Topic
  • 1 reply
  • Latest Post - ‏2012-03-02T22:01:48Z by GregWilhelm
GregWilhelm
GregWilhelm
6 Posts

Pinned topic NetSuite Simultaneous Request Hard Limit

‏2012-03-02T18:52:09Z |
For posterity, we discovered when connecting to NetSuite using the same credentials, that NetSuite allows a maximum of ten simultaneous requests under the same session. The amount of simultaneous requests that you can issue varies depending on your NetSuite license. If you exceed the number of simultaneous requests based on your license, you will start to receive WS_CONCUR_SESSION_DISALLWD errors from NetSuite on your SuiteTalk responses.

NetSuite apparently pools the session on their side based on the credentials that you provide. That means that this hard-limit of ten simultaneous requests spans across multiple orchestrations.

This means two things:

1) When connecting to NetSuite, you have to use a different set of credentials for each orchestration that you configure to support multiple instances.
2) You have to manually check the response of each and every NetSuite call (including searches) to ensure that the call completed successfully. Otherwise the orchestration will keep running and will mysteriously fail at a later point.

I hope that this helps somebody out in the future.
Updated on 2012-03-02T22:01:48Z at 2012-03-02T22:01:48Z by GregWilhelm
  • GregWilhelm
    GregWilhelm
    6 Posts

    Re: NetSuite Simultaneous Request Hard Limit

    ‏2012-03-02T22:01:48Z  
    The response that I got from NetSuite regarding this issue is:

    At this time, there is no way to disable this multi-threaded behaviour on the NetSuite end. As the documentation suggests, the Cast Iron application will have to retry the request if and when it encounters a WS_CONCUR_SESSION_DISALLWD error.

    Their suggestion is to manually build in retry logic into every NetSuite SuiteTalk call made from Cast Iron (this functionality doesn't appear to be built-in). Seeing how some or our orchestrations have upwards of seven distinct NetSuite requests, we are just going to fail the orchestration at that point instead of trying to implement this with loops and sleeps on every call.