Process Component Technology Selection

Process components might be implemented in any JMS-enabled technology that conforms to the interface specification in the product documentation.

Generally speaking process components can be classified by using a combination of the duration of the process component lifecycle and a description of the statefulness.

Process component duration defines how long it takes to execute all tasks in the plan item. There is no absolute number that defines a short vs. long-lived process component. Instead the duration defines whether or not the task can be amended in-flight:

  • Short-lived – an in-flight process cannot be amended. When suspended by Orchestrator the process runs to completion and returns a complete response.
  • Long-lived – an in-flight process can be amended. When suspended by Orchestrator the process might either run to completion and return a complete response, or it might suspend execution and return a suspend response. If a suspend response is returned, it must handle an activate request from Orchestrator later to resume execution.
  • Process component statefulness defines whether or not a process component needs to persist state internally during the life of an invocation. This does not include storing data by using Order Management Server data service interfaces, which is available for all process components. Instead, the determining requirement is whether or not state is stored directly within the process component:
    • Stateless – short-lived process component that is invoked and does not require state persistence.
    • Stateful – short or long-lived process component that is invoked and does require state persistence.

The choice of stateless or stateful process component is not necessarily determined by whether the backend systems being invoked are synchronous or asynchronous. Asynchronous backend system invocation is a common use case for stateful process component. However, it might be possible to pass a correlationID through the backend system that lets the use of a stateless process component. Consequently, a process component is defined as a logical entity that provides a given set of functionality. It does not necessarily translate directly into a single physical process that is invoked and runs to completion.

If a process component requires manual interaction then it is in almost all cases be defined as stateful.

Technology Recommendations based on Requirements

Some technology recommendations for a given set of conditions are as follows:

Requirement

Technology

Short lived process that does one or many synchronous invocations to back-end systems.

BusinessWorks

BusinessEvents

Short-lived process that does one or many synchronous and/or asynchronous invocations to back-end systems. The back-end system accepts a correlation ID that comprised of the combination of orderRef and planItemID.

BusinessWorks

BusinessEvents

Short-lived process that does one or many asynchronous invocations to back-end systems.

BusinessWorksBW6

Java

Short-lived process that does one or many synchronous and/or asynchronous invocations to back-end systems. The back-end system accepts a correlation ID but cannot be comprised of orderRef and planItemID.

BusinessEvents

Long-lived process that does one or many synchronous and/or asynchronous invocations to back-end systems with no manual interaction.

BusinessEvents

Long-lived process that does one or many synchronous and/or asynchronous invocations to back-end systems with at least one manual interaction.

iProcess

Long-lived process that does one or many asynchronous invocations to back-end systems.

Java