Frequently Asked Questions

I currently do not govern my REST concurrency. What happens now?

If you exceed the limit for concurrent requests, an error will be thrown. You need to make sure that your client applications will retry sending requests in the case of an error. This has always been considered a best practice, and the change in concurrency governance does not introduce any new error codes.

Will my existing integrations break due to these changes?

If the concurrency limits are exceeded, your integration might encounter the error codes listed in Effects of Authentication Method on Concurrency Governance. You must modify your integration to handle these exceptions and you must add logic to retry the requests.

Will this affect my sandbox account governance?

Sandbox accounts match your production governance limit. Developer accounts always have a governance limit of five.

Can I monitor my account’s concurrency usage level?

You can check your account limit on the Integration Governance page, at Setup > Integration > Integration Governance.

I have multiple user accounts being used for concurrent SOAP web services based on request–level authentication. None of them exceed one request at a time. I do not have an SuiteCloud Plus license. Do I now need to buy one?

The total number of web services concurrent requests across all users will be governed by the account level limit. If you exceed that limit, you might require additional SuiteCloud Plus licenses.

How does this impact the SuiteCloud Plus license?

Prior to version 2017.2, SuiteCloud Plus licenses helped increase the limit on maximum permitted concurrent SOAP web services requests. This did not have any impact on RESTlets. Starting from version 2017.2, both SOAP and RESTlet requests can benefit from SuiteCloud Plus licenses. SOAP and RESTlet requests both share the same pool for concurrency, which is set at account level. By purchasing one or more SuiteCloud Plus licenses, this limit can be increased.

Is there any impact based on the authentication used for SOAP web services? (Request-level or token-based authentication)

For the RESTlet API, there is no impact. All RESTlets are subjected to the account-level governance limit. For SOAP web services, if you want to use request-level authentication, you need to designate a concurrent web services user to enable multiple concurrency. If you switch to token-based authentication (TBA), you do not have to designate anyone as concurrent user. You can run multiple SOAP requests as permitted by the account-level governance limit.

You should use TBA. This eliminates the need to designate a concurrent web service user as one token can be used in more concurrent requests up to the account limit.

How does the governance change affect the usage of the Concurrent Web Service User option on the user record?

You can continue to use this option to run concurrent SOAP web service requests for designated users. However, these requests will be counted against the account-level governance limit and there is no guarantee or reservation for designated users.

Prior to version 2017.2, if you had one or more SuiteCloud Plus licenses, each designated concurrent web service user is guaranteed 10 concurrent SOAP requests. With the change, if a designated user makes 10 concurrent SOAP web service requests, the number of requests that succeed or fail will depend on other SOAP or REST requests that are being processed.

You should use token-based authentication (TBA). This eliminates the need to designate a concurrent web service user.