Workflow Patterns

Workflow Patterns

The eiConsole XML Workflow’s Process Orchestration Module allows for the Implementation of any number of Synchronization and State Based Workflow Patterns

In the previous sections we discussed how the eiConsole’s XML Workflow/BPM component handled XPath Routing, Batch Splitting and other aspects of implementing an XML workflow within a given eiConsole “route”. Here we’ll explore how it handles Workflow Patterns / Process Orchestration.

Routes can also be chained together into more sophisticated business process models and data flows. The RouteToRoute Transport is used to sequence multiple routes within a given interface.

Here we see a sample RouteToRoute Transport configuration from our example interface. Unlike other connectivity adapters, this transport moves data within the system, from the current route to the next in the desired workflow. The next route in the interface is identified by the name of one of its Listeners. In this case, that Listener is “Step2A-Listener”.

XML Process Orchestration Transport Configuration panel

This listener is defined as a “Programmable” Listener in the next route:

XML Process Orchestration Listener Configuration Panel

Perhaps most interestingly, the Process Orchestration Transport and its corresponding Process Orchestration Listener, allows us to merge asynchronous transactions. In other words, it can serve as a rendezvous point for data arriving from different sources.

Consider a scenario where we need a piece of “Fish” data and a piece of “Shark” data to arrive independently and be merged into a single transaction. To accomplish this, a Process Orchestration Listener is configured to wait for the Fish and Shark data:

XML Process Orchestration Listener panel

Then, in two different routes – a Process Orchestration Transport is defined to submit the corresponding components to the process.

XML Process Transport Configuration

As components of the data flow or business process are submitted, the Process Orchestration Listener evaluates its firing conditions. Essentially, it is checking to see if both defined “pieces of the puzzle” have arrived. When they have, processing will continue as configured.

In this example, we are looking for named components of the business process and aggregating those pieces when they arrive. However, the modules support a plethora of synchronous and state-based process orchestration patterns.

TAKE A TOUR

XML WORKFLOW NEXT STAGE >> XML PIPELINE

NEXT STAGE>> TRANSACTION MONITORS

This is a unique website which will require a more modern browser to work! Please upgrade today!