Reports run on data, and businesses run on the insights provided by these reports. Even a small department may have dozens of reports that are critical for understanding what’s going on in business and information workflows and making timely decisions. Those reports need to run on time and if they have errors, you need to know.
Recreating a Workflow for 100+ Reports in 2 Weeks with the JDE Orchestrator
Recently, we had a client who was in the middle of an upgrade. They had over 100 reports to run on a regular basis in their old system, and needed to recreate the same workflow in the new system. They looked at 3rd party report scheduling tools, but realized that the Orchestrator might be able to do what they needed without the expense of paying for any more software.
They were right.
Our ACBM team only needed two weeks to build 20-30 orchestrations to run the client’s 120 reports. That’s much faster than the client could have configured a third party system. They saved on both software costs and time to deploy--all with standard JDE tools.
What We Did
- Put all the reports on different schedules for different users to run automatically and unattended
- Built out dependencies and prerequisites, including dependence on previous reports when applicable
- Created error handling process to message or notify users of errors if a report failed
Error Handling in Reports
There are two options for dealing with errors in reports.
| Independent | Dependent |
| For independent reports, you can simply let the user know that a report has an error and keep the workflow going. | For dependent reports, you can abort and stop processing all future reports that depend on that initial report. |
Building Orchestrations for Independent Reports
For reports that had no future dependencies, we simply needed to send a message to the user to notify them of the problem. We built an orchestration to find all reports that errored in the JDE in the last hour and send an email to users.
This had a couple of components: a form request to pull the reports that ran for the day that had an error, and a Groovy script function to filter out anything from more than an hour in the past.
The Challenge with Dependent Reports
Dealing with errors for dependent reports was the more complicated piece of this project. JDE narrowly defines an error as a process that doesn’t run at all. For example, if a journal entry isn’t in balance, it errors out because it didn’t process. However, as long as a report can process, it is considered a success. So, if it ran and returned an “E” for error, that is still a successfully completed process because the report did run…
It’s like the old joke about the surgeon who told a patient’s family, “The operation was a success, but the patient died.”
This meant we needed to build our own report level error handling to capture the status of the report. This was a three-step process:
- Find the job status by inspecting the report to see the “E”
- Build a rule to check if it is an error
- Build conditional logic to call the custom error message to send to the user
With that piece of the puzzle in place, we could use built-in Orchestrator functionality to easily abort the report and stop the future reports from running.
Making Errors Happen Was the Hardest Part
The biggest challenge overall was trying to get reports to error so we could test and prove that the error handling worked. Ultimately, we succeeded and our client is now able to use the Orchestrator to handle all their scheduled reporting needs in the JDE.
Have a big job that’s right for the Orchestrator? Contact us to build a fast and affordable solution.