Process Components

This component can be implemented in a variety of technologies depending on the required functionality. Typically this will be TIBCO Fulfillment Provisioning (FP).

All Process Components must adhere to the service contract specified by Orchestrator in order to be considered a valid Process Component. This means implementation of three types of request events and providing two types of responses. These components should be accessed via standard JMS event interface wherever possible. Individual Process Components should be stand-alone components which allows for changing the Process Component collection dynamically in real-time without requiring an order management outage.

All external component integrations will be through the Process Components component. These integrations will generally either be service calls to perform automated tasks, or callouts to start a manual workflow.

The integration pattern for automated service calls will take the form of Process Components sending out an event to an adapter layer which will include relevant order and order line data as requested from the cache. This adapter layer will then transform the data into the format required by the back-end service and then invoke that service. When it has completed it will send a response back to Process Components to complete the step in the flow.

Process Components are responsible for the following:

  1. Implement the tasks required to fulfill a particular product on an order. This may be done in any JMS-enabled technology provided the interface specification for a Process Component is satisfied.
  2. Accept requests from Orchestrator to start executing a new fulfillment process.
  3. Request required information from the cache that is required as part of a fulfillment process.
  4. Execute the required business process for fulfilling a particular product that a customer may order. This may take the form of invoking back-end service calls, business process management, or manual tasks as appropriate for the implementing technology.
  5. Update information in the cache as part of the fulfillment process if required.
  6. Return the execution results to Orchestrator.
  7. Suspend execution of a fulfillment process when requested by Orchestrator. Respond to the suspend request by returning to Orchestrator confirmation of a successful suspend or normal completion of the fulfillment process.
  8. Resume execution of a suspended fulfillment process when requested by Orchestrator through to completion from the point of suspension.
  9. Cancel execution of a suspended fulfillment process when requested by Orchestrator. The tasks following the point of suspension are not executed. Cancellation may require rollback of previously completed tasks in the fulfillment process, or a simple abort of the execution process.