https://netsuiteprofessionals.com logo
Join Slack
Powered by
I need to import 500,000 records to NetSuite overn...
# integrations
c
I need to import 500,000 records to NetSuite overnight, I'm trying to design for ensuring we're using parallel processes in NS. Nobody wnats to enter build phase until we understand how SuiteTalk behaves.
đź‘€ 1
m
The integration concurrency limit allocates those threads strictly to the integration. Meaning it cannot be used by the rest of netsuite, ever. Doesn’t really split your data over those threads.
c
That can't be right. It surely releases the threads when the integration is not running. @mightyd3
And what does it really mean? Does it allow for 14 concurrent SOAP connections or does it use the threads for concurrent processing of data it receives from a single SOAP connection?
m
What was described is correct. At the integration level. NetSuite will not allow those threads to be utilized by other integrations, if allocated. You can see this when you allocate X to integration X, and then try to allocate some more to others. You are limited to what is unallocated. https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/bridgehead_156224824287.html#Concurrency-Limit-per-Integration
I generally see the concurrency limits set on the integrated product side -- celigo boomi etc
c
This bit looks key
If the integration is currently idle, I would have through the threads would be released to other processes.
Are you suggesting that is not the case?
m
Read the paragraph about that screenshot.
c
"When allocating part of your account's concurrency limit to one application, you reduce the available concurrency limit for other integrations, which do not have a specific limit."
m
It is not the case. You are limiting those threads to that integration.
c
What is the behaviour when leaving the field empty?
m
No limitations
Outside of your account level concurrency
c
No limitations but not ring fencing resources from the rest of the system?
I think it's better to leave it empty then and set the max concurrency settings in Boomi
m
Correct.
c
It's not clear what allocation to make in Boomi though
Guess I could match it to netSuites 14 threads but they won't all always be avilable.
m
You might have to talk with them. SPS is similar. A end user can't touch their concurrency settings, but they can internally if requested. (first hand knowledge)
c
We purchased 10 threads which is the max - I've got a feeling it won't be something we can configure
I'm starting to think 500,000 records overnight is too many
m
I wouldn't disagree there.
c
I can't see another option though - I need to get end of month rev rec journals from two other systems - it's a lot of data
m
Don't really know enough to provide value there. Are they just journal entries you are posting? Try to post to custom records first, then map/reduce in?
c
That's assuming importing against a custom record would be quicker.
m
For me, always is.
MUCH faster.
c
Was that still via SOAP?
m
Oh no.
I don’t use soap, but I have seen integrations which do, and with speed.
c
SOAP was just the default due to the Salesforce Bulk API to NetSuite connector
It looks like that Boomi connector isn't really saturating NS
Literally only utilised 3 cores at a single time
m
Time to call up boomi.
w
A bit late here, but note that NS has async versions of their API calls. If you utilize them for bulk inserts, the API concurrency won't be your bottleneck. Don't know if Boomi has support for them though.
3 Views
Open in Slack
PreviousNext
Powered by