What / where is the setting within Service Connect that determines the number of Epicor active sessions a given interface is allowed to consume? We have an integration set up now that appears to open and use as many available Epicor licenses as we have available when it’s ran, which then runs us out of available Epicor seats overall until it completes.
In Service Connect, under Connectivity, then Asynchronous Pools, we can right-click on the single instance and open Properties…there is a value there shown as “Maximum threads count”, which is set to 7, but that doesn’t seem to have any relation to the number of Epicor sessions that get opened.
Right-clicking on Connectivity and selecting Properties shows a “threads count” of 12, but that appears to be related to the Service Connect side, not to the Epicor side of things.
Sure it’s a pretty straight-forward thing to change, but not having much luck with changing either of these values and then restarting services.
Should add that setting the Epicor profile that this runs under to not be allowed multiple sessions (in Epicor / User Account Maintenance) causes problems when Service Connect tries to open multiple connections, so we’re really looking at where this may be driven from the Service Connect side.
I’m nowhere near a Service Connect expert, but our Workflow has a starting workflow and then a sub-workflow that is called for each record in the input file. In that sub-workflow call, we have it set so it does not “Run cycles simultaneously in several threads”. Not sure if your workflows are set up the same way, but I hope this helps. We had the same issue where Service Connect was consuming all of our licenses until we changed this.
Thank you Tyler…unfortunately our workflows aren’t set up like that, but it does look exactly what we’re looking for. I just thought that this would be defined a little better elsewhere.
Are you using Service Connect 9.05.702 with Epicor 0.05.702a?
The number of threads on the first screen shot (for the asynchronous pool System) controls how many threads Service Connect (SC) is allowed to use for independent asynchronous processing of messages (concurrency of synchronous calls to SC is not restricted).
SC allows to call Epicor using .NET or Web/WCF references.
During the execution of the workflow, when Epicor .NET reference is invoked, SC needs to supply a logged-on Epicor session for Epicor to accept the call.
The session is opened with the first invocation of Epicor .NET reference by the workflow, and is released when the workflow completes, unless session caching is enabled.
Session caching allows to save on time needed to open the session, if SC is under heavy load, keeping the session open between workflow executions for some time (session is only reused if appServer/user/password/company/… are the same).
The behavior you describe (if workflows use .NET references) may be caused by the session cache mis-behaving, and not releasing/not reusing the Epicor session in time.
To see whether that is the case, you can use SC administration console:
Expand Connectivity
Select .NET References
Right-click .NET References and select Properties
In .NET References Properties dialog, un-check Cache Epicor sessions
Restart SC services
Note: restarting SC services breaks the processing of the messages being processed at that time, so, you need to pick up such time when messages are not being processed. If the integration used input channels to pick up incoming messages, then disabling input channels (you will need to re-enable them after services are restarted) and checking with Document Tracking / Events\All Logs in SC Administration Console would allow ensuring that no messages are under processing at a particular time).
When you import the .NET references, there’s a checkbox on the 2nd or 3rd prompt in with a checkbox to “Use Service Licenses”. This was added quite a few releases ago, and is supposed to help with eating up your regular user licenses. If I’m reading the documentation correctly, if you hit your license limit, it slows down SC instead of using up all available licenses.
Tyler was correct as well in that you usually want the sub-workflows to run asynchronously. I’ve never done anything with the checkbox he mentioned - so I can’t really speak to that. However, on the “General” tab I always set it to “Execute Synchronously”. I’ve been creating SC workflows for about a dozen years, pretty much since Epicor first came out with it, and I can’t think of a time where I’ve needed to run them asynchronously. In fact, when I’ve tried doing it (to increase throughput), it’s caused nothing but problems.
