Is there a way to see what the issue is when DSI stops communication with JDE? I think it is usually an issue on the JDE side but want to be able to prove that. To fix it I have to bounce the communication agent to reset the connection.
Hi James,
That is a rather generic question, so I’m going to have to provide a rather generic reply.
As we offer multiple, but related, software products (dcLINK, MEP, Cloud Inventory, etc.) that integrate with multiple JDE products (World, EnterpriseOne) running on different target hardware (Windows Server, iSeries, Linux) talking with different backend databases (SQL Server, Oracle, DB2) across disparate environments (OnPrem, Cloud), where the specific version details of the products also have large impact on the interoperability requirements.
So a complete understanding of all the integration details is required for triage of any such issue from communications with JDE.
The general answer is that it would depend upon the specifics of the symptoms being presented, and based on those symptoms, what appropriate artifacts are available for examination from the time period where this occurred.
In general, I would want to look at the log files produced by our software over that time frame; it is also possible that I would also want to examine Windows Event Viewer logs from the same time (assuming this is not iSeries).
It sounds like this is a recurrent problem, so I would also want to look for patterns around when the failure was occurring.
If the problem can be replicated, or known to replicate in a certain timeframe, possibly additional detailed logging can be enabled during that time to provide more pointers to underlying issues.
I would probably also look at the system/integration maintenance procedures, such that when JDE was taken down for maintenance, that the “DSI” software was taken down first at that time, and then brought back up second after JDE was again running & operational – and that such periodic maintenance was occurring at all.
Any specific steps, and what appropriate artifacts to be looking for/thru, would of course be dependent upon the version of our software, whether it is OnPrem or Cloud-based, as well as the particular JDE product being integrated with, and the versioning of that product.
And that versioning between our software & JDE can be critical, especially as integrations with 64-bit EnterpriseOne are more complex & require all components to be more closely aligned for completely successful operations.
We would also absolutely want to verify that our software which is installed on your JDE system is appropriate/current for the underlying version of the JDE code, as upgrades to the backend ERP without corresponding updates to our software can/will cause issues.
This would be an appropriate thing to open a ticket with the Customer Success Center to further investigate, so that all of those details can be drilled into to be able to determine a more specific plan-of-attack.
1 Like