Straight Through Process with Camunda BPM and Apache Camel

Forward

In this article I introduce straight though processing (STP), its relationship to business process management (BPM), and various associated technical details.

Source code at GitHub

Introduction

Straight through processing (STP) describes the automated and uninterrupted execution of services from beginning to end. The process “start” receives enough information so that each subsequent step can move forward with uninterrupted execution. Human intervention is not required.

Business Process Management Notation (BPMN) helps illustrate STP. And, with both concept and illustration we now have an established metaphor for communicating capability across both technical and non-technical audience.

Business Process Management Notation (BPMN) helps illustrate STP

Business Process Management Notation (BPMN) helps illustrate STP

 

Architectural Overview: Comparing Service Orchestration Without and With BPM

Without BPM:

Though lacking an illustrated process diagram, this architecture still provides STP.

(1) User makes request to web-app’
(2) Web-app’ forwards user-request to ReST service infrastructure
(3) Service infrastructure, or SOA, then breaks out request into a series of back-office service calls

Though lacking an illustrated process diagram, this architecture still provides STP

Though lacking an illustrated process diagram, this architecture still provides STP

 

With BPM:

So let’s make our design a little more interesting by adding BPM to help communicate our concepts and ideas. We’re working towards meaningful representation. And, BPM’s pattern of linking together tasks into composite process resonates – meaning that both developers and analysts (and even management) tend to grasp this message.

Tasks, as building-blocks, can be assembled/re-assembled into composites representing business functions.

Let’s review the new architecture with a focus on the new BPM layer:

(1) Service Layer (SOA) makes a single request to BPM
(2) BPM orchestrates communication with back-office systems
(3) BPM returns results

Tasks, as building-blocks, can be assembled/re-assembled into composites representing business functions

Tasks, as building-blocks, can be assembled/re-assembled into composites representing business functions

 

Reference Implementation

Focusing on Business Services integration with our BPM layer. Java code example demonstrates Camunda BPM integration and omits back-office integration (keeping it simple).

(1) Service Layer (SOA) makes a single request to BPM
(2) BPM prepares a response
(3) BPM returns results

Java code example demonstrates Camunda-BPM integration and omits back-office integration

Java code example demonstrates Camunda-BPM integration and omits back-office integration

 

Adding Asynchronous Behavior

The above example works fine no matter the number of tasks within our process. But, I’ve noticed that all our process variables may not be returned, via the above illustrated example, if we configure a task for asynchronous behavior. This is reasonable given the context of model as it launches new threads during the course of execution.

To get all of our process variables back at the end of an asynchronous process we add the request-reply pattern. And, Apache Camel provides both excellent documentation and implementation to suit our needs.

Our ReST API is now launching our Camunda process via the Camel conext and route defined. The camel route uses WildFly’s new built-in Artemis JMS implementation to first start the process and then return results.

Let’s review the new architecture:

(1) Service Layer (SOA) sends request (message), via Camel component, to the queue: JmsBpmStartQueue
(2) Camel picks up the message and starts the BPM process via a managed bean
(3) BPM orchestrates communication with back-office systems
(4) BPM returns results to the JmsBpmStartQueue
(5) Camel forwards message back to top-level Service (JAX-RS)

To get all of our process variables back at the end of an asynchronous process we need to include the request-reply pattern

To get all of our process variables back at the end of an asynchronous process we need to include the request-reply pattern

 

Reference Implementation showing Apache Camel

(1) Service Layer (SOA) sends request (message), via Camel component, to the queue: JmsBpmStartQueue
(2) Camel picks up the message and starts the BPM process via a managed bean
(3) Bean starts BPM Process
(4) BPM returns results to the JmsBpmStartQueue
(5) Camel forwards message back to top-level Service (JAX-RS)

NOTE: Round-trip takes about 127ms (measured from HttpRequester)

Async STP via Apache Camel

Async STP via Apache Camel

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments are closed.