Tuesday, July 31, 2012

Progress "Divests" Savvion - OR - How OSS Mitigates Software Risk

Just two years ago Progress acquired Savvion for around 40mill USD. Some of you may remember my blogs on this subject, as a large proportion of the product consisted of repackaging Drools; but without giving any noticeable due credit.

Now Progress has decided to divest itself of Savvion, along with a number of other products. I can imagine the existing Savvion install base is not too happy, as noted in this Savvion blog article:
"This will no doubt have an impact to many organizations which uses Savvion for their core business applications and will impact other major initiatives. It is too setback and bad corporate strategy by Progress specially when the acquisition on Savvion was quite recent. " http://savvion-blog.blogspot.co.uk/2012/04/progress-announces-to-sell-savvion-and.html

There is an important lesson to learn from this, with regards to risk management.
Open Source Never Dies!!!

When you commit to a product you need to know it's going to be there for the long term. With proprietary technologies you are at the whim of the current business strategy. It took just two years for Progress to decide to divest itself of Savvion, creating uncertainty and risk for the community.

Open Source technologies offer an alternative way to manage risk. Healthy projects with large community adoption will always have companies invested in both developing that software and providing services around it. If the dominant company(s) decides, for what ever reason, to refocus their strategy and divest themselves of their involvement with that project; other organisations will step up to fill that void.

Now of course you need to make sure you pick a healthy project, with a strong community and large world wide adoption; such as we have with Drools and jBPM. Some areas to consider that help assess a projects health include, but is not limited to:
  • mailing list volumes
  • speaking engagements and workshops
  • published books
  • real time chat channels
  • user groups
  • job adverts (shows demand)
  • number of service companies
  • global impact (where in the world it has installed user bases and service companies)
Drools and jBPM are very successful projects at Red Hat, and Red Hat is very committed. But imagine in Bizarro world where a new RHT CEO decided to divest itself of the Drools and jBPM projects. Over night many of the existing alternative service companies out there would be competing to fill that gap and take on the divested Red Hat customer base. New companies might be formed too, to take advantage of the situation. To differentiate themselves from other service companies they would look to take on more of the core development for the project to demonstrate leadership in the community. In short the technology lives on, your risk from the adoption of the technology is mitigated. Further you have multiple options from competing vendors all vying to give you the best possible services and technology.

Compare the above Bizarro world situation to the reality that Savvion users are now experiencing.

But Savvion users, fret not. Red Hat brings a world of sunshine, come on over and dive in, the water is lovely :)


Sunday, July 29, 2012


Once you become familiar with the topics discussed in my previous two posts:
You can start playing more and more with the Rule Engine. One of the things that you will notice during your first steps is the behavior mismatch between a Rule Engine and  Process Engine. This is the main topic of this short post.


Every time that we start a new Process Instance inside any Business Process Engine we expect that the engine will execute all the activities defined inside the process definition. We understand that the process will run until it reaches a Wait State, meaning that an external Asynchronous interaction is required by the process to continue. All the Synchronous activities will be automatically executed by the engine as soon as possible.
In the previous post we've analyzed a process which includes some rules to Rank a Car and Define the Price of that Car.
Synchronous Process
For that example, we never doubt about the Synchronous nature of the Rules Evaluation and Execution. Once again, unless we introduce an Asynchronous External Interaction into our process like a Human Interaction or an Asynchronous call to an external system  our process will run each activity as soon as it finishes the previous one.
Now if we jump to the Rule Engine Arena, we have a different expected behavior.
Rule Engine: Evaluation and Firing Cycle
Rule engines work using a two phase execution cycle:
  • Evaluation / Activation: When we insert new data (Facts) into the Rule Engine, the information is evaluated and all the rules that evaluates their conditions to true will be activated. All this activations are placed inside the Agenda.
  • Firing: Using a Conflict Resolution Strategy, the Rule Engine will pick one Activation from the agenda and it will execute the Consequence for that rule, which can cause  new activations to be placed inside the agenda or the cancellation of previous activations. After finishing executing the selected activation, the engine will pick another activation to execute. This loop will continue until there are no more Activations in the Agenda.
This recursive nature of the rule execution cycle, and the fact that we need to enter into the firing phase explicitly by calling the fireAllRules() method, force us to think about how the process and rules combination will work at runtime.

Stateful vs Stateless

As I've promised in my previous post, from now on we will work with Stateful Sessions, meaning that our processes and our rules will be hosted in a session that will be responsible for keeping the status, allowing us to have a richer context to work.
Stateless Sessions can be considered a simplified version of Stateful Sessions, were the execution cycle just run once, and the context cannot be reused to add more information later on. When we start using Stateful Sessions, long running Processes and Rules can coexist and influence each other behaviors.
The Process Instance itself can become a Fact inside the Rule Engine and we can start doing inferences about it. At the same time we can create Rules to evaluate a set of Process Instances which are running in the same session, opening the door for a whole set of patterns. But, before jumping into the patterns we need to understand the execution behavior in this Stateful Environment.
Now if we have a Process which requires to evaluate some Rules as part of an activity we will find out that we explicitly need to call the fireAllRules() method to execute the consequences of the activated rules. We need to know that our Rules living in the same session where the process is being executed will be evaluated as soon as we insert information into the Rule Engine, activations will be created and placed inside the Agenda, and they will be there until we call the fireAllRules() method.
From our previous example we can see clearly how different contexts were used and how with stateless session we can obtain a synchronous execution.
Stateful and Stateless Contexts
Now if we want to do all the evaluations inside the same Stateful Context we need to be careful with the execution behavior. Take a look at the following figure which shows the Process Instance and a set of facts coexisting in the same Stateful Session, where all the evaluations will be made.
Stateful Context
Now we have facts that we will be evaluated as soon as we insert them into the Session, so it will be our responsibility to define where the current activations will be fired. If we want to simulate the same behavior from our previous example, we will need to call the fireAllRules() method after each activity which is related with rules evaluations.
From the application perspective this is not easy to handle, because if we have several processes being executed we will not know when it is necessary to call the fireAllRules() method for sure.
For this reason, the following section explains a technique which help us to put the Rule Engine a Reactive Mode.

The Reactive Mode

There are two ways to put the Rule Engine in what we call "The Reactive Mode".
  • Fire Until Halt
  • Agenda & Process Event Listeners
Using these two alternatives we will be forcing the Engine to fire the activations as soon as they are created, without the need of calling explicitly the fireAllRules() method.

Fire Until Halt

The Fire Until Halt alternative requires another thread to be created, which will be in charge of monitoring the activations and firing them as soon as they are created. In order to put the Engine in a reactive mode using the fireUntilHalt() method, we use the following code snippet:
[code language="java"]

new Thread(new Runnable() {

  public void run() {



} ).start();

[/code]The only downside of using the Fire Until Halt approach is that we need to create another thread – this is not always possible. We will see that when we use the persistence layer for our business process, using this alternative is not recommended. For testing purposes relying on other thread to fire our rules can add extra complexity and possible race conditions. That’s why the following method, which uses listeners, is usually recommended.
Check an example of Fire Until Halt here: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/test/java/com/salaboy/jbpm5/JBPM5ProcessAndRulesIntegrationPatternsTest.java#L113

Agenda & Process Event Listeners

Using the Agenda and Process Event Listeners mode allows us to get the internal Engine events and execute a set of actions as soon as the events are triggered. In order to set up these listeners, we need to add the following code snippet right after the session creation, so we don’t miss any event:
[code language="java"]


new DefaultAgendaEventListener() {

   public void activationCreated(
                          ActivationCreatedEvent event) {

        ((StatefulKnowledgeSession) event.getKnowledgeRuntime())

    new DefaultProcessEventListener(){

    public void afterProcessStarted(
                             ProcessStartedEvent event) {

        ((StatefulKnowledgeSession) event.getKnowledgeRuntime())


Notice that we are attaching a DefaultAgendaEventListener and a DefaultProcessEventListener that define several events where we can hook up behavior. In this example, we are overriding the behavior of the activationCreated(…) and afterProcessStarted(…) methods, because we need to fire all the rules as soon as an activation is created or a process has started. Look at the other methods inside the DefaultAgendaEventListener and DefaultProcessEventListener to see the other events that can be used as hook points. This approach using listeners gives us a more precise and single threaded approach to work.
Check an example using Agenda and Process Event Listeners here: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/test/java/com/salaboy/jbpm5/JBPM5ProcessAndRulesIntegrationPatternsTest.java#L164
Notice that this example works in the same way that the previous one, it give us the same results, but in this one we don't need to sleep to wait another thread to finish the execution of the fire all rules cycle. Sleeping is not an option for real applications, and because of the recursive nature of the cycle we will never know for sure how much time the other thread will require to finish.


Knowing about how to put the Rule Engine in Reactive Mode will be a common practice to work with processes and rules. It is important to know that both approaches – Fire Until Halt and Agenda and Process Event Listeners – give the same results in the previous tests, but they work in different ways. We need to understand these differences in order to choose wisely.
I strongly recommend you to check the examples provided in the links, to get familiar with this behavior. Future posts will work in Reactive Mode, and understanding how everything works in the back will help you to understand more advanced examples. Enable the logs in the example and analyze the output to understand the Process and Rules execution.
If you have questions about the examples, post a comment :)
If you have suggestions about how to improve the examples, post a comment :)


Saturday, July 28, 2012


I'm back! In my previous post I've introduced a couple of patterns about how to mix processes and rules and viceversa. This post, before jumping into more advanced topics which requires to know how the Rule Engine works, will explain with some examples how we can interact with the Rule Engine using stateless sessions . This examples can be used to compare how most of the BPMS out there used to work with Rule Engines. At the end of the post you can find an example about how to solve the same scenario presented in the example just using Rules.


The main focus of this post is to describe the common ways of defining stateless interactions against the Rule Engine. As I mentioned in my previous post, this is how BPMS were doing the interactions from the last 20 years. After this post everything will be about Stateful Sessions. For that reason, the second half of this post analyze how we can start translating these kind of models to leverage the power of the Rule Engine.
The classic examples of the Decision Points Pattern and the Data Validations/Enrichments Task Pattern were quickly introduced in my previous post. So let's take a look at some examples which shows some common modeling decisions that we made for representing our business situations.

Data Validation/ Enrichment Task Pattern

The first example looks like this:
Car Ranking Process
Let's start simple with a couple of Task which can be resolved using the Data Validations/Enrichments Task Pattern. This means that for both tasks we will need to contact the Rule Engine in order to Rank a Car and then another set of Rules will be in charge of Define the Car Price based on the Ranking and some other business definitions, that could be the current state of the Car market.
The ultimate objective of this process is to put the best price possible for the company that wants to sell the car. A process like this can be used to quickly react on Market changes, so for example if the company in charge of selling 3 different brands of car, know that there is a high demand of an specific brand because of the Olympic Games, they can quickly tune the system to influence the Ranking and Pricing logic.
If you want to run this process in any other BPMS you will need to know the Rule Engine APIs and find a way to call them. If you want to  copy exactly the same behavior in jBPM5 you will need to use  WorkItemHandler which internally use a Stateless Session to do the Evaluations. So for running this example you will need to do something like the following figure:
Stateless Interactions
No matter the process engine  you will end up doing something similar. An example about this can be found here:
The rules of this example are not complex to keep the example small and as simple as possible.
Some characteristics of this example that you must know:
  • The Process runs inside a Stateful Session and we create two Stateless Sessions for doing the Ranking and Pricing evaluations. We need to move information around the different sessions, we need to instantiate them and we are compiling the rules each time that an evaluation is required.
  • We are creating a lot of artifacts that we need to maintain:
    • 2 DRL Files
    • 2 WorkItemHandlers
    • 1 BPMN2 Process file

Decision Points Patterns

For this example, let's imagine that once we define the Price of a particular car we (as a company) will define if we will accept the car from our providers or if we will reject it because we will not be able to sell that particular car:
Decision Point
There are several ways of defining the business conditions which will dictate if we better leave this car or if we will accept it to sell it to our customers.
A common practice is to define the restrictions in the gateway's outgoing Sequence Flows based on the process variables. We can say something like:
  • If the calculated price is less than 15000 we will drop the offer
  • If the calculated price is greater than 15000 we will pick the car from our provider to sell it to our customers
This can easily be translated to a Java sentence which evaluate the "car" process variable:
[code language="java"]

(return (car.getCurrentPrice() < 15000);

This is OK for simple hello world examples, but when we have a real business situation this evaluation becomes really complex, and more if they are based on external services.
So, we have another alternative, once again using a Stateless Session:
Stateless Decision Point
If we have more complex business conditions, we can once again use Rules to keep that logic decoupled from the business process in a declarative way.
If you take a look at this example, it also shows how you can plug external services into the decision logic.
You can find the RulesHelper here, it's a very simple implementation but it shows the basic concepts: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/main/java/com/salaboy/jbpm5/RulesHelper.java
Some characteristics of these examples:
  • We are sequencing decisions that doesn't require to be sequenced, we can use the power of the Rule Engine to make all this automated decisions for us.
  • Creating multiple sessions we are defining new scopes to handle different pieces of information, but the information that all those sessions handle needs to be moved from one context to the other.
  • We should try as much as we can to keep the business logic decoupled from our business process model
  • As long as we don't have external interactions such as Human Interactions or External System Interactions, we should keep our processes as simple as possible and we will need to analyze if for simple situations we required a business process definition or we  can just use Business Rules for do the tasks.

The Rule Engine Way

If you are already a Rule Engine user, you probably notice that all the previous examples can be written using only rules, because there is no need for coordination. The whole point of the previous examples was making a business decision, which can be easily translated to a set of Rules. We can collapse all the logic represented by the processes and rules previously introduced into just a set of rules which will now when to evaluate the information that we are providing.
The Rule Engine Way
We insert facts, and we end up with a Decision which is valuable for the company.
Notice that we are covering the same requirements that were introduced in the previous examples, but just using rules.
The whole point of this section is to show how we can switch from one Process Oriented Perspective to a Rule Driven Perspective to solve the same kind of scenarios. Knowing all the tools and approaches we will be able to design more flexible solutions choosing the best approach based on the requirements that you have.
I've collapsed all the rules that were used in the previous examples in just one DRL file and I've added some modifications for them to work together. Rules: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/main/resources/car-evaluations.drl
At this point is important for you to recognize, that I'm not suggesting that we can drop the process engine and do everything with rules. When we have this kind of scenarios which doesn't involve Human Interactions or Asynchronous interactions with external systems, we can evaluate if we really need a process definition or we are just trying to make a decision which can be solved by rules only. Most of the time, users who only know the Process Oriented way of solving things ends up with extremely complicated process diagrams to solve things that can be quickly summarized in rules.


On this post we spend some time looking at some examples of the previously introduced Patterns: Data Decoration/Enrichment Task and Decision Points patterns. All the examples from this post show the usage of Stateless Sessions to make One-Shot data decorations or decisions, but at the end of the post we analyze how we can solve the same scenarios using the declarative power of the Rule Engine.
On my following posts we will continue analyzing more advanced patterns that uses Rules to simplify business processes that tends to become more complex when we start adding too much business logic on top of them.


Thursday, July 26, 2012

jBPM Designer 2.3.0.Final released!

We are happy to announce a new release of the jBPM Designer, the Web-based business process Editor for jBPM 5.
Here is an overview of new features and most notable bug fixes in this release:
New Features
Notable Bug Fixes
You can download jBPM Designer version 2.3.0.Final from Sourceforge. If you are upgrading from an older Designer version, make sure to clear your browser cache before start using the new one.
For the next release we will strongly focus on
  • Simulation and Replay capabilities
  • Alternative asset storage options
  • Usability enhacements
jBPM Designer is open-source and of course free! If you would like to be part of Designer development and discussions or just want to ask questions feel free to talk to us on the User Form, the Mailing List, or IRC.
You can also follow the latest news about the jBPM Designer on it’s Blog.
Enjoy :)


Wednesday, July 25, 2012


Hi there, I want to share with everyone some updates about the jBPM Form Builder. I was doing some work to make it independent of the environment and more easy to use. This post include the current state of the project, how to build it and run it and the future steps. Feel free to leave feedback about the features that you consider most relevant and if you want to get involved please contact me, there is a lot of work to do on this front.


The Form Builder was created by Mariano De Maio as a community effort to have an unified and generic way to build forms that can be reused multiple times by our applications. One of the most common use cases are front ends for Human Tasks inside our business processes. The Form Builder right now is a stand alone component built using GWT which now can be deployed in different Application Servers and Servlet Containers and support multiple browsers. The main focus of this component is to allow us to quickly create a form and then provide the mechanisms to render this form inside our applications.
Example Form
The current version provides the initial version of a configuration service, which allows us to configure where do we want to store our form definitions. This is an important feature  to be agnostic of all the other components that we need to deploy, allowing us to just deploy the form builder if we just need to create forms. This simplify the development and configurations efforts required by the users to get started with this component.


I've being working in decouple in the internal functionality in different modules to make it more reusable and accesible from third party application. The following figure shows how the components looks right now:
Form Builder Components
You can follow the discussions about the design and each module functionality joining the jbpm-dev mailing list.
As you can notice, there are two big things:
  • The Form Builder WAR:  the application that allows us to model our forms. It can work as an standalone component, you don't need to deploy any other application to work with it.
  • The Form Consumer: any third party application which wants to interact with the real form
In the following section we will see a quick demo about how to model a form and how to consume it from another application.


The following video shows how we can design a form that will be in charge of interacting with a User Task created on the  jBPM5 Human Task Server. We will see how we can design, save and then render the resultant form from a different application.


The following steps for the project is to provide a simplified list of components with a default layout and a customizable CSS palette to allow you to customize and adapt the form builder to your own needs. We will be working to integrate the current version to the jBPM Web Process Designer to be able to jump back and forth from the Business Process Design view to the Form Builder.
There are several improvements related to the data mappings and automatic form creations that we are investigating and developing.
I will share soon a list of visual components that we will be providing in a different post, but feel free to send suggestions!

Get Involved

This is a very good time to get involved and share your opinion about this kind of components. The more requirements that we can gather the better the component will be. If you want to learn and contribute in this project please contact me, there are a lot of small tasks to do which will help to improve the usability and flexibility of this component.
You can find the source code of the project here: https://github.com/droolsjbpm/jbpm-form-builder/
Some task that could be done by community members are:
  • Maven profiles for different containers
  • Create new components to display in the palette
  • Archetype for creating clients
  • UI improvements
  • Documentation
If you think about another feature that you want to add contact me and we can figure out how to add it.


Sunday, July 22, 2012

Scaling Planner with JIT selectors in memory consumption and performance

For Drools Planner 5.5.0.Beta1, I 've rewritten the Selector architecture from scratch. I 've just pushed the changes to enable it on master. A few weeks ago, I already blogged about the Just In Time Selectors, which I 'll talk about more in this blog entry. In the next few weeks I 'll cover the other new features in the new Selector architecture.

Let's take a look at the memory footprint on a few datasets, with the old Selector architecture and the new Selector architecture.

Dataset machinereassignment B1

The B1 dataset has 5 000 planning entities and 100 planning values with a search space of 10^10000.

Before (without the new selectors):

Solving ended: time spend (61178), best score (0hard/-5368866214soft), average calculate count per second (85983).

After (with the new selectors in JIT mode):

Solving ended: time spend (60672), best score (0hard/-3818500264soft), average calculate count per second (144530).

Except for the selectors, all the code is exactly the same. Notice how:
  • The old selectors used 500 MB memory. JIT selectors use around 100 MB memory. That's about 80% less memory usage.
    • With a lower max memory setting, it can even use less.
    • The difference is even more for bigger problems (B2-B10).
  • The old selectors calculated 85k scores per second. JIT selectors calculate 144k scores per second. That's almost 70% more performance.
    • How is that possible if even the score calculation code is exactly the same? That's because the JIT selectors don't shuffle the entire move list on every step, they use Random far more efficiently. This leaves more time to do more steps (from 41 steps to 2186 steps).
  • In 60 seconds, the old selectors found a best solution of score -5.3m, JIT selectors found a score -3.8m. That's a 28% better solution.
Bigger datasets have even better results. Do note that in non-JIT mode (cacheType STEP or PHASE) the new selector architecture produces a graph and results similar to the old Selector architecture.

Dataset machinereassignment B10

The B10 dataset has 50 000 planning entities and 10 000 planning values with a search space of 10^184948.

Before (without the new selectors):

The old Selector architecture simply could not scale to this problem size on a regular computer.

After (with the new selectors in JIT mode):

Solving ended: time spend (60994), best score (0hard/-37237760070soft), average calculate count per second (18302).

This dataset is so big, that it takes over 750 MB and half a minute just to load the dataset from file into memory. However, running Planner on top of it, barely takes 200 MB more, so in this case, Planner has a memory footprint of only 27% of the dataset itself.


When the use cases become really big, traditional selector methods run into memory limits. In those cases, JIT selectors don't: they continue to scale out.

However, most use cases are smaller, with only a few thousand planning entities. They have plenty of free memory and therefor see little or no benefit from JIT selectors. But they do benefit from other new features in the new Selector architecture, such as filtering and probability selection. I'll blog about those soon.

Voice-driven BPM with jBPM Designer

Have you ever thought of modelling your business processes using your voice? Alternative input methods have always been a part of Assistive Technology but are moving more and more into the “mainstream” user experiences. Just think how many of you speak into your iPhone every day now? :)

Using our voice is the most natural way of communication and now it can also be part of your BPM modelling efforts with the addition of Voice-driven BPM modelling in the jBPM Designer.

Below is a video showing this new feature:

The voice commands are fully user-configurable, however currently only the English language is supported.

Note that this feature is experimental and still subject to change and enhancements. You can start using it now however by cloning and building the jBPM Designer from its GitHub repo.

jBPM Designer is a free and open-source project and if you are interested in contributing to this or many other cool features, hit us up on IRC to get started.


Friday, July 20, 2012

(Processes & Rules) or (Rules & Processes) 1/X

One of the things that differentiate jBPM5 from other BPMS is the fact that it runs on top of the Drools Rule engine. During a series of post I will be trying to share some of the advantages of this approach. Because this topic is heavily discussed inside Chapter 9 of the jBPM5 Developer Guide which will be published soon, I will try to use this post to gather feedback about what people expect or know about these features inside jBPM5 and Drools.

Old School Integration

For years and years the integration between BPM Systems and Rule Engines were limited to very simple stateless interactions. The most popular examples that we can find about this very simple integrations are:
  • Decision Points Pattern
    Decision Point
  • Data Validations/Enrichments Task Pattern
    Data Validation, Data Enrichment, Consistency Checks
*JBoss Drools --> Rule Engine (www.drools.org)In both cases we can find the following characteristics:
  • Stateless Interaction with the Rule Engine (One Shot)
  • We need to move the information between the Process Engine context to the Rule Engine context
  • We will probably need to adapt the information structure to work well in both environments
These three characteristics are OK but they just use 1% of the Rule Engine Power. Let's see what we can do if we take advantage of the fact that we have a Rule Engine for free when we use jBPM5.

 jBPM5 and Drools Integration Patterns

This section shows some integration patterns that we can implement using more features of the Rule Engine. In no way these patterns are the only ones that can be implemented but I'm just showing a random set of them for inspiring you to create new ones based on your needs. This patterns will serve as the basis for more advanced patterns that I will be sharing in future post which are also detailed inside the jBPM5 Developer Guide.

Contextual Decisions

In jBPM5 we can use the DRL language to define the conditions that needs to be evaluated inside a gateway. When we see this for the first time it looks like the old "Decision Points Pattern" introduced in the previous section, but it's not.
  • Contextual Based Decisions Pattern
Decisions Based on Context
If we use the DRL syntax to write XOR gateways conditions we can decide not only based on process variables, we can make decisions based on the session context that we have available. This flexibility open a very useful set of patterns that can be written to leverage this feature. When we use the DRL language to express conditions in each of the outgoing sequence flows in the XOR gateway we are filtering the facts available inside the Stateful Knowledge Session, so for example:
[code language="xml"]

 Person( age < 18 && > 25)

 Person( age > 25 && < 40 )

 Person( age < 18 )

Looking at this example, we are not filtering the information that is inside the Process, we are checking the available facts in the context to make a decision inside our business process. If we want to analyze process variables using the DRL syntax we have two requirements. First of all, we need to make the ProcessInstance available as a Fact inside the Rule Engine, and then we can use the following DRL snippet to evaluate the process variables:
[code language="java"]

WorkFlowProcessInstance( $person: variables[“person”])

Person( age < 18 ) from $person

Obviously we can also mix the evaluation of the Process Variables with Facts inside the Knowledge Session giving us the ultimate flexibility. This example just show the basics, in order to understand what can be done you need to play with it and try to map your own scenarios to use these mechanisms. You can see the example how everything is glued together in my github repo: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/test/java/com/salaboy/jbpm5/JBPM5ProcessAndRulesIntegrationPatternsTest.java That test uses the process-drl-decision.bpmn process that you can open with the process designer provided by the jBPM installer.
DRL Decision Process
  • Multi Process Instance Evaluations Pattern
This pattern will be used to make decisions in different instances of the same process based on shared common data. We will see how we can control and affect processes executions based on facts available inside the session. This example will be used to demonstrate more advanced patterns in the future. The process that we will be using here looks like:
Multi Process Instance Decision
In this case our process have 2 paths that will consume different amounts of Resources. Based on the available resources on runtime the XOR gateway will decide which path will be selected. If each task consume 1 unit of the available resources we can say that Path 1 will consume 5 (5 task needs to be executed) and Path 2 will consume just 3 units. If the process is related to a customer relationship process, we can say that some customers will require more attention than others. The most basic way of handling resources for these kind of scenarios is to say that we will always execute Path 1 unless we are out of resources. In that situation we will choose Path 2, because we don't have enough resources to go through Path 1. This example shows how we can control multiple instances of the same process running in the same context, which is extremely useful to add environmental restrictions about the resources (in the generic sense) that will be required by our business processes. You can take a look at the example provided in this tests which runs this scenario with 50 units to demonstrate how the global rule will kick in as soon as we are out of resources. Check the test class: https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/test/java/com/salaboy/jbpm5/MultiEvaluationProcessAndRulesTest.java The Process File (BPMN2): https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/main/resources/multi-process-decision.bpmn The rules file (DRL): https://github.com/Salaboy/jBPM5-Developer-Guide/blob/master/chapter_09/jBPM5-Process-Rules-Patterns/src/main/resources/resources.drl 


The following post will show more advanced patterns which can easily create using jBPM5. From the architectural perspective of our applications we also need to analyze how these patterns can help us to solve recurrent problems which complicates our models when we use traditional approaches. The idea of breaking different solutions into patterns will help to make reference them and to build on top of them different solutions to different business scenarios.

Once we master the integration between processes and rules we can start including events  (CEP - Drools Fusion) into the picture.

Feel free to write back in the mean time, if you are already experimenting with this kind of topics. Most of the examples that can be found inside the GitHub repo are more advanced that the one presented here, but we need to have the foundations first in order to understand how things work together.


Thursday, July 12, 2012

Dr. Douglas Lenat (Cyc) joins Dr. Robert Greenes to keynote IntelliFest 2012

I'm very excited that this year Dr. Douglas Lenat will be one of the keynote Speakers. Dr Lenat is the founder of the gound breaking AI project  Cyc:
"Cyc is an artificial intelligence project that attempts to assemble a comprehensive ontology and knowledge base of everyday common sense knowledge, with the goal of enabling AI applications to perform human-like reasoning." (wikipedia)
Dr. Douglas Lenat joins Dr Robert Greenes, a biomedical and infomatics star from Arizona State University, who will be keynoting the Healthcare day.

The healthcare day is being co-chaired by Emory Fry, MD and Dr Davide Sottara, and request for presentations is now open. Please send your healthcare and medical submissions to the following emails: 
to: eafry at gmx d0t com. 
cc: dsotty at gmail d0t com, mproctor at codehaus d0t org.


Friday, July 06, 2012

IntelliFest Oct 2012 (San Diego) : Healthcare, Bootcamps and More

IntelliFest 22 - 26 Oct 2012 is under way. This year it's located in San Diego, at the Bahia Resort Hotel.

There will be a dedicated Healthcare day, as well as the normal Drools&jBPM bootcamps. Both days are available with free registration; although spaces are limited. Followed by the 3 day main event. The main sessions will cover a wide range of reasoning technologies from the domain of AI, register here. The main sesssion format this year is multi-track to cater for developers, management and executes. The IntelliFest call for presentations is still open.

The healthcare day is being co-chaired by Emory Fry, MD and Dr Davide Sottara, and request for presentations is now open. Please send your healthcare and medical submissions to the following emails:
to: eafry at gmx d0t com.
cc:  dsotty at gmail d0t com, mproctor at codehaus d0t org.

Any talks that involve reasoning technologies from the domain of AI is accepted. However special focus will be given to rules, workflow, event processing, ontologies, planning and agents. Both 25 and 50 minute talks are accetable.We prefer presentations more on the clinical side, than on the administration side (i.e. billing talks).

I have the great pleasure of announcing the healthcare keynote speaker, Dr Robert Greenes. A biomedical and infomatics star from Arizona State University.

Title: "Embedding Decision Support in Clinical Systems"

Dr. Robert Greenes
Chair, Department of Biomedical Informatics
Arizona State University

Dr. Greenes joined ASU in September, 2007 to lead the new Department of Biomedical Informatics (BMI).  This unit, originally in the School of Computing and Informatics, in the Fulton School of Engineering, is now a Department under the newly constituted Biomedicine@ASU framework.
Before coming to ASU, Dr. Greenes spent many years at Harvard, in the field of BMI, first at Massachusetts General Hospital, then at Brigham and Women’s Hospital, where he established the Decision Systems Group in 1980, and developed it into a leading BMI research and development program. Dr. Greenes was professor of radiology and of health sciences and technology (HST), at Harvard Medical School, where HST is a joint division of Harvard and MIT. He was also professor of health policy and management at Harvard School of Public Health. For over 20 years, he has directed the Biomedical Informatics Research Training (BIRT) program, with support from the National Library of Medicine and other sources, with co-directors now representing 10 hospital and university-based informatics groups throughout the Boston area. Dr. Greenes is a practicing radiologist, and has also had brief interludes at Stanford and in industry. Dr. Greenes’ research has been in the areas of clinical decision support, in terms of models and approaches to decision making, the knowledge representation to support it, and its clinical application and validation. He has also been active in the promulgation of standards and fostering of group collaborative work, particularly in knowledge management. A related research interest is human-computer interaction, particularly with respect to the use of clinical information systems by providers and patients, the improved capture of clinical data and the incorporation of individualized, context-specific decision support. Another interest is in personal biosensors for monitoring of patients at risk in a variety of settings.


Modeling of clinical decision making - knowledge representation - knowledge management - clinical decision support - personal biosensors - human-computer interaction - group collaborative work


1970, Ph.D, Harvard University
1966, MD, Harvard Medical School
1962, BA, University of Michigan