Oracle is at it again, adding new features that users have requested! Orchestrator has always provided a way to monitor what is happening inside orchestrations so you can tell exactly what is working and what may be going wrong. This is the new Monitoring function inside the JDE environment.
There Was an Orchestrator Monitor Before. What Changed?
There has always been a debugger available to allow you to go through a particular data set step by step. There has also been an orchestrator monitor that offers insights into orchestration exceptions as well as a high level summary information available about the last 10 orchestrations.
You would get basic information such as:
- The last run time for the orchestrations
- The average time each one took to run
- Whether each one succeeded or failed
- An error message showing which orchestration failed and when
- Potentially the input of the failed orchestration (but not for individual steps)
- Overall successes/failures over a certain period of time
The old functionality didn’t offer additional information about the successes or inputs at the individual step level for failures.
The New Enhanced Monitoring Function Has It All
Instead of only having limited, high level visibility, JD Edwards Orchestrator users now have a wealth of data to explore about how their orchestrations are performing. You can now track step details for input and output which are logged into tables where they can be viewed and analyzed. Unlike before, when only the 10 most recent orchestrations were logged, this data is saved and can be revisited at any time.
The new widget in the Start button allows users to define the level of monitoring desired. Setting this up correctly is important since there is so much in-depth information that can be gathered that monitoring can potentially consume a LOT of resources. WARNING: Trying to monitor everything could lead to creating millions of rows of data that's largely useless.
Use Cases for the Orchestrator Monitoring Function
Developers are going to be very happy to have this new tool in their test, prototype, and production environments. It’s possible to select exactly which environment you want to monitor, or designate monitoring for specific users or roles. This helps limit the monitoring to the areas where seeing the results actually aids in debugging and decision making.
Example: You might have an integration that runs automatically at scale and doesn’t have issues (or that is tracked and logged elsewhere). But you might want to be able to see what happens if the integration is run manually as a one-off. With the new monitoring function, you can choose to monitor with that level of specificity.
How Having More Detailed Monitoring Helps:
Being able to see lower level detail for each individual step is obviously helpful for knowing where an orchestration is failing. You can pinpoint if it is an orchestration issue, a problem in a JDE application, or an issue with data. You can now troubleshoot more easily. The new monitoring function is like having an x-ray to see inside of your historical orchestration runs.
Common use cases include:
- Initial debugging and testing for new orchestrations
- Checking in on existing orchestrations that have suddenly begun failing
- Evaluating performance for orchestrations and finding ways to optimize each step
One of our clients uses Monitoring to see how many orchestrations are running, who is running them, and how long it takes for the orchestrations to run. This is a good way to evaluate how Orchestrator is being adopted and used across an organization, along with areas for improvement. This level of granularity wasn’t possible before.
Want More Guidance on Improving Your Orchestrations?
As always, we’re excited to see the ongoing upgrades to Orchestrator. Our team is here if you need support, advice, training, or help building orchestrations.