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 understand how data from these devices can be used by JD Edwards EnterpriseOne applications.

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 each of the XML files used in the orchestration as described in the next chapter, "Configuring an Orchestration".

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 IoT Orchestrator, Company A can design 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 configure the rules XML as described in the Section 4.3, "Configuring Rules XMLs" 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 Information for the Orchestration

This process entails 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 the cross-reference XML as described in the "Configuring Cross-Reference XMLs" section in this guide.

Also, in this phase you can decide if you want to incorporate a white list into the orchestration by configuring a white list XML as described in the "Configuring White List XMLs" section in this guide.

Example: Company A's Cross-Reference Analysis

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

  • 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. You identify 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 IoT data into another database.

Use the information gathered from this phase of the analysis to design the services request XMLs as described in the "Configuring Service Request XMLs" 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.