Netsuite SuiteScript (Suitelet) vs. SuiteTalk (Web Service)

Netsuite purposely disallows a user from establishing two separate sessions to the NetSuite portal. That is, you cannot have a session established on Firefox and Chrome or Internet Explorer at the same time, and this is true for any user including the one being used by the Netsuite Web Service. This causes a potential problem where your visitors may be submitting forms at the roughly same time which triggers a second web service call to be made to Netsuite while the previous one is still running. When the second web service call is made before the first one is completed, the first call terminates without completing its task potentially losing a lead or whatever the task the first one was designed to do.

How do we go about solving concurrency problem?

There are a few ways to resolve the concurrency problem Netsuite purposely imposed on users. Depending on your need and in-house expertise, you may choose to use any one of the following options to overcome the concurrency problem.

1. You may choose to queue web service requests via your preferred programming language, and send them one request (or batch) at a time in the background. This requires that you store the individual requests in your own persistent storage for later invocation to soap-based Netsuite Web Service. An example of how to create a customer via the SuiteTalk web service call is illustrated in this tutorial.
2. Use Netsuite Suitelet. Suitelets are extensions of the SuiteScript API that give developers the ability to build custom NetSuite pages and backend logic. Suitelets are server-side javascripts that operate in a request/response model. A suitelet is invoked by making a GET or POST request from a browser or via a command-line cURL interface. You may develop a Suitelet and make it available publicly without requiring a separate run-time Netsuite user license or Netsuite user login.
3. You may opt to purchase the Netsuite plug-in which allows a user to establish up to 10 sessions. This may not be a viable solution to a concurrency problem if you have a high-traffic website with a high number of web submissions.

License and Concurrency Considerations

Here is the statement from Netsuite on License and Concurrency Considerations. This is extracted from Getting Started with SuiteFlex documentation.

Every NetSuite user is given one browser session and one SuiteTalk web services session. The browser session means the user can be logged in to NetSuite with only one browser at any given time. For example, a user that logs into NetSuite using Firefox while her Internet Explorer is still logged in would result in her IE session being terminated. SuiteTalk user sessions work the same way. A SuiteTalk session is single-threaded, which means it cannot be used concurrently by multiple applications. Consider the following scenario of two applications trampling each other’s sessions:

1. Application ABC logs in to NetSuite and establishes a session
2. ABC performs some data manipulation
3. Before ABC has a chance to log out, application XYZ logs in using the same pair of sign-in credentials
4. ABC attempts another data manipulation but is unsuccessful because its session was terminated by XYZ
5. ABC’s retry logic logs in again, thus terminating XYZ’s session

As shown above, multiple applications using the same user sign-in credentials at the same time can result in session problems that are difficult to diagnose. These problems can often be resolved by using one of the following solutions:

• Ensure each pair of sign-in credentials is not used by multiple applications at any given time
• Use a separate license for each SuiteTalk application in use

Multi-threaded applications may also face the same session problem. Threads that access the SuiteTalk session simultaneously will trample each other the same way multiple applications do. To ensure a multi-threaded application can safely use a single WS session, try these solutions:

• Develop a pooling mechanism that serializes the access to the NetSuite WS session. When a thread gains access to the session, the access is locked until the thread finishes using it and releases it back to the pool. All other threads must wait for their turn to access the session. This mechanism avoids session problems by ensuring only one thread may use it at any given time.
• Consider purchasing the WS Plus module. The WS Plus module allows a user to be designated as a “concurrent web service user”. A concurrent web service user’s session can have up to 5 concurrent sessions at any time. This means the user can have up to five logged-in WS sessions, each with their own jsessionid. Note that threads sharing the same login session (hence sharing the same jsessionid) will still clobber each other.