1. Orchestrator Guide
  2. How It Works

How It Works

When you create and save an orchestration in the Orchestrator Studio, it automatically becomes a published REST service. The name of an orchestration is used to define an endpoint on the AIS Server. The endpoint URL is

http://<AIS_server>:<port>/jderest/orchestrator/<orchestrationname>

To invoke an orchestration, calling applications or devices use a post operation to this URL, where <orchestrationname> is the name of your orchestration. The post operation must include security parameters that enable access to the orchestration and any EnterpriseOne application invoked by the orchestration. See Orchestration Security Considerations for more information.

The following illustration shows how the EnterpriseOne Orchestrator processes orchestrations. This illustration depicts an orchestration that includes rules, cross-references, form requests, and a connector to a notification.

EnterpriseOne Orchestration Processing

An external client, which might be a third-party application, a Cloud service, an IoT device, a mobile application, the Scheduler, or anything that is capable of sending a REST request, will invoke the orchestration by its endpoint address and provide the necessary inputs in the body of the REST request.

You can use the following Orchestrator components as building blocks in any order and in any combination to create orchestrations that are as simple or complex as your service requires.

  • Orchestration. An orchestration is the high-level object that defines the name of the orchestration (the REST endpoint), the inputs, the outputs (REST response), and the order and structure of the other components listed below.

  • Service request. A service request is a general term for an orchestration component that provides some actual service or "work." As such, service requests are the essential components of an orchestration. The types of service requests are listed below.

    • Form request: A form request invokes one or more EnterpriseOne application forms. You use this type of request to automate EnterpriseOne applications. You can create a form request in the Orchestrator Studio, or you can use the Process Recorder to record your actions in EnterpriseOne and then edit the resulting form request in the Orchestrator Studio. Form requests can use EnterpriseOne applications to read data and also to write data back to EnterpriseOne tables just as a human user would.

    • Data request: A data request reads data from any EnterpriseOne table or business view. You can provide inputs into a data request so that it performs certain steps, for example to filter data, and return back data sets (arrays) or aggregations such as sums or averages. Data requests are read-only components.

    • Report: A report request will run any EnterpriseOne report (UBE). You can specify inputs, for example, the report version, data selection, and data sequencing. The report will execute as if a human user had submitted the report in EnterpriseOne. The report request can return the server and job number of the report for use in subsequent orchestration steps.

    • Watchlist: A Watchlist request will return all the information that is available about a Watchlist, including the number of rows (that is, the number that is shown in the badge of a Watchlist), whether that number has triggered a warning or critical threshold, and other Watchlist parameters.

    • Connector: Orchestrations can invoke other orchestrations or notifications. A connector request is used as the step within a main orchestration to invoke another orchestrations or notifications. Connector requests are also used to invoke external REST services, external databases, and File Transfer Protocol (FTP) sites for sending and receiving documents.

    • Custom request: A custom request enables you to use the Groovy scripting language or Java to create an orchestration step that performs any service that you can conceive and develop.

    • Message: A message request allows you to send an e-mail message to one or more recipients. You can create the subject and body of the message, including text substitution variables that are populated from previous orchestration steps. The message can include links to EnterpriseOne applications, links to external URLs, links that launch other orchestrations or notifications, and attachments.

  • Rule. A rule contains a set of conditions against which the orchestration input or values from orchestration steps are evaluated to produce a true or false state. Rules can be nested to produce complex evaluations. Rules determine how the orchestration is processed at runtime. You can also build custom rules using Groovy or Java that enable you to define complex rules..

  • Cross reference. A cross-reference is a set of data relationships defined by the designer of the orchestration that enriches the minimal input from devices. For example, the serial number of a device can be cross-referenced to an EnterpriseOne equipment number for use in service requests.

  • White list. A white list is an initial rudimentary pass or fail check of the incoming message's device signature of the incoming message against a predefined list of signatures. A white list provides an additional layer of security to the Orchestrator security..

  • Schedule. A schedule is a definition of the frequency at which an orchestration or notification will automatically run. A schedule is its own user defined object, enabling you to reuse common schedules, such as "once per day" or "once per hour." The Orchestrator Studio enables you to define simple schedules easily. You can also use the CRON syntax to define more complex schedules, such as "every Monday at 8:00 am."