[Vinayak Contributions: 0Level 1☆]

Hello everyone,

I have 200000 of orders to be created in Netsuite. These 200000 of data is coming from another system (via Integration). And on each order Netsuite should perform some logic ie Netsuite trigger user event script so I am not understanding whether I should go for sop or restlet. what is the best possible solution to add these data into Netsuite via integration.

Thanks,
This is a cached copy. Click here to see the original post.

[Olivier Gagnon NC Contributions: 0Level 1☆]

Web Services (SOAP based) or RESTlets are both fine. RESTlets are traditionally faster to set up and you can get more paralelism from them off the bat, so they are a typically a good choice for those reasons.

In either case, both will allow you to achieve your objective, so it mostly depends on your situation. If you happen to have the infrastructure in place to set up Web Services faster than RESTlets (example: you have a Dell Boomi box lying around), or if you are more comfortable in C# or Java, than use Web Services, otherwise if you’re already pretty skilled at SuiteScript a RESTlet will be quick to set up.

[Vinayak Contributions: 0Level 1☆]

Hi Olivier Gagnon NC,

At a time how many records I can insert using web service or RESTlet. I mean parallely. and with both these option my server side scripts(User Event) will trigger with irrespective number of records I am inserting at a single time right?

[Olivier Gagnon NC Contributions: 0Level 1☆]

With Web Services, even SuiteCloud Plus, you’ll always be single thread. So, 1 record at a time. But with SuiteCloud plus, you’ll probably see throughput increase (i.e. still 1 record at a time.. but faster).

With RESTlets, you have a certain possible concurrency IF you code your inputting multi-thread as well. The exact number of concurrent executions is up in the air these days, but I would safely say between 5 to… 15? The reason it is unkown is that NS controls it, and they have released contradictory statements of late and I lost track of what the truth is.

[pcutler Contributions: 0Level 1☆]

One option with SOAP services is to use multiple employee records for multi-threading. A single employee is generally limited to one simultaneous SOAP request, so with 100 employee records you can have 100 simultaneous requests. There should be no limit as long as your NetSuite account is sized correctly for the number of active employee records in the system.

If you pay for a SuiteCloud Plus licence, another option with SOAP services would be to designate an employee record as a “Concurrent Web Services User.” This will increase the concurrency limit for that employee based on the terms of your SuiteCloud Plus license.

Finally, as Oliver pointed out, NetSuite has been inconsistent on their concurrency limits for RESTlets. They originally announced a concurrency limit of 15 threads and subsequently announced that they are delaying enforcement of this limitation. Use caution if you’re developing multi-threaded RESTlet integrations, because we can probably anticipate a stricter limit being applied in the future.

[chanarbon Contributions: 0Level 1☆]

I do agree with the point raised by pcutler with the multithreading approach if you are using SuiteCloud Plus. Here’s another solution that I think would be pretty much useful if you want to try something new and interesting:

1. Create a RESTlet that will accept a CSV file. Each file line should be formatted in such a way that you can easily parse it.

2. Each RESTlet call would trigger a Map/Reduce script which you will feed with the CSV file as script parameter.

3. On the getInputData phase of the Map/Reduce script, you will parse the CSV file and convert each line into a simple JS object array which you can pass to the Map phase

4. The map phase creates the record based on the CSV columns

From the integration standpoint, you can have the multithreaded application mimic the addList functionality of web services, with the fact that Restlet calls can be concurrent all you have to think is which queues are to be used for the queueing of the MR scripts.

[Author]

Posts