This article was originally published on Diabolical Labs.

Back in the early days of “workflow” we had control of the transaction, usually a document, from the start of the process to the end. As IT evolved into the SOA/ESB era, we had a little bit less control but for the most part the process engine orchestrated everything.

There were frequent hand-offs to message queues but normally the message would come back to the process engine so it would continue to orchestrate the process.

The microservice world is different. Instead of having a process engine or an ESB controlling a small number of large services, we have many small services that can potentially send and receive messages or respond to events from any of the other services.

It’s more like a web. One initiating message or event to a particular service could affect the exchange of many hundreds of messages between the microservices before the initial request is considered complete. That can make BPM practitioners a bit uneasy due to the loss of control.

We may not have control any longer but we still can have visibility into the process. We can still apply our usual patterns for SLA and exception management, and human and compensating workflows. This can be accomplished through what I call a “tracking” process.

I have a process running today that interacts with microservices written with the microservices framework, Vert.x.

Vert.x includes an Event Bus and a cluster manager, among other features. A Vert.x cluster is made up of one to many nodes. A microservice is packaged as a jar module that includes a number of what they call Verticles (British spelling I guess). The verticles are deployed to any number of Vert.x nodes.

Once the verticles are deployed, the Event Bus manages the flow of messages and responses throughout the cluster. This all happens asynchronously, so there is no way us to control that flow from the process manager.

We can still create a process in BPMN that looks like the traditional process. Here is an example.

Opportunity Intake Process
Opportunity Intake Process
This is a simplified version of a real process that’s been running for a couple of years on Vert.x. It receives business opportunities from an outside source. Once one is received, we need to save it locally. Then we run it through a machine learning classifier to see if it is the type of opportunity the client might be interested in. If it is, then a human needs to have a look at it. Otherwise, it is rejected.

We receive thousands of these every day. Due to the parallel nature of Vert.x we are able to spawn many requests over the cluster and get this work done quickly.

The persistence part a quite performant so we don’t need many instances of that verticle in the Vert.x cluster. The classification part is slow and requires more resources. So, we have many instances of that verticle over the cluster.

The process above looks like a traditional process but in fact, we are not in control of the transaction here. In each activity, we are sending a message using the Vert.x Event Bus and then waiting until an event happens at a future time. Once that event is received we move on the the next activity which does the same.

Unfortunately, the classification activity doesn’t always complete in a timely manner. In this example we added a boundary timer so that if the classification takes too long, we notify a user and then terminate the process.

The activities that involve microservices in the main process are modeled as subprocesses. Here is an example of the Persist Opportunity subprocess.

screen-shot-2016-09-16-at-12-00-37-pm
Persist Message that calls Vert.x
The first activity is a custom work item handler I created for Vert.x. It will send a message to the Vert.x cluster using the Event Bus.

That message may cause a number of other services to be called within Vert.x. We don’t care about that, all we need to know is when it’s all finished. I created a customization for Vert.x so that the process manager will be sent a signal when a particular Vert.x service is complete. When that happens the Catch Signal will be executed. At that point, control will be returned to the calling process which can move on the next activity.

So, there you go! We can model processes as we are accustomed to even though we are not in control of the transaction as it moves through the various microservices. You can definitely use these pattern to combine microservice activities with traditional ones and apply our usual process management patterns to all of it.

 

If you are going to Java One in September 2016 check out the Red Hat speakers and consider attending Burr Sutter’s session on Reactive Microservices with Vert.x [CON5389]

 

You can also learn more in the webinar I’ll be hosting on 9/27 at 11am ET.

Screen Shot 2016-05-26 at 2.01.22 PM

 

 


Connect with Red Hat Consulting, Training, Certification

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Training on Twitter
Like Red Hat Training on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn
Creative Commons License