Categories
API Change

Background Processing

Over the last year as LOCATE’s customer base has grown and the nature of business conducted on LOCATE has changed we have started to see larger and larger orders being processed in LOCATE. Large specifically as it relates to the number of lines on orders. What used to typically range from 1-20 lines with an occasional 100 line order now averages in the 1-40 line range with occasional orders of 1000+ lines. Performing actions on these larger orders has become a bit of a problem given LOCATE’s strict 60 second processing window for API calls. These larger orders simply result in timeouts as the operations cannot be performed quickly enough. One current work around is to leverage CSV files and the “Order Action” import to background process these larger operations, but this is tedious for the user and developer alike. With tonight’s release, we are beginning an important change in the LOCATE code base…background processing.

LOCATE makes use of background processing in many places (e.g. syncing services, auto-work, vendor confirmations, vendor site operations, etc.), but we have shied away from using background processing on the more frequently used endpoints like issuance, unissuance, voiding, cloning, etc. Starting tonight LOCATE will begin using background processing dynamically, based on order line count, for the /transferorder endpoint. Specifically with the issue and unissue operations. When one of these operations is backgrounded LOCATE will return a 202 response in place of the usual 200 response. Since the operation is backgrounded and the model will not have changed the 202 response contains no content and serves purely as an indicator to the caller that LOCATE is working on the requested operation.

We selected the /transferorder endpoint as the starting place for this roll out as it represents a lower impact order type where we can test/verify this functionality in the coming days. If you are calling transferorder-issue or transferorder-unissue then you may have to make some changes to your code to keep it working as it is currently written. With this rollout we are introducing a new header that can be provided on your requests to tell LOCATE that you do not want it to background process the request. You can read more about the details in the “Background Processing” section on the Core API Features page. For all developers who’s code relies on LOCATE’s serial processing of their requests we recommend that you add the new header to your code now so that as we roll out this change to more endpoints your code will not be affected until you are ready to change it, but disabling background processing when using an operation on a larger order will still result in a timeout as it does now.

We will update the API Reference to include the 202 response code as endpoints are updated to the new standard, as well as post about the changes on this blog. This change will greatly improve the user experience as well as reduce un-necessary load on the LOCATE servers for requests that cannot complete in a timely fashion.