Is a Third-Party Software Making Your JD Edwards Application Look Bad?

JD Edwards EnterpriseOne can do a lot for a company. It’s absolutely packed with features and functionality that makes it come pretty close to an all-in-one solution. Unfortunately, as with anything else in life, nothing is 100% perfect for everyone all the time. It’s like buying a car then getting new wheels and tires. What came with the car might have been acceptable, but you wanted a different look or better handling. It’s the same with JDE – you love it, but here and there you just need something a little different that fits your company’s needs better.

A company might need to make their report output look a specific way, have fine-grained control over their scheduled jobs, implement more complex security, or any number of things. Third-party software to the rescue! When a business wants to extend or enhance specific features of JDE they can reach out to any number of companies for solutions to personalize their JDE software. Third-party software can do more than just make JDE features better. As fantastic as JDE is, it doesn’t really do everything as I’m sure we all know. Sometimes companies need a very specific solution for their industry which aren’t in the scope of an ERP software package.

All of these third-party applications and hardware interface with JDE in some way, and the database is always part of it. An application can simply provide a small amount of information all the way to a high-bandwidth continuous interface manipulating data throughout the system. If you have other applications interfacing with your JDE data, you *will* affect the performance of JDE in a measurable way. If an external program has an issue that makes it take up too much of a database’s resources or block other processes from completing, it can very easily cause the JDE application to slow down or even stop.

How does this get reported? In my experience, if the database serving the JDE data is affected by something people most commonly blame the database itself. This is especially true with database sessions that are blocking other sessions. Whatever happens, the tech team is asked why JDE and the database are not working correctly. End users, from data entry clerks to the CEO, assume that some part of the JDE/DB combination is causing problems.

I’m not saying a database or JDE can’t possibly be the source of a system-wide problem. But, just because JDE or the database is having problems doesn’t mean that either one is the cause of the issue. If you have a third-party software that touches JDE data, some day you will encounter a situation where that software or something in between causes JDE or the DB to malfunction. The complicating factor here is that most people see a problem in JDE or the DB and think that’s the only place to look. If someone tells them that the cause is not either one but an external process, it’s difficult for them to understand or accept.

Anything that touches your JDE system or the database can be the source of an issue – including the network and all hardware. If there is a network hiccup in the middle of a third-party software trying to post a transaction, that can cause blocking that halts JDE processing. No amount of performance tuning, additional memory, or more CPU can solve that problem. Third-party reporting tools can be a real performance killer without needing any help. When you allow people to create ad-hoc reports who are not familiar with JDE processing or database indexes, you’re just asking for trouble. One person can create a report that will bring any database to its knees in moments whether it’s a small standalone instance to a million-dollar Supercluster.

There are many other problems that can crop up due to something external to JDE or the database. Putting servers on different subnets is a killer to JDE processing and a CNC or DBA won’t be able to fix that. One large client of mine had a debilitating performance issue they struggled with for weeks. After getting brushed off by the network and infrastructure teams repeatedly, those same people discovered that one of the network switches used by JDE was getting flooded by an unrelated server which slowed down all traffic on that switch. You may also find that an application is running exactly as designed, but due to large data selection, extensive server-side processing, or waiting on multiple threads to finish you find yourself in a situation where you just have to accept the performance hit or redesign the application.

Keep an open mind when troubleshooting JDE and DB issues. Just because you are seeing the problem reflected in JDE or the database, that doesn’t mean that’s where the problem started. Third-party software isn’t perfect. Networks aren’t always stable. Hardware fails. People trip over network cables. There’s an entire world of possible contributors out there waiting to drop your business processing in to a black hole. Cast a wide net early and you’ll figure out the root cause faster.

Feel free to send us any questions you may have at Inquiries@getGSI.com.