Mike's Workshop Manuals: Service manuals for every vehicle
Home >> Mercedes Benz >> 2016 >> Sprinter 3500 Van Cargo Extended, 4WD >> Repair and Diagnosis >> TMC Recommended Practices >> Cost Control Methods >> RP 1612 - Service Event Data Transparency >> RP 1612 - Service Event Data Transparency >> Data Sharing Plan >> Customer/Fleet Management: Repair Order/Case Created/Updated

Customer/Fleet Management: Repair Order/Case Created/Updated

In this situation, the service provider submits a POST message to this web service endpoint to notify the customer's FMS that an RO has been created or updated. Provision for the following data elements or fields should be made accordingly:

NOTE: An API is always less prone to high-traffic creation if there is no need for real-time actions submitted by local actions. Unless there is a need for real-time updates, a scheduled job or services can call the following requests on regular intervals as needed. This also means less development required to create the standard, and less effort to come into compliance. POST and GET terminology is used here to indicate the nature of a request. POSTS and GETS often handle one specific direction of query vs. another. It is common for API structures to handle multiple verbs for any given request to support flexibility of transactions. This is important when building the solution especially if it follows a representational state transfer (RESTful or REST) standard in development.
NOTE: Regarding restriction limitations on data traffic, TMC recommends that developer solutions limit the data on GET - e.g., when gathering/requesting 300 R O/cases at a time. Snapshots of data are recommended versus sending all data since last transmission, as are use of appropriate VMRS codes. Security restrictions should be in place secure data integrity and guidelines implemented to restrict someone from pulling data for another location, maliciously or without proper user credentials and authority.