The Complete JDE Orchestrator Guide Part 1: Orchestrations
The Orchestrator is a powerful tool well worth taking some time to learn. When you know how all the pieces work, you can use it to streamline and automate a wide range of business processes. This new blog series covers the basic ins and outs of all the components and subcomponents--along with tips and tricks that will advance your knowledge and help you accomplish much more than you have before.
Starting at the Top in Orchestrator Studio
At the top of the hierarchy is the Orchestrations component. This is one of the two master components (the other is Notifications). In the coming weeks, we will look at all the subcomponents you can use to build an orchestration. First let’s look at what this top level component is and what it does.
The Orchestrator Is an API Factory
Orchestrations are API endpoints that can be called from any external application or put on a scheduler to run autonomously. Any REST enabled application can call an orchestration to push or pull data into or out of JDE.
An orchestration acts like a traffic system with four functions:
The orchestration itself doesn’t process the data, it simply directs (orchestrates) the movement. It serves as the container within which all the action happens.
Subcomponents Drive the Internal Workings of Each Orchestration
The actions within an orchestration are carried out by subcomponents. Each subcomponent has a transformation screen within which you can map orchestration inputs, prior step outputs, and system values to transform data and prepare it for the next step.
All steps are compartmentalized. You can mix and match and reuse them as often and however you like. For example, you can plug in a form request as a microservice early in the workflow and then use the same form request again at a later step or in a completely different orchestration!
Being able to track data in and out of each step and enter orchestrator inputs and prior step output as next step input is the magic that makes everything happen.
Orchestrations Now Have Many More Subcomponent Options
When it first became available, the Orchestrator Studio only offered service requests, rules, cross references, and whitelist options. “Service request” was originally only used for what is currently known as form requests. It then became an umbrella term for everything from data requests to reports, messages, connectors, and more. Thankfully, Oracle now presents each of these different types of components as top level menu options. This makes it easier to find and use the specific type of component you need to build your orchestration.
Today, there are 11 different subcomponents you can use to build orchestrations.
Form Requests | Data Requests | Cross References | Whitelists | Rules | Reports | Watchlists | Connectors/Connections | Messages | Custom Request (Groovy) | Schedules
Next, we’ll start exploring each of the different subcomponents, how to use them, and what they offer. First up is the popular and useful Form Requests feature.