We are migrating our applications which use the Epicor SOAP API to use REST instead. However, there is a potential issue which in reviewing the SOAP code I’m not sure what the equivalent is in REST.
When we use SOAP, we would use a license and due to the limited number of licenses available there was the potential for no license to be available. As a result, in the code there is a check to see if an error occurred, and if the error is related to no license being available we perform a back-off series of retries until we either succeed or an excessive number of retries occurs.
Is there a similar phenomena that we need to take into consideration when use the REST APIs? When I browse the (OData) APIs I don’t see anything mentioned in the result codes about this. If I look at the custom methods list, I see a possible status code 500, which means “Internal server error. Server is unable to process the request.” but without explanation of what could cause this.
The Server error is captured in the Windows Event Log ‘Flight Data Recorder’ for you to review. If you want to opt into returning full error content, change the vanilla ASP.net custom error handling.
I am more interested in how you are grabbing licenses.
Are you obtaining a session with license for a length of time?
Are you just using default temp sessions and hoping a license is available when requested?
There are design trade offs there as to what user experience you need / want to provide.
For SOAP, I am using the soap module of node.js, creating a new WSSecurity object passing the user name and password. From testing we did with this when it was initially implemented, it actually grabs a license for only a very short period of time. As I recall, we set up an artificial environment in which only a single license was available, and then tried running multiple calls in “parallel” but in practice we weren’t reliably hitting a license error even though the overall SOAP call was relatively slow (a few hundred milliseconds).
For REST, I’m using the “authorization” header to put an encoded version of the user name and password into the HTTP request.
In practice this has worked out fine so far because our web services licenses are separate from our users and we don’t have any long-running processes using web services. So even if we happen to temporarily run out licenses, it is very likely that one will free up again in a few seconds.