Decision Orchestration in Aletyx Enterprise Build of Kogito and Drools 10.1.0-aletyx

Decision orchestration brings together rule execution, decision logic, and process flows to create powerful automation solutions. Aletyx Enterprise Build of Kogito and Drools supports multiple approaches for orchestrating decisions—from modern Rule Units in Kogito to classic Ruleflow patterns in Drools KJARs—enabling teams to build sophisticated decision services that scale across enterprise environments.

Understanding Decision Orchestration

Decision orchestration coordinates the execution of multiple decision components within a larger process flow. Instead of isolated rule evaluations, orchestration allows you to:

• Sequence decision logic across multiple rule sets or DMN models
• Control execution flow with conditional branching and parallel evaluation
• Integrate decisions with processes using BPMN workflows
• Maintain state across complex decision chains
• Handle exceptions and recovery patterns systematically

Orchestration Approaches

Modern Approach: Rule Units in Kogito

The recommended approach for new development uses Rule Units within Kogito applications. Rule Units provide a modular, type-safe way to organize and execute decision logic.

Key characteristics:

• Code-centric design with compile-time safety
• Native Quarkus and Spring Boot integration
• Cloud-native deployment with fast startup and low memory footprint
• Event-driven architecture with built-in Kafka support
• OpenAPI-generated REST interfaces

Example Rule Unit orchestration:

// Define a Rule Unit for credit scoring
public class CreditScoringUnit implements RuleUnitData {
    private final DataStore<LoanApplication> applications;
    private final DataStore<CreditScore> scores;

    public CreditScoringUnit() {
        this.applications = DataSource.createStore();
        this.scores = DataSource.createStore();
    }

    // Getters...
}

// Rules file for CreditScoringUnit
package org.example.credit;
unit CreditScoringUnit;

rule "High Income Applicants"
when
    $app: /applications[income > 100000]
then
    scores.add(new CreditScore($app.getId(), 750));
end

rule "Standard Applicants"
when
    $app: /applications[income > 50000, income <= 100000]
then
    scores.add(new CreditScore($app.getId(), 650));
end

Invoking Rule Units via REST:

curl -X POST http://localhost:8080/credit-scoring \
  -H "Content-Type: application/json" \
  -d '{
    "applications": [
      {"id": "A001", "income": 120000, "age": 35}
    ]
  }'

Response:

{
  "scores": [
    {"applicationId": "A001", "score": 750}
  ]
}

Legacy Approach: Ruleflows in Drools KJAR

For enterprises migrating from earlier Drools versions, Aletyx Enterprise Build of Kogito and Drools provides continued support for Ruleflow orchestration patterns via the startProcess API in KJAR deployments.

Aletyx Enterprise Ruleflow Support

The startProcess method is available exclusively in Aletyx Enterprise for KJAR-packaged applications. This support helps teams maintain existing workflows during migration to modern Rule Units. See Drools Ruleflow documentation for details.

Classic Ruleflow pattern:

KieSession session = kbase.newKieSession();

// Insert facts
session.insert(new LoanApplication("A001", 85000));
session.insert(new Applicant("John Doe", 35, 700));

// Start the ruleflow process to orchestrate rule execution
session.startProcess("LoanApprovalRuleflow");

// Fire all rules following the ruleflow sequence
session.fireAllRules();

// Extract results
Collection<LoanDecision> decisions = session.getObjects(
    new ClassObjectFilter(LoanDecision.class)
);

Ruleflow BPMN metadata requirement:

To enable legacy ruleflow support in your BPMN process, add this metadata attribute:

• Name: LegacyRuleFlow
• Value: true

Without this metadata, you may encounter:

java.lang.IllegalStateException: Illegal method call.
This session was previously disposed.

Ruleflow orchestration capabilities:

Ruleflows use BPMN process definitions to control decision execution:

graph LR
    A[Start] --> B[Ruleflow Group: Validation]
    B --> C{Valid Application?}
    C -->|Yes| D[Ruleflow Group: Scoring]
    C -->|No| E[Ruleflow Group: Rejection]
    D --> F[Ruleflow Group: Approval Logic]
    F --> G[End]
    E --> G

Each Ruleflow Group contains related rules that execute together when that stage of the process is reached.

Hybrid Approach: Business Rule Tasks in BPMN

Both Kogito and traditional jBPM processes support Business Rule Tasks to embed decision logic within larger process orchestrations.

Business Rule Task capabilities:

• DMN integration: Execute DMN decision models with specified inputs
• DRL integration: Invoke Rule Units for complex rule evaluation
• Data mapping: Transform process variables to/from decision inputs/outputs
• Synchronous execution: Decision completes before process continues

Example BPMN with Business Rule Task:

graph LR
    A[Start: Loan Application] --> B[Service Task: Validate Data]
    B --> C[Business Rule Task: Credit Scoring]
    C --> D[Business Rule Task: Risk Assessment]
    D --> E{Approved?}
    E -->|Yes| F[User Task: Final Review]
    E -->|No| G[End: Rejected]
    F --> H[End: Approved]

Configuring a Business Rule Task:

1. Add a Business Rule Task to your BPMN process
2. Configure the rule implementation:
3. DMN: Specify namespace and model name
4. DRL: Specify Rule Unit class name
5. Map process variables to decision inputs
6. Map decision outputs back to process variables
7. Handle results in subsequent process steps

See BPMN Activities for detailed configuration guidance.

Decision Orchestration Patterns

Sequential Decision Chain

Execute decisions in a defined sequence where each decision may influence the next.

Use case: Multi-stage approval process

graph LR
    A[Application Data] --> B[Validation Rules]
    B --> C[Scoring Rules]
    C --> D[Pricing Rules]
    D --> E[Approval Rules]
    E --> F[Decision Output]

Implementation:

• Kogito: Chain multiple Rule Unit invocations within a BPMN process
• KJAR: Use Ruleflow with sequential Ruleflow Groups
• BPMN: Connect multiple Business Rule Tasks in sequence

Parallel Decision Evaluation

Evaluate multiple independent decision sets concurrently for performance.

Use case: Risk assessment from multiple perspectives

graph TD
    A[Application] --> B[Credit Risk Rules]
    A --> C[Fraud Detection Rules]
    A --> D[Compliance Rules]
    B --> E[Aggregate Results]
    C --> E
    D --> E
    E --> F[Final Decision]

Implementation:

• Kogito: Use parallel gateways in BPMN with separate Business Rule Tasks
• KJAR: Define parallel branches in Ruleflow process
• BPMN: Configure parallel gateway with multiple rule evaluations

Conditional Decision Routing

Route to different decision logic based on runtime conditions.

Use case: Product-specific pricing rules

graph TD
    A[Product Application] --> B{Product Type?}
    B -->|Mortgage| C[Mortgage Pricing Rules]
    B -->|Auto Loan| D[Auto Loan Pricing Rules]
    B -->|Credit Card| E[Credit Card Pricing Rules]
    C --> F[Generate Quote]
    D --> F
    E --> F

Implementation:

• Kogito: Use exclusive gateways in BPMN to route to appropriate Rule Units
• KJAR: Use Ruleflow with conditional branching between Ruleflow Groups
• BPMN: Configure gateway conditions based on process variables

Deployment Models

Kogito Microservices

Deploy individual decision services as independent microservices.

Characteristics:

• One service per bounded context: Separate credit scoring, fraud detection, etc.
• Independent scaling: Scale high-demand services independently
• Event-driven communication: Services interact via Kafka topics
• Container deployment: Docker, Kubernetes, OpenShift

Example service invocation:

# Credit Scoring Service
curl -X POST http://credit-scoring-service:8080/scores \
  -H "Content-Type: application/json" \
  -d '{"applicantId": "A001", "income": 85000}'

# Fraud Detection Service
curl -X POST http://fraud-detection-service:8080/check \
  -H "Content-Type: application/json" \
  -d '{"transactionId": "T5678", "amount": 50000}'

Monolithic KJAR Deployment

Deploy comprehensive decision logic as a single application.

Characteristics:

• All rules in one KJAR: Centralized rule repository
• Shared KieSession: Efficient memory usage for related rules
• Spring Boot or standalone: Flexible deployment options
• Traditional application server support: WebSphere, WebLogic, JBoss EAP

Example configuration (Spring Boot):

# application.yml
kie:
  maven:
    settings:
      custom: /path/to/settings.xml
  kjars:
    - groupId: com.example
      artifactId: decision-rules
      version: 1.0.0

Hybrid Architecture

Combine Kogito microservices for new capabilities with legacy KJAR systems during migration.

Migration strategy:

1. Identify bounded contexts: Determine logical separation of decision domains
2. Extract high-value decisions: Move frequently changed rules to Kogito first
3. Maintain KJAR for stable logic: Keep mature, stable rules in existing KJAR
4. Use event integration: Connect systems via Kafka for loose coupling
5. Gradual migration: Move rules incrementally as business value dictates

See Drools Ruleflow Migration for detailed migration guidance.

Integration with Processes

Event-Driven Process Integration

Connect decision services with process workflows via events.

Architecture:

sequenceDiagram
    participant App as Application
    participant Kafka as Kafka Topic
    participant DecSvc as Decision Service
    participant ProcSvc as Process Service

    App->>Kafka: Publish: ApplicationSubmitted
    Kafka->>DecSvc: Consume: ApplicationSubmitted
    DecSvc->>DecSvc: Execute Rules
    DecSvc->>Kafka: Publish: ApplicationScored
    Kafka->>ProcSvc: Consume: ApplicationScored
    ProcSvc->>ProcSvc: Continue Workflow
    ProcSvc->>Kafka: Publish: ApprovalRequired

CloudEvents format:

{
  "specversion": "1.0",
  "type": "DecisionRequest",
  "source": "loan-application-service",
  "id": "A001-20250131-001",
  "datacontenttype": "application/json",
  "kogitodmnmodelnamespace": "https://example.com/dmn",
  "kogitodmnmodelname": "CreditScoring",
  "data": {
    "applicantId": "A001",
    "income": 85000,
    "requestedAmount": 250000
  }
}

See Event-Driven Integration for comprehensive event patterns.

Service Orchestration Integration

Embed decisions within service orchestration workflows.

Pattern:

• Process service invokes decision service via REST
• Decision service returns results synchronously
• Process continues with decision outputs

See Service Orchestration for service task patterns.

Best Practices

Design Principles

1. Separate concerns: Keep decision logic separate from process flow
2. Modular units: Design Rule Units around bounded contexts
3. Stateless decisions: Prefer stateless decision evaluations when possible
4. Clear interfaces: Define explicit inputs and outputs for each decision point
5. Version control: Track decision logic changes alongside code

Performance Optimization

1. Minimize state: Reduce working memory size in rule sessions
2. Optimize rule conditions: Place most selective conditions first (LHS)
3. Use parallel evaluation: Execute independent decisions concurrently
4. Cache results: Store decision outputs when inputs haven't changed
5. Monitor execution: Track rule firing statistics and execution times

Testing Strategy

1. Unit test Rule Units: Test individual Rule Units with comprehensive scenarios
2. Integration test orchestration: Verify decision sequences in full flows
3. Performance test at scale: Validate throughput under production load
4. Test decision correctness: Validate business logic accuracy
5. Test error handling: Ensure graceful degradation on failures

Monitoring and Observability

Key Metrics

Track these metrics for decision orchestration health:

• Decision execution time: Latency per decision evaluation
• Rule firing frequency: Which rules execute most often
• Decision throughput: Decisions processed per second
• Error rates: Failed evaluations and exceptions
• Resource utilization: CPU and memory consumption

Prometheus Metrics Example

# Query decision execution time
sum(rate(decision_execution_seconds_sum[5m]))
  by (decision_name)

# Query rule firing counts
sum(rate(rules_fired_total[5m]))
  by (rule_unit)

Next Steps

• Learn Rule Units: Understanding Rule Units
• Explore Ruleflows: Drools Ruleflow Guide
• Master BPMN: BPMN Activities
• Event Integration: Event-Driven Architecture
• Get Support: Contact Aletyx for migration assistance

PREVIOUS Advanced BPMN: Releasing a New Process Version

NEXT Event-Driven Integration

Was this page helpful?