jBPM is a flexible Business Process Management (BPM) Suite, fully open-source and written in Java. It allows one to model, execute, and monitor business processes throughout their life cycle. Business users can modify business logic and business processes without requiring assistance from IT personnel.
Features and tools:
- Pluggable human task service based on WS-HumanTask, for including tasks that need to be performed by human actors.
- Pluggable persistence and transactions (based on JPA / JTA).
- Web-based process designer to support the graphical creation and simulation of business processes (drag and drop).
- Web-based data and form modeler to support the creation of data models, process and task forms.
- Customizable dashboards and reporting
- All combined in one web-based workbench, supporting the complete BPM life cycle:
- Modeling and deployment – author processes, rules, data models, forms and other assets
- Execution – execute processes, tasks, rules and events on the core runtime engine
- Runtime Management – working on assigned tasks, managing process instances, etc.
- Reporting – keeping track of the execution using Business Activity Monitoring capabilities
- Eclipse-based developer tools to support the modeling, testing and debugging of processes.
- Remote API to process engine as a service (REST, JMS, Remote Java API).
- Integration with Maven, Spring, OSGi, etc.
The web-based designer allows you to model business processes in a web-based environment. It is targeted towards business users and offers a graphical editor for viewing and editing business processes (using drag and drop), similar to the Eclipse plugin.
The full set of elements and attributes that are supported in designing a process flow but it includes mostly used and common elements like:
o Start Event (None, Conditional, Signal, Message, Timer)
o End Event (None, Terminate, Error, Escalation, Signal, Message, Compensation)
o Intermediate Catch Event (Signal, Timer, Conditional, Message)
o Intermediate Throw Event (None, Signal, Escalation, Message, Compensation)
o Non-interrupting Boundary Event (Escalation, Signal, Timer, Conditional, Message)
o Interrupting Boundary Event (Escalation, Error, Signal, Timer, Conditional, Message, Compensation)
o Script Task
o Service Task
o User Task
o Business Rule Task
o Manual Task
o Send Task
o Receive Task
o Reusable Sub-Process (Call Activity)
o Embedded Sub-Process
o Event Sub-Process
o Ad-Hoc Sub-Process
Our focus in this article is to elaborate important aspects of business processes: Human Task Management. While some of the work performed in a process can be executed automatically, there will still be other tasks that need to be executed by human actors. We’ll use RedHat Jboss BPM Suite, alias Business-Central application to provide a demo for Human Task.
jBPM supports a special human task node inside processes for modeling this interaction with human users. This human task node allows process designers to define the properties related to the task that the human actor needs to execute, like – the type of task, the actor(s), or the data associated with the task.
A User Task node contains the following core properties:
- Actors : The actors that are responsible for executing the human task. A list of actor id’s can be specified using a comma (‘,’) as a separator.
- Group : The group id that is responsible for executing the human task. A list of group id’s can be specified using a comma (‘,’) as a separator.
- Name : The display name of the node.
- Task Name : The name of the human task. This name is used to link the task to a Form. It also represents the internal name of the Task that can be used for other purposes.
- DataInputSet : This consists of all the input variables that the task will receive to work on. Usually you will be interested in copying variables from the scope of the process to the scope of the task. (Look at the data mapping section for an example)
- DataOutputSet : This consists of all the output variables that will be generated by the execution of the task. Here you specify the names of the variables in the context of the task that you are interested to copy to the context of the process. (Look at the data mapping section for an example)
- Assignments : Here you will specify which process variable will be linked to each Data Input and Data Output mapping. (Look at the data mappings section for an example)
- Comment : A comment associated with the human task. Here you can use expressions.
- Content : The data associated with this task.
- Priority : An integer indicating the priority of the human task.
- Skippable : Specifies whether the human task can be skipped, i.e., whether the actor may decide not to execute the task.
- On entry and on exit actions : Action scripts that are executed upon entry and exit of this node, respectively.
From the perspective of a process, when a user task node is encountered during the execution, a human task is created. The process will then only leave the user task node when the associated human task has been completed or aborted.
The human task itself usually has a complete life cycle as well. The following diagram is from the WS-HumanTask specification and describes the human task life cycle.
A newly created task starts in the “Created” stage. Usually, it will then automatically become “Ready”, after which the task will show up on the task list of all the actors that are allowed to execute the task. The task will stay “Ready” until one of these actors claim the task, indicating that he or she will be executing it.
When a user then eventually claims the task, the status will change to “Reserved”. Note that a task that only has one potential (specific) actor will automatically be assigned to that actor upon creation of the task. When the user who has claimed the task starts executing it, the task status will change from “Reserved” to “InProgress”.
Lastly, once the user has performed and completed the task, the task status will change to “Completed”. In this step, the user can optionally specify the result data related to the task. If the task could not be completed, the user could also indicate this by using a fault response, possibly including fault data, in which case the status would change to “Failed”.
While the life cycle explained above is the normal life cycle, the specification also describes a number of other life cycle methods, including:
- Delegating or Forwarding a task, so that the task is assigned to another actor
- Revoking a task, so that it is no longer claimed by one specific actor but is (re)available to all actors for anyone to claim it
- Temporarily Suspending and Resuming a task
- Stopping a task in progress
- Skipping a task (if the task has been marked as skippable), in which case the task will not be executed
This sample application explains how to create a business process consisting human tasks with respect to a loan application. In this application, a customer can enter his details post which the bank manager can approve or reject the loan application.
Steps to create and run business process in business-central:
1. Create new business process
2. Drag and drop required events, tasks from the object library palette
3. Create required variables at process level properties
4. Set required parameters for customer human task
5. Set required parameters for manager human task
6. Below is the complete process flow design
7. Generate forms for human tasks
8. Customize customer task forms using form modeler
9. Customize manager task forms using form modeler
10. Build and Deploy ApplyLoan Process. Start ApplyLoan process under process management tab
11. After the process gets started, customer task will be generated under the task tab. Fill in the required details and complete the task.
12. Manager Approval task will be generated. Now, the manager can approve/reject the loan and complete the task.
13. Executed process model can be seen from the process model view under process instances tab.
User Tasks can be used in combination with Swimlanes, to assign multiple human tasks to similar actors. It is a mechanism to specify that multiple tasks in the process should be done by the same actor of the assigned group. So, after the first task instance is created for a given swimlane, the actor should be remembered in the process for all subsequent tasks that are in the same swimlane. A swimlane, therefore, has one assignment and all tasks that refer to a swimlane should not specify an assignment.
If we need to extend loan application process further and forward it to finance department where multiple tasks have to be completed like validating customer documents, crediting loan amount and this ownership has to be given to a single person of finance department (group), this can be achieved by implementing a swimlane.
For more such articles, Keep a tab on our future blogs!
Until next time!!!
- Manager’s Dilema: SAS vs R vs Python
There are countless articles on this topic already, and I must begin by accepting that I am quite late to this superstar battle. However, every time these champions of analytics…
- KAFKA-Druid Integration with Ingestion DIP Real Time Data
The following blog explains how we can leverage the power of Druid to ingest the DIP data into Druid (a high performance, column oriented, distributed data store), via Kafka Tranquility…
- Understanding Memory Tuning in JVM- A Case Study and Analysis
JVM Heap Model The JVM heap model consists of the Young generation and the Old generation memory. The newly created objects are allocated to the young generation memory, as they…
- Introduction to Messaging
Messaging is one of the most important aspects of modern programming techniques. Majority of today's systems consist of several modules and external dependencies. If they weren't able to communicate with…
- Working with SQL Server Database on Microsoft Azure (Part 1)
One of the trickiest implementation for any organization is the database. They require dedicated server and someone to manage it. Cloud services such as Microsoft Azure give organizations opportunity to…
- Middleware Migration Testing
What is Migration Testing? Migration involves moving an old legacy application to a new platform. Migration testing, thus, involves complete analysis and understanding of the old application to gather requirements…