Is eConnect multi-threaded?

By Steve Endow

Just when you think you know something about something, a question comes up that gives you pause because you don't know the answer.

I just fielded a seemingly simple question about eConnect:  Is the eConnect service multi-threaded?

Good question, I didn't know.

I tracked down the GP 2013 eConnect Install Admin Guide and searched for "thread", and what do you know...  There is a configuration option to specify the number of threads for the eConnect.  Kind of, but maybe not really.

The catch is that the configuration option is listed under the Incoming Service.

eConnect.Threads This key specifies the number of threads that are available
when the service starts. The default value is “0”.


< add key="eConnect.Threads" value="0" / >

A value of “0” indicates a single thread will be used. You can set the value to any
number between 0 and 19. A value of 19 makes 20 threads available when the
service starts. A higher number of threads should allow the service to process
documents more quickly.


While that may sound geekishly cool, like turning on eConnect afterburners, there is a good reason why the default value is one thread.  The subsequent warning on page 34 explains:

There are scenarios where increasing the number of threads degrades system performance. If the server cannot support more threads, or custom code added to an eConnect pre or post stored procedures is not thread safe, adding threads may cause unexpected results. Changes to this key’s value require careful evaluation and testing.


So while this indicates that the Incoming Service supports multiple threads, can we then deduce that the main eConnect service supports multiple threads?  I guess I still don't know for sure since I've never bothered to try and develop a multi-threaded eConnect application.  Presumably someone at Microsoft has a definitive answer.

I've developed integrations that have processed millions of transactions and have only had a few situations where multiple threads might have helped to process transactions faster, but it would have required me to write a multi-threaded integration, which probably would have been difficult to justify.

But if you know that you will be running multiple large integrations at the same time and have a limited amount of time to import transactions, it might be worth investigating.  And testing...thoroughly!

Steve Endow is a Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com