Error Handling in the Orchestrator

No system is perfect. Whether it’s a problem caused by an external data source that’s unreachable or a workflow that was broken by a software update, your orchestrations need to be set up to handle errors correctly. 

The Orchestrator Has Great Error Handling Capabilities

In newer versions of the Orchestrator, you have the flexibility to take all kinds of actions inside an orchestration:

• Track errors on any step in the orchestration (including form requests). It’s the fourth button on any component in the orchestration.
  
  
• Define what happens next (continue or abort). With a step in the orchestration that’s really not essential, you can click the continue option. If it’s a prerequisite for a later step or necessary for the successful completion of the orchestration, you can click the abort option. You can also undo what’s already been done up to that point by calling another orchestration to undo what has been done.
  
  
• Configure the orchestrator to send out custom error messages. You can define what you want the error text to say. For example it might read, “Update advanced pricing failed while expiring existing records.” 

Let’s explore the example of pricing records. 

When adding a new pricing record, the first step is to expire the old records. So, if there is an error with the addition of the new record, we need to create an orchestrator to reverse the expiring process already completed. 

We do that by calling another Orchestration to update the expiration date with the original value. You can also assign an orchestration notification related to the error. We can map inputs or outputs from previous steps and use the results of what has already happened to take corrective action. 

Messages and Notifications for Error Handling

Messages are built into the orchestration itself as a sub-component and proactively send a  message to the user when an error occurs. Notifications are a master component that uses the subscription framework inside JDE. It only sends notifications to subscribers. You can use either function to communicate with users about errors. For a deeper dive on this topic, explore the blog post on Messages and Notifications in JDE Orchestrator.

The Benefit of Internal Error Handling

Sometimes, our clients use the Orchestrator as an integration tool by calling orchestrations from an external data source. Before the current level of error handling in the newer versions of JDE, it was difficult to manage errors due to limited Orchestrator functionality. With today’s built-in error handling, you have full access to all Orchestrator components and JDE itself. You can track errors, take corrective action, and leverage the internal subscription framework for notifications.

What if you are using an older version of JDE? How does error handling work for reports when the JDE doesn’t quite get the job done? There are usually still ways to build what you need with the Orchestrator and some Groovy script. 

See a use case where we did that for a client here.

If you have a tough or interesting use case for error handling, we want to hear about it. Contact us to share your challenges.