Showing posts with label business process. Show all posts
Showing posts with label business process. Show all posts

Monday, October 28, 2013


A old/new example was migrated to , The evaluation project is now provided and you can try it out following my previous posts from here and here. The Evaluation process shows how a task can be created and assigned based on a process variable. Feel free to try it out and give some feedback about it. Look at the end of the post, if you are looking for helping us to build useful examples.

The Evaluation Process Example

This example simulates an internal Evaluation process for the employees inside Acme Inc. This process is executed every quarter once per person inside the research department. The Human Resources department of Acme Inc. will instantiate one process instance for each employee adding a reason justifying why the evaluation is being performed.
Evaluation Process
Evaluation Process
In order to instantiate a process instance you need to specify the user/employee that you are going to evaluate. Notice that the "employee" needs to be a valid user in the system. This is because the first task of the process called "Self Evaluation" will be automatically assigned to the specified employee.
New Process Instance
New Process Instance
In this case the Evaluation will be performed on the already configured user called "salaboy". So the first task will be automatically assigned to "salaboy". In order to see the task you will need to be logged as "salaboy".
Notice that the "HR Evaluation" and the "PR Evaluation" are performed by the HR and PR group respectively. So you need to have users configured for those Groups in order to see the tasks associated with them.
The following screenshot shows how to assign a task to a specific actor using a process variable. In this case the #{employee} expression is picking the process variable called "employee" and assigning the task to the specified actor. For that reason it is important that the employee entered in the first form exists.
Assigning a Task Using a Process Variable
Assigning a Task Using a Process Variable
Once you complete the "Self Evaluation" task the HR Evaluation and PM Evaluation Tasks will be automatically created. You will need to log out and login with users in the HR and PM group in order to perform those tasks and complete the process instance.

Join Us Providing your Example Processes

If you have a process example or a business scenario that you want to see working in the KIE Workbench and you think that it can serve as an example for other people to get used to the tool or to show some specific functionality, please get in touch and we can work together to get that included in the jbpm-playground repository. Notice that I would like to keep only high level and business oriented processes inside that repository, so make sure that it make some sense from the business perspective level. We will be creating 
I will be posting more examples over the week, so we can cover a wide range of scenarios that allows users to build their own by copying from the examples or at least using them as guidelines.

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:

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:
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:
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:
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.