In our previous blog, “Enterprise BPM Transformation – Embrace the Change,” we discussed the transformational capacity of BPM and how it helps organizations gain better visibility that translates into higher productivity. Many companies invest in tools like Lucidchart, Visio, Modelio, Pega BPM, ServiceNow BPM, etc., based on their diverse and specific business needs. While each of them has benefits and limitations, we at Radiant highly recommend jBPM. As a Java-based workflow engine, it leverages framework capabilities and externalized assets like business processes, planning constraints, decision tables, and business rules in a unified environment. Business analysts, system architects, and developers can implement their business logic with persistence, transactions, messaging, events, etc. Automated Decisioning Support in jBPM helps analyze, track, and implement tasks using machine learning algorithms that automatically assess and process them. It facilitates process execution using the BPMN 2.0 specifications and Java’s object-oriented benefits. jBPM is helpful as a standalone service or code embedded into your customized service.

Over the years, jBPM has been increasingly used in the following areas:

  • Business processes (BPMN2)
  • Case management (BPMN2 and CMMN)
  • Decision Management (DMN)
  • Business rules (DRL)
  • Business optimization (Solver)

jBPM lets you implement complex business logic with adaptive and dynamic processes that use business rules and advance event processing. jBPM can also be used in traditional JEE applications, Thorntail, or SpringBoot & standalone java programs. Control rests with the end-users who can monitor and work on which processes (wholly or partly) should be dynamically executed.

The Differentiating Features of jBPM 

Benefits of jBPM

  • Better management visibility on business resources and processes and thus improved decision-making
  • Low cost of inputs (at least 30%), less wastage (at least 40%), de-skilled labor requirements, and standardized components.
  • Quality: Consistent and reliable output quality leads to higher customer satisfaction.
  • Meant for everyone: Non-developers can effortlessly design business processes and obtain a much better view of runtime process states.
  • Support for human tasks: jBPM Workflows can also create manual testing tasks or signing off on releases.
  • Graphs: Complex workflows can be easily modeled with jBPM using a graphical designer and the Java code, which performs the workflow-triggered actions.
  • Resilience: Existing workflow definitions remain unaffected by new processes.
  • Flexibility: More variables relating to the approbation flow can be introduced dynamically in the workflow aligned to the specified rules and conditions.
  • Multiple flows: jBPM helps manage multiple workflows simultaneously for a complex business logic through automation.

How we Implemented jBPM for a Ticketing System at Radiant Digital

This section will discuss how we implemented jBPM for a Ticketing System project of our client. The essential features of this implementation include:

  • This project was deployed on an AWS server.
  • jBPM Business Central was used for workflow creation and execution.
  • Our implementation components included Business Rules, Rest APIs, script tasks, human tasks, Data Modular Forms, and Process level variables.
  • Various REST APIs were developed and integrated with the jBPM use case, and the entire service was deployed on AWS.
  • Dashboard and data visualization features have been implemented using Big Data to monitor and execute all the defined workflows’ tasks and processes.

Implementation Steps

  1. Launch JBPM business central.
  2. Business Central has four activity options, Design, Deploy, Manage and track.

  1. Use the “Design” option to create your project space and click to add project and add your required assets by clicking the “Add Asset” option to choose your asset.

  1. For the ticketing system, we used the following steps.
  • Create the ticket using REST APIs or create a ticket using an email sub-process (to create automatically).
  • We used three REST APIs for CREATE, UPDATE, and DELETE operations, deployed them on this code on the AWS server, and used their endpoints in our project.
  • We then defined the required object(s) separately.

Once the object(s) were defined, the form was automatically generated on jBPM. We could edit and design the form as required.

  • The user needed to enter the ticket details in the form, and the form data was routed to store the “Create Ticket” REST API after submitting the details.
  • This form appeared again, asking the user if an update was required. When the user clicked “Yes,” the user could update the ticket details that got stores on the “UPDATE” REST API; otherwise when the user clicks on “No,” the system directly moves on to the next step in the process.

5. After completing the first two steps, the system initiates the “Ticket Routing” sub-process. This sub-process gets the ticket details based on the ticket ID available in the APIs and checks the user’s country and region based on the business rule definition.

6. Based on the region name, the system ended the process and moved to the primary process again, or the aging user needed to enter the interface team name, and the team checked if the user had already been serviced or not. In case the user was not serviced, an ITT checks the TMG and the TOG business rules and ends the sub-process. It then enters the primary process in case the user is not serviced. This loop keeps happening until the user updates the ITT.

Create Ticket Process Flow

An Auto-assign sub-process automatically assigned the ticket for a particular user and sent the notification to that user. Here’s the process flow.

After completing the Auto-assign sub-process, the data again went to the primary process. Here, the data was retrieved using the “Get Task” Rest API, and the system checked if the Task Completion data was due along with the task status and updated these details using the “UPDATE TASK” Rest API.

After completing the Auto-complete sub-process, the data moved to the primary process the “EVENT-SUBPROCESS” API was used. In the primary process, we used the “intermediate” signal to transfer the data. The “start” signal was used to ask the user if additional data needed to be added.

Again, the user could update data by clicking “Yes” when the form appears or “No” to send the validation data. When the form appeared again, the user had to change the status details and call the “UPDATE” REST API, to update the changes. This completed the ticket.

The Ticket Details Form snapshot is given below.

The snapshot of the analytics-driven Ticketing System Dashboard is given below.

jBPM Migration Steps 

The three types of migration to be carried out include runtime process instance, data, and API calls’ migration.

Runtime Process Instance Migration:

jBPM 7.0 comes with an excellent deployment model based on knowledge archives, allowing different project versions to run parallelly in a single execution environment. This is powerful; however, it raises some migration concerns. Some of the pressing questions include:

  • Can users run both the old and new versions of the processes?
  • What shall happen to already active process instances that were started with a previous version?
  • Can active versions be migrated to a newer version and vice-versa?

Active process instances can be migrated, but this is not a straightforward process that can be performed via the jBPM console (aka kie-workbench). You can directly deploy the steps provided in this article to your installation and migrate any process instance. I explicitly use the term “migrate” instead of “upgrade” here because it can move from the lower to the higher version and vice-versa. Few things might happen when migration is performed. These depend on the differences between the process definitions of the two versions.

What does Migration Include?

  • You can migrate from one process to another within the same Kjar.
  • You can migrate from one process to another across Kjars.
  • You can migrate with node mapping between the two process versions.

While the first two options are more straightforward, the third one requires some explanation.

Before we move to the migration scenarios, let’s understand what node mapping is.

While making changes in the process versions, we might end up in a situation where others replace the nodes/activities. When migrating between these versions, node mapping needs to take place. Another scenario is when you’d like to skip some nodes in the current version.

Scenario 1: Simple migration of process instance

This case is about migrating active process instances from one version to another.

  • “default org.jbpm:Evaluation:1.0” project is used, consisting of a single process definition – evaluation with version 1.0.
  • A single process instance is started with this version. Once done, a new version of the evaluation process is created.
  • The upgraded version is then released as part of the “org. jbpm: Evaluation:2.0” project with version 2.0.
  • Then, the migration of the active process instance is performed.
  • The process instance migration results are illustrated on the process model of the active instance and the outcome of the process instance migration.

Scenario 2: Process Instance migration with node mapping

Here, we go one step further and add another node to the Evaluation process to skip one of the original version nodes. For that, we need to map the nodes to be migrated. The steps are almost the same as in scenario 1, except that we need to perform additional steps to collect node information and then let the user manually select which nodes should be mapped to the new version.

Data Migration

  • Two types of processes are involved in data migration. One for the external database migration (ex. MySQL, SQL…) and the other for internal data migration.
  • jBPM has a default repository where all the data is stored. You can also import the code to the external repository and perform runtime migration.

API Calls Migration

The Red Hat JBoss BPM Suite 5 provides a task server bridged from the core engine using the messaging system provided by HornetQ. A helper or utility method called “LocalHTWorkItemHandler” helps you bridge the gap until you can migrate API calls in your current architecture. Since the “TaskService” API is part of the public API, you will need to refactor your imports and methods because of package and API changes.

What you get after the jBPM Migration 

  • A high-performing rules engine based on the Drools project.
  • Improved rule authoring tools and an enhanced user interface.
  • A commonly defined methodology for building and deployment using Maven as the basis for repository management.
  • A heuristic planning engine based on the OptaPlanner community project.
  • Better algorithms to handle a more significant number of rules and facts.
  • A new Data Modeler that replaces the declarative Fact Model Editor.
  • Stability, usability, and functionality improvements.
  • Case management capabilities.
  • A new and simplified authoring experience for creating projects.
  • Intuitive Business dashboards.
  • Process and task admin API.
  • Process and task consoles that can connect to any number of execution servers.
  • A preview of a new process designer and form modeler.
  • A new security management UI.
  • Upgrades to Java8, WildFly 10, EAP 7, etc.

If you’re looking for a seamless jBPM migration or project implementation, we could help you with our industry-leading expertise. 

Connect with us to learn more.

 

 

Big Data