Last week Apache Camel v2.16 was released with over 600 issues resolved (bug fixes, updates and new features). Claus blogged about top 10 highlights already and here I want to briefly show you a use case about my tiny contribution in this release: camel-jbpm component.
This component is intended to make integration with jBPM (a Business Process Management Application) easier. It uses Remote Java API and basically does REST calls to jBPM to manage business processes (start, stop, abort), execute Business Rules, manage Human Tasks, etc. So rather than manually creating a REST client or using Remote API, you can use the Camel component. The remote API provides also HornetQ based integration, but I've dropped out that part from the Camel component as it didn't play nicely with OSGI.
In the sample use case (which is inspired by a real one) there is an integration application based on Camel that runs on JBoss Fuse which is supposed to do real time integration. And whenever an error occurs in the integration route, the error details are sent to jBPM for evaluation and review by human being if necessary. To demonstrate that I've created two separate projects:
The Camel route below is self explanatory, there is a route that generates 10 exceptions with half a second delay each and an error handler that catches those exceptions and sends them to jBPM. Notice that it also populates CamelJBPMParameters header with the details about the error.
You can find the sample code on github with instructions about how to build and run it on Fuse.
The second part of the demo consist of a jBPM process that receives the errors and processes them. The BPMN2 diagram of the process is below:
The process have input parameters matching the values from CamelJBPMParameters header. In the first step it initializes a RequestQualifier object that is marked as non-critical. In the second step we use Drools and Complex Event Processing to qualify errors. The idea with CEP is that we want to mark an error as critical only if there were more than 5 errors in 10 seconds time window. Also to prevent marking multiple errors as critical and flooding the system with Human Tasks, we limit it to only 1 critical error at most in 10 minutes interval. All these conditions are written in Drools as following:
Once the request with the error details has been qualified (as critical or not), we use that information to do conditional routing. All non critical errors are logged and the business processes complete as there are no further action defined for them. We can see the full list of completed processes and error related information in the following screen shot:
On the other branch of the business process, if an error has been marked as critical, we do create a Human Task and the process stops at this point. This requires a user to assign the task and take some actions. Once the Human task is claimed and completed, then the business process continues and completes in the next step.
From the ten error messages generated in quick succession, only one is qualified as critical and generates Human Task and the remaining nine gets logged and completed as expected.
The business process project with instructions on how to deploy it to jBPM is on github too.
This component is intended to make integration with jBPM (a Business Process Management Application) easier. It uses Remote Java API and basically does REST calls to jBPM to manage business processes (start, stop, abort), execute Business Rules, manage Human Tasks, etc. So rather than manually creating a REST client or using Remote API, you can use the Camel component. The remote API provides also HornetQ based integration, but I've dropped out that part from the Camel component as it didn't play nicely with OSGI.
In the sample use case (which is inspired by a real one) there is an integration application based on Camel that runs on JBoss Fuse which is supposed to do real time integration. And whenever an error occurs in the integration route, the error details are sent to jBPM for evaluation and review by human being if necessary. To demonstrate that I've created two separate projects:
- A Camel project that runs on Fuse, handles any exception and sends the details to jBPM
- A Business Process project that runs on jBPM, classifies the errors using Drools and Complex Event Processing and creates Human Tasks if the error is critical.
The Camel route below is self explanatory, there is a route that generates 10 exceptions with half a second delay each and an error handler that catches those exceptions and sends them to jBPM. Notice that it also populates CamelJBPMParameters header with the details about the error.
You can find the sample code on github with instructions about how to build and run it on Fuse.
The second part of the demo consist of a jBPM process that receives the errors and processes them. The BPMN2 diagram of the process is below:
The process have input parameters matching the values from CamelJBPMParameters header. In the first step it initializes a RequestQualifier object that is marked as non-critical. In the second step we use Drools and Complex Event Processing to qualify errors. The idea with CEP is that we want to mark an error as critical only if there were more than 5 errors in 10 seconds time window. Also to prevent marking multiple errors as critical and flooding the system with Human Tasks, we limit it to only 1 critical error at most in 10 minutes interval. All these conditions are written in Drools as following:
Once the request with the error details has been qualified (as critical or not), we use that information to do conditional routing. All non critical errors are logged and the business processes complete as there are no further action defined for them. We can see the full list of completed processes and error related information in the following screen shot:
On the other branch of the business process, if an error has been marked as critical, we do create a Human Task and the process stops at this point. This requires a user to assign the task and take some actions. Once the Human task is claimed and completed, then the business process continues and completes in the next step.
From the ten error messages generated in quick succession, only one is qualified as critical and generates Human Task and the remaining nine gets logged and completed as expected.
The business process project with instructions on how to deploy it to jBPM is on github too.