3 Designing an Orchestration

This chapter contains the following topics:

3.1 Understanding the Orchestration Design Process

You might already have a business process in EnterpriseOne that involves manually entering data into EnterpriseOne from a device that collects data. Or you might use a non-EnterpriseOne system to record data from various devices. Or you might not yet understand how data from these devices can be used by JD Edwards EnterpriseOne applications. Because the Orchestrator can accept data from any source that can send a REST call, it does not matter if the data is coming from an IoT device, an external system, or even from another EnterpriseOne application. This chapter uses an IoT device as an example, but regardless of where the input is coming from, your design process is the same.

Before you can create an orchestration, you need to perform an analysis to:

  • Identify the problem and the solution.

  • Identify the data that you want to collect.

  • Define the rules and conditions that determine how to process the data.

  • Identify the EnterpriseOne application inputs (fields and grid columns).

  • Identify additional applications in which to work with the data, such as a custom Java application to perform a specific business process or a process for storing the data in another database.

You can use a simple worksheet for your analysis or you could use a storyboard, flow chart, or a combination of methods depending on the complexity of your orchestration. Use the information captured from your analysis to configure orchestrations in the Orchestrator Studio as described in .

Example: Company A's Orchestration Design Process

Company A used a storyboard as part of their orchestration design process to illustrate the design of a simple orchestration. Figure 3-1 shows an illustration of the overall result of Company A's design process. The remaining sections in this chapter contain additional details about each part of the design process and examples of how Company A identified the information required for the orchestration.

Figure 3-1 Example of an Orchestration Design Process

Description of Figure 3-1 follows
Description of ''Figure 3-1 Example of an Orchestration Design Process''

3.2 Identifying the Problem and Solution

Begin the analysis by identifying the problem or the data gap, and then identify how you want to use the data in EnterpriseOne, or in other words, determine which EnterpriseOne business process or transaction you want to invoke.

Example: Company A's Problem and Solution

Problem

Company A currently uses sensors to detect issues in certain assets to prevent potential breakdowns. Specifically, the company uses vibration and temperature sensors on various pieces of equipment. The data read from the sensors is not tied into their EnterpriseOne system; instead, it is integrated with a third-party software program that an operations manager has to access several times a day to monitor equipment. It would be ideal if the company could eliminate the need to use a disparate software program to manually oversee the performance of its equipment.

Solution

Company A wants to design a process that uses the EnterpriseOne Condition-Based Maintenance program for monitoring. With the Orchestrator Studio, Company A can create an orchestration with rules and conditions that:

  • Invoke a transaction in EnterpriseOne Condition-Based Maintenance that sends a warning message if vibration or temperature levels are within a certain range above normal operating levels.

  • Invoke a transaction in EnterpriseOne Condition-Based Maintenance that sends an alarm message if vibration or temperature levels exceed a certain level.

3.3 Identifying the Data for the Orchestration

After you identify the problem and determine the EnterpriseOne applications or processes that you want to invoke, you need to identify the device data or payload to use in the orchestration. For example, a reading from a sensor might include a vibration measurement, a temperature measurement, and the date and time of the readings.

Example: Company A's Data Analysis

The "Input - Data" area in Figure 3-1 highlights the data that Company A identified for their orchestration.

3.4 Identifying the Rules for the Orchestration

Next, identify the rules and conditions to determine how to process data from the sensors.

You will use the information from this part of the analysis to create a rule for the orchestration as described in the Creating a Rule section in this guide.

Example: Company A's Rules Analysis

In this part of the analysis, Company A identified the following conditions:

  • A vibration reading greater than or equal to 90 and a temperature greater than or equal to 250 will trigger an alarm message.

  • A vibration reading greater than or equal to 30 and a temperature greater than or equal to 520 will trigger an alarm message.

  • A vibration reading greater than or equal to 60 will trigger a warning message.

  • A temperature reading greater than or equal to 350 will trigger a warning message.

The "Rules" area in Figure 3-1 shows the rules and conditions that Company A is using to determine which data should be processed by the orchestration.

3.5 Identifying the Cross Reference and White List Information for the Orchestration

Identifying cross references involves identifying and mapping each piece of data to a value or data item in an EnterpriseOne form field or grid column.

Use the information from this part of the analysis to configure cross references for an orchestration as described in the Creating a Cross Reference section in this guide.

Also, in this phase you can decide if you want to incorporate a white list. A white list provides an additional security layer for the orchestration by allowing data from only the devices defined in the white list. See the Creating White Lists section on how to set up a white list.

Example: Company A's Cross Reference Analysis

Company A used this phase of the analysis to map the following inputs to EnterpriseOne fields:

Input EnterpriseOne Field
sensor ID equipment number|measurement location
equipment number warning recipient|alarm recipient

The "Cross Reference" area in Figure 3-1 highlights the cross references Company A is using in the orchestration.

3.6 Identifying the Service Request Information for the Orchestration

Next, you need to identify how the data is used to invoke a business process or transaction in EnterpriseOne. This involves identifying the EnterpriseOne applications and inputs including the control IDs for EnterpriseOne buttons, fields, and so forth.

You can also determine if you want to use custom Java to execute a custom process or to route data into another database.

Use the information gathered from this phase of the analysis to design the service request for the orchestration as described in the Creating a Component section in this guide.

Example: Company A's Service Request Analysis

The "Service Request" area in Figure 3-1 highlights the data Company A is using for the service request.