Event Process Orchestration

Scenario ID¶

Triggered by an event, small in size, one to many (1-n) where the order of the underlying interfaces matters and completion needs to be tracked.

A typical scenario is where an order or business transaction is orchestrated through a certain fulfillment process.
The flow often starts from an order in a GUI or from B2B. A BPM or work-flow enabled interface tool manages the order until fulfilled, often while sending statuses back to the ordering system.
If the orchestration is completely automated and relatively simple, this is a good case for pattern A2PESB-WF.
If the orchestration is completely automated, medium complexity and/or long-running (>10 minutes), it requires A2PESB-DB.
If orchestration is complex, and/or requires human interaction for exceptions and monitoring, there is an option to build an application for this: A2PAPP or in the integration layer, a BPM enabled integration tool would be preferred, A2P-BPM which to some extent becomes an application itself.

Consider modern BPM tools for application rationalization; to improve monitoring and control and simplify the interface situation by simply having fewer systems and fewer places where data is stored. The BPM tool and data-store is used both for automated processing and for service desk and branches to manage issues.
BPM tools can now handle non-linear process (or Adaptive Cases) where certain steps in a process are not necessarily always followed in the same sequence. This provides the flexibility to support processes whose execution path cannot be fully defined until the process actually begins on a case by case basis.