Orchestrator

This section describes the functions of the TIBCO Order Management Orchestrator component.

Orchestrator is a Java-based component, which by default runs in standalone mode. This simplifies the deployment and administration. The Java implementation of the Orchestrator is multi-threaded, which improves performance.

Orchestrator communicates with Automated Order Plan Development using RESTful services.

Orchestrator and southbound systems can communicate by using the following modes:

The ASYNC, SYNC_CONFIRM, and SYNC_NOCONFIRM modes are based on the RESTful concept. The JMS mode uses Java Message Services.

Note: Any type of break such as SUSPENSION or AMENDMENT, is not supported in SYNC_CONFIRM and SYNC_NOCONFIRM modes of Orchestrator.

ASYNC: Orchestrator invokes a RESTful API exposed by the southbound system (for example: Processcomponent). The southbound system receives the request, determines that the acknowledgment mode is ASYNC and initiates asynchronous processing of the request, and returns a response to the Orchestrator. After the request is processed by the southbound system, it invokes an API exposed by Orchestrator corresponding to the request that was received by it.

SYNC_CONFIRM: Orchestrator invokes a RESTful API exposed by the southbound system (for example: Processcomponent). The southbound system receives the request, determines that the acknowledgment mode is SYNC_CONFIRM, processes the request synchronously, invokes a response API exposed by Orchestrator corresponding to the request that was received by it and after its completion, returns a response to the Orchestrator for the request.

SYNC_NOCONFIRM: Orchestrator invokes a RESTful API exposed by the southbound system (for example: Processcomponent). The southbound system receives the request, determines that the acknowledgment mode is SYNC_NOCONFIRM, processes the request synchronously, and returns a response to the Orchestrator for the request.

JMS: Orchestrator sends various requests to southbound systems to be sending messages to the corresponding queues. The messages are then processed by southbound systems and the responses are sent to the reply queues.

In the request for all the modes, Orchestrator includes some headers, which are expected to be included in the response headers as well.

  • acknowledge: The communication mode. To be used by the southbound system to determine the processing semantics.
  • parent: The parent of the request. Used for SYNC_CONFIRM mode. It is copied while invoking the response API of Orchestrator.
  • duplicate: Used to determine if the request is an original request, a duplicate request, or a possible duplicate. The possible values are POSSIBLE, FALSE, and TRUE.