How-to: An Embedded jBPM hello, world example

Ok, I admit it. BPM is not the hottest of hot trends right at the moment. But it still has a place. For example, BPM is rock solid at collaboratively modeling business processes with diagrams and orchestrating enterprise services — especially microservices. In fact, BPM might let you keep your microservices finely grained, as they should be, and avoid too many composite microservices.

But what if you don’t want to implement an entire BPM server and suite? Instead, you want to flip it around (as I argued for in mode 3 of my draft whitepaper on the same subject). You want to expose a service that embeds the workflow execution engine. If this is what you’re thinking about doing, then I think this is the hello, world example you’ve been Googling for.

Model your hello, world “business process”

I did this TDD, but let’s start our discussion with a super simple business process model. The workflow it describes accepts some initial parameters and then calculates a new string saying “Hello ____.” That is, the example sets a process variable as input — in BPM-speak — and then reads a different process variable to use as output.

bpm-diagram

Above you see my BPMN 2.0 diagram really is simple: it’s comprised of a start event, an end event, and a script task reading the input process variable string (“name”) and setting a new process variable (“welcomeText”) to be consumed later.

First, I defined an input process variable as a data element in the properties window of the overall BPM2 process.

bpm-diagram-properties

One thing I should mention is that the tooling didn’t let me actually specify the string datatype for the incoming type. I had to manually edit the XML file (which is on my Github repo below), but I think it’s just that I’m a little new to the tooling — not that it’s impossible.

Next, I defined the following script task, which reads the process variable named “name.”

script-task

 

I saved the file as say_hello.bpmn in my Maven project’s resources directory.

Now embed the jBPM execution engine

Remember, I don’t want to deploy the BPMN file into a standalone server. I want to flip it around and embed the server. We can do that with just a few lines of Java code. Before we get too far into this, the JBoss documentation says that my approach is “not recommended for real application development but more for try outs.” Instead, they recommend using the RuntimeEngine to give you finer-grained control over your execution. For now, I’ll leave it to you to explore the distinction.

Under this scenario, we just need to create an object that has access to the BPM execution engine and then create a session from that engine. Specifically, the first step is to set up our KieBase, which has the execution engine inside it, and feed it the BPM workflow (documented above). Then we get a reference to a KieSession. KieBase is a relatively heavyweight operation but creating new sessions is pretty lightweight.

Next we’re going to set our process variables on the session and start the workflow (while holding a reference to the ProcessInstance).

Notice the typecast in there? It’s from the kie-based ProcessInstance to the jBPM process instance from the org.jbpm package, which is useful in later steps.

Finally, we extract the “output” of the BPM process by getting access to the workflow’s process variables after the workflow completes as follows:

I don’t like all the typecasts, but this is my first cut. It works, and it’s pretty fast. Comments? All the code is on Github here.

warningAn important caution about this approach: One initial comment you may have is that running a process in this way will cause a lot of problems if you’re trying to run a long-running process or take advantage of the full suite of options in BPMN. I know, I know. But I’m imagining a microservices-like use case that’s pretty limited. By this I mean you’re going to run mostly quick, short orchestrations (likely of other microservices) and you don’t need to incorporate human interaction in the process nor do you need to even store the state of the process as it runs. In short, you’re getting a very limited suite of BPM services, but that’s ok for this use case.

In defense of the enterprise developer

I was reading a PriceWaterhouseCoopers article during my long West to East Coast trip to Raleigh last night. PWC warned big enterprise CIOs that their organizations are lame because they represent “slow tech,” and that all the talent wants to go work for “fast tech.” So, old line CIO, prepare to retool to go to the mat with Etsy. And good luck with that.

Instead, I want to offer a clear defense of what it means to be an enterprise software developer even as they are today and without changing a thing (even if change is always warranted).

Before I start, let’s get this out of the way: I know, quite painfully, how lame it can be to be an anonymous corporate software developer lost in a sea of cubicles buried deep in some forgotten corner of Corporate America when you disengage. I hated it with an exquisite passion, so much so much that I dropped out of the whole thing and went to law school. I met a guy today at the Red Hat Tower who shared my experience but did something much more fun: he bumped chairs in Breckenridge for a while. But you can avoid the problem and not derail your career like we did.

I believe that enterprise software developers get bigger opportunities more often than developers in almost any other context — especially with the big emphasis on “digital” these days. The bigger the enterprise, the bigger the range of opportunities. Here’s the non-exclusive list I made on the airplane:

It can be a huge mental challenge to navigate and improve the thick mesh of enterprise applications, services, domain knowledge, and the endless sea of acronyms. An even bigger challenge is how to break down all the barriers and speed bumps created by those systems.

For many software developers, shipping code is not the bottom line. If you look around for stuff on developer culture or developer happiness, you’ll run into a lot of (quite good) navel gazing pieces about how important it is for developers to be able to ship code. I get it. But the art of craftsmanship, which often gets included in the discussion, exists even in code that doesn’t ship this afternoon and it exists in places other than just code. Anyone can be a craftsman anywhere and whenever they chose to start.

In big enterprise environments, your code touches millions without much effort. Big enterprises already have the scale most startups dream of. So it’s amusing for me to read how young software developers dream of working for companies like Facebook or Google because their code could touch millions of people. Well guess what, most big enterprises deal with multiples of those numbers daily. What if you were working on code for Visa? How many lives would you be involved in? Target? The New York Stock Exchange? How many lives can you touch by just being in those environments and doing great work?

Finally, big enterprises offer something “out of the box” that’s hard to get with anything but the fastest growing startups. If you’re smart, you’re articulate, and you want to develop strong leadership skills, there’s really no better launch pad. If you’re in a company of 50, 100, or 300 thousand people there’s a lot of runway in front of you right now. If you join a startup of five, ten, one hundred people, your runway is completely dependent on the growth of the company.

Does Docker = The End of Java Containers?

I’ve said this to almost every software person I know, including a guy who lives here in Pasadena and works for Docker as an evangelist: I’ve never seen anything hit so broad, fast, and high-profile as Docker has in the enterprise. Lots of people who are lots smarter than me said also said it months before me, locked it in as a critical opportunity, and aligned to it. My company, Red Hat, is a great example. In a lot of ways, we’re leading the charge — not just with Docker but with ancillary technologies like Kubernetes, and I’ve heard we’re in the top three upstream contributors to those projects.

While I get to see the from the inside the great stuff Red Hat does (and it’s indeed cool, I’m just writing personally and as a consultant who only really cares about results for my clients. And in that context — out in the field — I’ve noticed the impact Docker’s having on the developer ecosystem, especially the Java enterprise ecosystem. While we recently celebrated the twentieth anniversary of Java, as an industry we spent the majority of those twenty years trying to figure out how to build big, monolithic, mutlti-threaded, container-based enterprise systems. That is, we thought we needed Java EE containers or OSGi containers or whatever because we couldn’t possible run mainline Java code.

Or that’s what our industry and our bosses said, right?

Frankly, even though I admit I followed my marching orders without really challenging them, hasn’t it been a colossal hassle? As a developer, all I really want is some kind of framework that works, like Hibernate. I like it even better if it’s a standards-based framework like JPA because I could theoretically move to some better framework someday… maybe.  It’s great for speeding up development and saving me keystrokes.

But at runtime, I don’t want to have to code around specs and requirements and impositions just because of some mythical (or, worse, historical) scalability issues. When I was younger and when I challenged less, I just assumed that the big runtime containers, like the JavaEE containers, were solving a problem I didn’t really understand, so I slavishly followed the specs and debugged the seemingly endless issues and just believed that my life was the better for it.

But… now… in a Docker-like, microservices world, all that has turned on its head. An executive-level client at one of my recent clients, who’s tracking these same issues closely, asked me not so long ago, “Do I really need a container anymore?” I didn’t have an articulate, crisp answer for him. Since then, I’ve had people I’ve heard other people with vested interested in container-based architectures answer with a resounding, “YES!”

The developers in the room looked skeptical. I am too. I don’t think containers are dead. But I think their primacy is.