Orchestrator
Orchestrator receives orders from OMS. Then Orchestrator executes a series of tasks in a defined order.
Orchestrator interacts with several other components to store orders, to create plan specifications. Orchestrator is also responsible to communicate with external systems (process components).
Orchestrator is responsible for the following:
- Manage the overall order lifecycle.
- Store the order in cache.
- Optionally determine order feasibility by sending the order to a Feasibility Provider which returns the result back to Orchestrator.
- Develop a plan for fulfilling the order by sending the order to AOPD which returns the plan specification.
- Use this plan specification to create the execution plan for an order.
- Store the plan in cache.
- Interpret the execution plan and coordinate order fulfillment by invoking the correct Process Components in the correct order.
- Update the order status to complete in the cache at the end of the order lifecycle.
When OMS sends an order, submitted by an external system, to the Orchestrator, the order may refer to several products.
For each ordered product, a series of plan items must be completed sequentially for that product to be provided. The Product Catalog maintains the link between product and plan item. Orchestrator receives the requests for order fulfillment. Orchestrator component in turn sends the order to AOPD to analyze the order and the Product Catalog, and determines the plan of action to fulfill the order. Orchestrator then uses this plan to reach the goal by invoking the process component associated with each plan item in the defined sequence to fulfill an order. For details, see TIBCO Fulfillment Order Management Administration Guide.
The actual fulfillment of the product happens by invoking the process component - typically implemented as Fulfillment Provisioning cartridges or the BPM workflow processes - described by the plan fragment assigned to the product in the Product Catalog. The invocation of the process components in a specific sequence and at specific time is known as the order orchestration, which is done by the Orchestrator.
Management Orchestrator receives AOPD-generated execution plan for order orchestration. It has one to many inter-dependent plan items, which typically maps to the order lines in the order. See figure Order and Execution Plan.
There can be one-to-one, one-to-many, or many-to-one relationships between the order lines and the plan items based on the Product Catalogue modeling.
- In case of Affinity between two products, the two order lines requesting these two products have a single plan item in the execution plan, to fulfill the product products simultaneously.
- In case of a bundled product comprising of sub-products and services, the order line requesting this product have multiple plan items in the execution plan, one corresponding to each sub-product or service.
A plan item contains the process component which has to be invoked for the fulfillment of a particular product. AF Orchestrator invokes the process components and starts executing the plan contained in the plan items according to the dependencies between them. The execution plan, and hence the order is considered to be COMPLETE or FULFILLED once all the process components corresponding to the plan items are executed successfully.
The high level relationships between the order and plan entities are shown in the following figure:
Plan item, Plan fragment, and Process Component are inter-related concepts.
Here is the brief description of each of these concepts:
- Plan Item is one of the steps in a plan that must be executed to reach the goal of fulfilling an order line, and eventually the order. The plan item is configured with the name of the Process Component, which must be invoked to fulfill a product. The name of the Process Component is provided by Fulfillment Order Management AOPD during plan development, and gathered from the Product Catalogue using the name of the product.
- Plan Fragment is the model definition of a Process Component, which fulfills a particular product. Products are linked to plan fragments in the Product Catalogue. The name of a plan fragment is the same as the name of the Process Component that it describes.
- Process Component is the physical implementation of the tasks required to fulfill a product. It is described by a plan fragment and invoked as a plan item step in a plan.