Original Message:
Sent: Mon December 04, 2023 12:54 PM
From: Carlos Bittrich
Subject: Pattern for DMN rules in batch mode
Thanks @Jaime Izuzquiza and @James Taylor for the participation. It is clearing the landcape.
Regards.
------------------------------
Carlos Bittrich
Original Message:
Sent: Mon December 04, 2023 11:47 AM
From: Jaime Izuzquiza
Subject: Pattern for DMN rules in batch mode
Well, I guess it depends on how the implementation of the caller is carried out. From my experience, there was no coupling at all.
Anyway, I'd also say that there are several things to consider: for instance, if the business requirements specify that the caller requires to tackle decision results one by one, avoiding decision request number 10 being blocked by later decision evaluations (what might happen in a one-shot decision evaluation if something happens to a specific array position)
My opinion, as a summary: both approaches are perfectly acceptable from a technical perspective, and each use case has a technical approach that fits better.
------------------------------
Jaime Izuzquiza
Business automation specialist
Freelance
Madrid
Original Message:
Sent: Mon December 04, 2023 11:36 AM
From: James Taylor
Subject: Pattern for DMN rules in batch mode
Our experience is that the more closely decision engines are deployed to the calling Java code, the more tightly coupled they seem to get. Even if, technically, there's no need to couple them, that seems to be what happens. I don't disagree that you should be able to maintain them independently, but that's not what seems to happen. Hence the preference for stateless, side-effect free decision service deployments.
------------------------------
James Taylor
CEO
Decision Management Solutions
Palo Alto CA
16504003029
james@decisionmanagementsolutions.com
Original Message:
Sent: Mon December 04, 2023 11:27 AM
From: Jaime Izuzquiza
Subject: Pattern for DMN rules in batch mode
Hi James,
What do you mean by "it couples the rules to the Java code"? The DMN project would still be independent from the Java program, which only acts as a DMN consumer the same way a REST client would do.
I agree the DMN model can be designed in a way it accepts an array of inputs instead of a single one, but I don't think the embedded approach couples the rules to the Java code. Modifying the decision logic without changing the Java code would still be possible and it's something I've already put in practice in real projects.
Best regards,
Jaime Izuzquiza
------------------------------
Jaime Izuzquiza
Business automation specialist
Freelance
Madrid
Original Message:
Sent: Mon December 04, 2023 11:16 AM
From: James Taylor
Subject: Pattern for DMN rules in batch mode
Carlos
We don't like to embed the engine in the Java application, unlike @Jaime Izuzquiza, because it couples the rules to the Java code.
You can set up the DMN project to process a batch and use the Kogito engine - we have tested with a 10KB payload and 10,000 transactions for instance and it processed it without restarting the pod or other issues. I believe you can also configure the Kogito server to avoid the restart issue
James
------------------------------
James Taylor
CEO
Decision Management Solutions
Palo Alto CA
16504003029
james@decisionmanagementsolutions.com
Original Message:
Sent: Sun December 03, 2023 04:31 AM
From: Carlos Bittrich
Subject: Pattern for DMN rules in batch mode
Hello, can someone suggest a pattern for calling DMN rules from a batch job? My thinking is that using Kogito as the runtime is the right engine for online transactions with a lot of variability in the processing instances but what happens when a batch job needs to call the same decision for millions of records in a single long running transaction?. I would not like to have the overhead of the RESTprocessing and pod restarts.
Regards.
Carlos Bittrich
------------------------------
Carlos Bittrich
------------------------------