Orchestrator
This section describes the functions of the Orchestrator component ofTIBCO Order Management.
Orchestrator is a Java based micro-service and it can be easily scaled up and down behind a load balancer. This approach simplifies the deployment and administration. The Orchestrator's Java implementation is multi-threaded, which improves performance.
The Orchestrator communicates with the Automated Order Plan Development component using RESTful APIs.
Orchestrator and southbound systems can communicate by using the following modes. This mode can be set in Orchestrator's defaultAckMode
property. The modes are as follows:
REST: Orchestrator invokes a RESTful API exposed by the southbound system (for example: Processcomponent). In the Orchestrator, when the default acknowledgment mode is set to REST, the Orchestrator invokes the planitem/planItemExecuteRequest
endpoint implemented by the processcomponent. When you use the acknowledgment mode as REST, the Orchestrator expects the processcomponent to implement RESTful APIs and expose the following endpoints:
-
* /pqf
-
* /planitem/suspendrequest
-
* /planitem/milestonerelease
-
* /planitem/executionrequest
-
* /planitem/errorhandlerrequest
-
* /planitem/activaterequest
-
* /plan/opdErrorHandlerRequest
-
* /feasibility
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. The corresponding REST endpoints are exposed by the Orchestrator and are used by the process-component. The RESTful endpoints are as follows:
-
* /v1/order/preQualificationFailedReply
-
* /v1/planitem/suspendreply
-
* /v1/planitem/milestonenotify
-
* /v1/planitem/executionreply
-
* /v1/planitem/errorHandlerreply
-
* /v1/order/feasibilityReply
-
* /v1/plan/error
MESSAGING: When the default acknowledgment mode is Messaging, the Orchestrator sends the outbound notification for the processcomponent over Messaging. There are various categories of notifications that Orchestrator sends over different queues.
Message Type | Queue Name |
---|---|
FeasibilityRequest | tibco.aff.orchestrator.provider.order.feasibility.request |
PlanItemExecuteRequest | tibco.aff.orchestrator.planItem.execute.request |
PlanItemFailedRequest | tibco.aff.orchestrator.provider.planItem.failed.request |
PreQualificationFailedRequest | tibco.aff.orchestrator.provider.order.prequal.failed.request |
PlanItemActivateRequest | tibco.aff.orchestrator.planItem.activate.request |
PlanItemSuspendRequest | tibco.aff.orchestrator.planItem.suspend.request |
MilestoneReleaseRequest | tibco.aff.orchestrator.planItem.milestone.release.request |
OPDRequest | tibco.aff.orchestrator.provider.order.opd.request |
The processcomponent listens on the respective queues and processes the notifications that are sent by the Orchestrator. Once processed, the processcomponent replies on the following queues.
Message Type | Queue Name |
---|---|
FeasibilityReply |
|
MilestoneNotifyRequest |
|
OPDReply |
|
PlanItemExecuteReply |
|
PlanItemFailedReply |
|
PlanItemSuspendReply |
|
PreQualificationFailedReply |
|
All failed replies from the southbound system are sent to orchestratorInboundQueueDead
queue instead of individual queues.
In the request for all the modes, the Orchestrator includes specific headers in its requests, which are expected to be included in the response headers.
- acknowledge: The communication mode used by the southbound system to determine the processing semantics.