Is eConnect Integration Service Multi-threaded?

Personally I have not experienced performance issues with eConnect, so the question to as if the integration service is multi-threaded or now had not crossed my mind before, so here are my thoughts so far after the question popped up.

What is the integration service?

eConnect Service shown from services mmc

The eConnect integration service is a windows service that wraps eConnect,  creating WCF end points, that forward calls to the underlying eConnect API methods. It literally just exposes methods like CreateEntity via WCF and takes any calls, forwarding them through to the eConnect CreateEntity method, its a few lines of code.

The WCF Service Behaviour is decorated with Instance ContextMode.Single and the default ConcurrencyMode.Single. Thus the WCF service is singleton, serialising every call into the WCF service:

   *   -- Processes messages on one thread. 
   *   -- Creates one service object per session

The eConnect library is not in itself multithreaded, for example, it does not intelligently break an eConnect document up into multiple parallel threads for execution. So the only opportunity for multi-threading to be at play has to be at the application that calls eConnect. Thus from what we know about the WCF end points, the conclusion has to be that eConnect Integration Service is not multiple threaded.

There is evidence of integrations in use that successfully pushing very large volumes through eConnect with no performance issue, so perhaps for most people its performance is not an issue. For those of you experiencing performance issues lets think a little more about this.

Improving throughput

It is feasible to create your own version of the Integration Service, in fact I wrote one when WCF first came out that was very similar to what was to follow later from Microsoft. It would be possible to add thread awareness to such a custom application, submitting econnect documents in parallel against the eConnect API.

Using multiple threads to push more through eConnect leads me to another concern, if a large volume of transactions are pushed through eConnect and they are of the same type, that rely on updating a central resource, say a batch table, next note ID, or next sop number, then a bottle neck exists.

At a SQL level the transactions are turned applied as SQL transactions so if one element of them fails the transactions can roll-back safely. Due to this, at a SQL level another transaction cannot proceed until the previous is committed (if a shared table locking dependencies exists). Hence the transactions end up serialised anyway. Thus little performance improvement is achieved by multi-threading the transaction pump that is feeding transactions into SQL server (eConnect).

The place to look for performance improvement would be in an investment into the SQL server hardware and configuration. With some investment in time and/or money, it is possible to get those transactions to happen as quick as possible. That is a win for the users and a win for the integrating app. Optimising the hardware and managing the SQL instance properly will bring larger improvements in throughput than just attempting to push more volume into the bottle neck of the transactions. This also lowers the probability of dead locks, something that will increase with the higher throughput of SQL transactions generated by integrations. A healthy well provisioned SQL server a leads to a happier GP application.

Testing theory

I built a little console application to test this thinking out. It spins up a variable number of worker threads and tries to create the same overall number of inventory items using those threads. The underlying SQL server load seemed to have more bearing on the processing times than the number of threads, which did not seem to affect how long it took to process the work load. I admit I have not thought this through deeply, there may be a flaw in my empirical testing but taking it at face value it confirms the theory in this post. I know the size of the eConnect transaction is tiny so it may not be telling me much.

Worker Threads

Processing Time

 

1

6.291

 

1

10.526

 

6

5.317

 

6

14.913

 

6

5.103

 

6

5.808

 

1

5.165

 

I do wonder if breaking large eConnect operations into smaller chunks for submission would result in faster processing results overall, something for investigation in the future…

Please comment on this post, if you have any alternative views or insight on this, I would be interested to hear them.

Steve Endow talks about the same subject back in 2014 with his post Is eConnect multi-threaded? In this post he talks about the windows message queue based eConnect Incoming service having thread settings, this is not to be confused with the relatively newer WCF based “Integration Service” we are talking about here.

Comments (2) -

  • Good post.  I am open to hearing about any situations where people believe that eConnect is a bottleneck for their business process.

    I have only had one customer who had a rare situation that might have benefited from having more than one thread for an eConnect import--but a redesign of their process completely eliminated the issue.  

    My thought is that you do not want to have multiple threads for a single transaction type (due to locking/blocking).  However, if you need to import multiple transaction types, then it may make sense to have multiple threads, each handling a particular transaction type.  But my argument against that would be that it is easier to just create two EXE wrappers for a single DLL library that can run separately than it would be to attempt to write a properly designed multi-threaded app.  

    The second consideration, and what I think is the more important one, is that you have to realize that if you need to import enough transaction volume that you are even considering multi-threading, then you have a much bigger problem:  posting those transactions after they are imported.

    Posting transactions in GP takes much longer than importing them, so if you consider the bigger picture, your bottleneck isn't really eConnect--it's GP posting.  Thousands of transactions can be imported in minutes, but posting them can take hours.

    If you are implementing high volume eConnect integrations, you will likely need to consider automating the GP posting process, which was how I started working with Andrew Dean and Post Master.  
    • Thanks for adding to the conversation Steve, I'm happy you understood my point on transaction mix well.

      Worthy point on posting, but not all eConnect work ends up in a transaction that needs posting, (although I admit most integrations do). Syncing 10k products & prices to a 3rd party product feed, for example does not end up requiring posting but can require intensive eConnect work, say rolling a price change over those items in GP.

      Tim.

Add comment

Loading