This one is another important eConnect Error message and its details. Thanks to the ZSL GP Team, for providing me the details to publish.

The team developed an Integration Tool for GP using eConnect v10.0. The tool was tested rigorously on a typical local environment and an apparently fresh environment. The tool was then released to the client and the installation did not have any issues.

Finally, the tool was given a test run on Client’s environment and the following error message took everyone by surprise:



Cause: The User Account, with which the eConnect was installed on the DB Server, got removed from the Domain, by the time they installed this tool. And apparently, the eConnect COM+ Component Services Identity was configured with the same User Account. Now whenever the Integration Tool interacts with eConnect COM Service, the Deleted User Account would have been referred to and since it does not exist, this error was thrown up.

Solution: The eConnect COM Service Identity was set to the option “System Account”. This would instruct the Integration Tool to use the current logged on User Account.

Now, I have some important points to highlight/stress based on this:

1. You can always stress the System Admin of any Client, to create one Domain User Account specifically for eConnect COM Service, with the credentials never expire and does not require any Password Enforcement. This is mandatory, as most of the times, the Integration on a Client’s place is going to be scheduled to run when there is no OR less activities on GP, some time in the midnight or some time in the weekend. In such cases, this would become a serious trouble to the clients, when they come back the next working day to find that the transactions had never been integrated for some issue which is irrelevant to them. When I say irrelevant, it is irrelevant to GP data. The System Admin need not reveal this to anyone else in his/her organization or even to you, once this is deployed. If anything to be troubleshot, you can always reconfigure the identity for that moment, and then ask the System Admin to reset it with the previous User Account.

2. If the System Admin does not approve of creating a new and separate User Account, then setup the eConnect COM Service Identity to “System Account”.

3. For your sake, please handle all possible Exceptions while developing a tool or a product which uses eConnect. I have seen people handle one common Exception, which is System.Exception. But this does not cover all exceptions. There are more: eConnect Exception, SQL Exception, and much more. Well, I am not a .NET developer by profile, so please do correct me if I have mentioned something wrong. But I do know that there are more specific exceptions (what we call Inner Exceptions) that need to be handled. So be more attentive and handle those exceptions.

4. When you document the Installation & Configuration of your tool, never miss detailing the eConnect Runtime Installation and Configuration, if the client do not have it running already. If the client do have it already, just mention that this needs to be confirmed. This does not take any special effort, but certainly have a clear cut instruction for both you and the client, for reference in future.

Vaidy