From Chaos to Clarity: A Four-Part Strategy for Orchestrating Business Rules with Kogito

If you’ve ever had to update a complex application, you’ve likely encountered the tangled web of if-else statements and boolean flags that govern core business logic. This "spaghetti code" isn't just a technical headache; it’s an agility problem. When a business rule changes, you shouldn’t have to go through a full development and deployment cycle.

This is where Rule Orchestration comes in, and with Kogito BPMN, we can go beyond a single solution to adopt a strategic, four-pronged approach.

In this blog we will specifically look into existing code and rule orchestration patterns which we can extract and prepare design draft for future implementation.

When observing a client’s business rules, I grouped them into four distinct categories, each with its own optimal implementation pattern. This method ensures that we use the right tool for the job, leading to a more maintainable, scalable, and agile system.

Before coming up with design draft for rule engine, below task needs to be done to understand the scope and timelines.

1. Understand existing rules and logic implemented and then decide a rule definition and falls into which category.
2. Prepare tree diagram for rules execution to understand the sequence.
3. Prepare dependency graph for rules execution, this will help in optimizing the rules and to check if rules can be executed in parallel.

Now, Let’s dive into these four categories and how to implement them with Kogito.

The Four Categories of Rule Implementation

1. Rule Implementation Using BPMN

For simple, straightforward business rules that are essentially part of the process flow, you don’t need to leave the BPMN canvas. This approach is best for decisions that can be represented as conditional branching.

• Use Case: A process that needs to check if a user is a “Premium” or “Standard” customer to route them to a specific service team.
• Kogito Implementation: You implement this with an Exclusive Gateway. The outgoing sequence flows from the gateway are given simple, clear conditions based on process variables (e.g., #{customer.type == "Premium"}). This keeps the logic visually transparent and directly tied to the process flow. This pattern is ideal when the decision logic is simple and unlikely to change frequently.

2. Rule Implementation Using DMN

For complex decision logic that can be expressed as a decision table or a set of business rules, DMN (Decision Model and Notation) is the perfect tool. This approach completely separates the rule logic from the process flow.

• Use Case: Determining a customer’s discount based on their loyalty status and the value of their transaction. This involves multiple conditions and outcomes.
• Kogito Implementation: You use a Business Rule Task in your BPMN diagram. This task is configured to call a specific DMN model, which you define separately (e.g., in Kogito’s DMN editor). The DMN table receives the customer data as input and returns the calculated discount. This empowers business analysts to directly manage the rules, and a change to the discount matrix doesn’t require a BPMN model update.

3. Rule Implementation Using BPMN + Code

Sometimes, a business rule involves custom logic that is too complex for a simple gateway or a DMN table but is reusable and part of the orchestration flow. In this case, you can combine the visual process of BPMN with a well-encapsulated piece of code.

• Use Case: A process that needs to check product inventory levels, which requires calling an external API and performing some business calculations on the response.
• Kogito Implementation: You use a Service Task in your BPMN model. This task is configured to call a specific method on a Java class (or a Spring/Quarkus bean). The Java code contains the complex business logic (e.g., making the API call, handling the response, and updating a process variable). This keeps the code separate from the process diagram but allows the process to control when and how it’s executed.

4. Rule Implementation Using Pure Code (Java Processor)

For highly complex business logic, especially calculations or algorithms, that is not part of the main process orchestration but is needed to pre-process data or provide a critical input, a pure code approach is best. This rule is often executed by a dedicated, independent service.

• Use Case: A sophisticated credit score calculation that involves a proprietary algorithm. The result is a single score that is then used by the BPMN process for a downstream decision.
• Kogito Implementation: You model this as a call to an external service. You can use a Service Task configured to make a REST API call to a separate, dedicated microservice (your “Java processor”) that performs the complex calculation. The process passes the required data, and the external service returns the result. This ensures that the core BPMN process remains clean and focused on orchestration, while the complex, potentially frequently updated business logic lives in its own, independently deployable service.

Implementing with Subprocesses

Best Practice which i followed is to keep your main BPMN orchestration clean and readable, you can implement each of these rule categories inside subprocesses. You can use:

• Embedded Subprocesses: For a tight logical grouping, where the subprocess is fully contained within the parent process.
• Call Activities: To reference and reuse a separate, independent process (e.g., your “Java processor” service or a shared DMN-based validation flow) as an external subprocess.

This approach ensures that your main BPMN diagram is a high-level view of your business process, with the details of specific rule categories neatly abstracted away into their own logical units.

By strategically using these four categories, you can design a rule engine that is not just functional but also highly adaptable and easy to maintain, providing true business agility.