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

tibco.aff.orchestrator.provider.order.feasibility.reply

MilestoneNotifyRequest

tibco.aff.orchestrator.planItem.milestone.notify.request

OPDReply

tibco.aff.orchestrator.provider.order.opd.reply

PlanItemExecuteReply

tibco.aff.orchestrator.planItem.execute.reply

PlanItemFailedReply

tibco.aff.orchestrator.provider.planItem.failed.reply

PlanItemSuspendReply

tibco.aff.orchestrator.planItem.suspend.reply

PreQualificationFailedReply

tibco.aff.orchestrator.provider.order.prequal.failed.reply

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.