This chapter contains the following topics:
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 .
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.
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.
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.
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.
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.
The "Input - Data" area in Figure 3-1 highlights the data that Company A identified for their 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.
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.
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.
Company A used this phase of the analysis to map the following 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.
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.
The "Service Request" area in Figure 3-1 highlights the data Company A is using for the service request.