Technical input & supervision: Kacper Klimczuk
In business process management, selecting the right tool for decision modeling is pivotal. One tool certainly worth considering is jBPM–a Java platform that manages business processes and decisions. Modeling business goals by describing the steps in a particular order in the form of depicted flow charts improves the visibility and agility of business logic. Let’s explore the pros and cons of this tool.
Components of Business Process Flow in jBPM
Business process flow consists of many elements like entry point, exit point, or flow direction edges, and–the most important–the task components.
There are three types of tasks:
- user task,
- business rule,
with DMN (Decision Model and Notation) at the center of the last one. Business rules contained by DMNs are elastic, used directly in the business process or called from the code level, with all the necessary decision-making data.
Using DMNs in Practice
Using business rules, specifically DMNs, offers various advantages. Especially when it comes to meeting standard business needs such as separating them from the source code. Another big advantage is the fact that simple models can be constructed by non-technical people.
How to create a DMN model? It must contain an input data block and one or more decision blocks. The first one defines data that the whole model would be based on, whereas decision blocks are the place where processing data should take place.
Single decisions can be modeled as:
- simple instructions, for example checking value from data model,
- structures, for example decision tables, to check multiple conditions.
For coding decision nodes, jBPM employs FEEL (Friendly Enough Expression Language), a language crafted specifically for the nuanced task of modeling business rules. FEEL provides many built-in operators and functions for decision-making tasks.
Strategies for Data Modeling in DMN Models
Every DMN model processes some kind of data to produce decisions. Hence, establishing a data model that fits our needs should be the first step. When it comes to more complex DMN models, there are two general approaches for modeling input data.
- The first is defining simplified data structure on both, the code and jBPM sides.
In this case, we pass to DMN just needed values which are specially prepared to minimize data manipulations on the DMN model side. As a result, we can create simpler models but we bound our source code with business logic because it must be aware of data to properly prepare it and pass it to the DMN.
- The second approach utilizes a special jBPM context data type, which can store unstructured data.
This way source code is no longer bound to the DMN model. However, data manipulations will be much more complex.
Complexities and Challenges in jBPM Implementation
Both solutions have advantages and drawbacks. The first increases code maintenance overhead, whereas the second increases model complexity, causing readability to decrease.
As complexity increases, diagrams become more difficult to understand and reading code becomes harder due to syntax issues, and the use of expression language.
Identifying errors and testing also pose challenges, and the available tools in Business Central may not suffice.
The Practical Reality of jBPM in Business
Ultimately, all of these complications mean that a tool originally designed to be business-friendly requires the involvement of a programmer. In theory, the DMN author can be a less technical person, but in practice, decisions are often modeled by the developer. When the business rule becomes advanced, implementation can prove challenging. Even though at first it may seem simple to use them in processes (mostly drag and drop) it often requires some coding as well. However, jBPM can provide a necessary solution to the requirement to keep the DMNs outside the code.
If you have a business need related to business decision modelling in your application, contact us to schedule a consultation with our subject matter experts. We have you covered!