Skip to content
110 Springfield Ave. | Berkeley Heights, NJ 07922
Back to blog

The Complete JDE Orchestrator Guide Part 1: Orchestrations

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:

  1. Defining inputs
  2. Defining outputs
  3. Defining the type and order of subcomponents
  4. Defining how data maps into and out of the subcomponents

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.

Get a sample chapter from ACBM Solutions' Orchestrator Training manual

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.

See Next Part

Leave a Comment

Back to Blog

Subscribe To ACBM Solutions Blog