1,588
I'm thinking of a system with very high volume, tens of thousands of transactions being sent in batches of 1,000 to eConnect in XML using the eConnect schema. Where is the bottle-neck for processing transactions via eConnect?
Could you gain an advantage by installing the eConnect service on additional machines and distributing the batches across them? Or is the bottle-neck at the SQL Server level?
*This post is locked for comments
The article Harry has picked up on it regarding the older eConnect service.
The modern WCF based windows service now known as the eConnect Integration Service, from my investigations is single threaded.
See the following post for more info:
http://www.timwappat.info/post/2016/07/19/Is-eConnect-Integration-Service-Multi-threaded
Tim.
Here's an article on the topic and the setting you would need to change, the default install is apparently 1 thread.
dynamicsgpland.blogspot.com/.../is-econnect-multi-threaded.html
I've had similar problems with the sop invoice integrations with econnect. I wrapped each invoice with a transaction. I ran a trace and saw a lot of chatty things going on. the code does not scale well, it needs to be rewritten to handle 10000 invoices at a time. I am able to import one invoice per second, and posting takes twice that.
Where do you find these details, Obi-Tim Kenobi?
Chad,
The service contract on the eConnect Integration Service is marked as singleton and single threaded, so my view is that it is not multi-threaded. You have me wanting to test my theory in practice though...
Tim
I was speaking with another GP developer and he felt confident the eConnect service accepts multiple requests and processes them in parallel. He said he has an integration importing 1,000 transactions in three minutes. Problem is I'm not sure if I have the time to design my own, proper test.
I am unsure but I'm thinking no - I don't think it has been optimized for a modern version of SQL. I don't think that's on MS roadmap - they are putting their development efforts into AX 7 on premise and AX Cloud/Dynamics 365 now.
That is what I was thinking. However, I am as yet unaware of the finer workings of SQL. Are the running of such stored procedures multi-threaded?
I believe the bottleneck is at the stored procedure level in SQL. All econnect does is send the transactions through to the stored procedures in GP. If you run a SQL Trace when running your integration you will see what is going on.
We've had problems and it's related to the size of the transaction...the more lines per transaction the longer it takes. We are also using AA which adds an additional layer of complexity.
Hi Chad,
We have the same issue. GP is linked to a program called Avantis via eConnect. Where there are about 1000+ transactions, it takes a few days to integrate over. No one has been able to find out why this process is slow, so I would be interested as well in other people's experience.
Share
Report
All responses (
Answers (
