JobBOSS | Ideas

API to send DCMobile transactions directly to JobBoss

DCMobile is a very power feature out on the production floor. There are other telemetry values that should be collected at the same time that an employee enters their data. To keep the user from having to enter duplicate information, Kinemotive would develop their own intranet page that collected all of the data and then handed JobBoss it's relevant data and stored the non JobBoss data elsewhere. By having an API, then Kinemotive doesn't have to make raw database inserts. JobBoss could filter the data and keep absolution integrity over the data in the JobBoss database.

  • Guest
  • Apr 5 2017
  • Already exists
  • Nov 19, 2020

    Admin response

  • Attach files
  • Guest commented
    19 Apr, 2017 02:47pm

    User Seat Reservation / Multi User Seat. The current SDK requires a user login before data can be exchanged. In a desktop environment, this works well and maps to the concept of one user per machine. In a web based world this becomes problematic. If I dedicate one user to the web application, I have a race condition if two people are using a page that needs SDK access. So now I have to implement locks and queueing for the lock if a collision occurs. 


    There is also a condition where all seats could be taken and the webserver get's locked out. Think of a situation where an "Oh my gosh" even happens at the company and every manager logs onto JobBoss. If they are low on seats, then they take all available seats. The production worker on the floor is now locked out of entering critical real time data. So a reservation / dedication of a seat to the web application would be nice.


    These two issues are both around the same feature so I've bundled them together. Basically a different type of authentication and revenue protection for Exact are needed in the website world.

  • Guest commented
    19 Apr, 2017 02:46pm

    Additional input;

    Replace XML with JSon. I've done projects with both XML and Json and JSon wins hands down. It's lighter weight so it takes less space, transmits faster, and it easier to read by humans. I haven't noticed anything I can do in XML that I can't also do in JSon.