First glimpse at the new BPM console

The new BPM console approaches it's first milestone and I'd like to use that opportunity to introduce you to the most important changes and new features.

Managing Process Definitions

Moving to GWT
More and more JBoss projects are moving to GWT. And they do it for a good reason:

• If you are familiar with Java development and don't want to become the next web developer expert, then GWT is a good choice. With GWT you can stick to eclipse, fire up a debugger and write unit tests.
• It has a rich set of UI widgets that you can use out of the box. The widgets also force a common look and feel across implementations.

Another good example of a successful GWT implementation is the Drools console.

Managing process instances

GWT is already quiet modular and it will allow for integration of consoles across projects. Another side effect is, that you can easily take a GWT application, or pieces of it, and hook it up with existing web applications. For instance this would allow users to embed the task management functionality of the BPM console with their own intranet.

Process instance details

Improve on BAM and BI functionality
Probably the biggest drawback of the current console is lack of BAM and BI features.

Workload overview

Improving on BAM and BI is not going to happen within a day, but you could expect to see the first metrics and stats in early releases and we try to add more bits and pieces while we move towards a full fledged BAM console. Because this going to overlap in both functionality and technology with the Service Activity Monitoring project, interested readers should have an eye on SAM as well.

Performance metrics

How to move forward
To begin with, we are going to provide a replacement for the existing jBPM console based on GWT. It will retain the current features and provide additional BI functionality. Initially we are going to leverage the existing jBPM3 backend and then gradually enrich it with SAM components or even replace it at all.

Process Graph View

Stay tuned. Next time we dive into implementation details: gchart, gwt and gwt-ext.

We know the answer, but what was the question?

Peter: "SAM means service activity monitoring".
Paul: "So, you are going to monitor service activities"
Peter: "Right. That's what I said."
Paul: "But it's two different things, isn't it?"

A typical hallway chatter. You just want to grab some coffee and then you bump into somebody, who completely turns your world upside down. It's a small question, but in this case an important one.

The last week I spend thinking about SAM infrastructure, basically getting an idea on how SAM might fit into different application/service landscapes. So you have SAM "monitoring" what your services do, and you put instrumentation code pushing "events" to SAM. Anything that might potentially be interesting to SAM, but it should figure our itself what's considered relevant. Hence the CEP backup behind it, right?

Fortunately I got distracted by some console work (moving the jBPM console to GWT), which made me think more thoroughly about what information will be relevant to people using the BPM console. There is process definitions, from which you create process instances, which again consists of work items (aka nodes). You can't tell upfront what path of execution will taken, neither you know what particular node types do.
At least from a monitoring perspective, you are forced to keep a more general look onto things. Coming from the technical side, this quiet naturally leads to a static view onto things: Process start and end dates, overall number of executions, average execution time. These sort of things.

But is it really what console users are interested in?
If I put on my "chief of sales operations EMEA" hat, I would probably like to see key performance factors relevant to my business. This might be anything from missed opportunities to SLA breaks of certain partners. But what are key performance factors?
Especially without knowing the business domain beforehand, how should I (the console developer) enable "chief of sales" to get the information relevant to him?

Let's look at the catchy title again: If I would have known upfront what you are going to ask me, I could have prepared myself. But I don't, and I never will.
I am just "Service Activity Monitoring" and you are monitoring service activities.

Now that we know "chief of sales" actually exists, we can start wondering about what actually enables him (or her) to do a successful job. IT is just the tool set here. If we do that, we will probably see that any business is goal driven (did we achieve it or not?), it has a number of participants (partners, systems, colleagues)
and suffers from derivations (exceptions, compensation). To "chief of sales" the underlying IT infrastructure is irrelevant. It exists and enables business, that's it.

Back to SAM.
To SAM the infrastructure exists but is irrelevant, too. Things that happen inside or outside your company can be relevant to the business. SAM just makes it visible to you and raises your attention.

Paul: "Great, sounds like a match."
Peter: "Yes, it is"
Paul: "But what's with the BPM console then?"

Well, the work on the BPM console made me realize that "chief of sales" questions are not restricted to BPM. It covers anything that enables particular business aspects. IT is just an implementation detail here. And so is BPM. Or ESB, or web services. But still all of these SOA components will provide information relevant to the business. And so does the BPM engine.

For the BPM console it means, that it doesn't need to be tight to the BPM domain. I believe that to a large degree general service information (goals, participants,derivations) which SAM can deliver would be sufficient. However, we may still add pluggable console components that are specific to BPM or even proprietary to jBPM. But to begin with, we should focus on a general monitoring concept.

Paul: "OK, back to work."
Peter: "Yep, talk to you later."