IBM Business Automation Community Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
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.
Have a look at this. You can avoid overhead by embedding the DMN engine in your Java application.
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
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.
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.
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.
Thanks @Jaime Izuzquiza and @James Taylor for the participation. It is clearing the landcape.
Glad to help @Carlos Bittrich. And always happy to read about different points of view @James Taylor :)