Open Edition

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

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

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

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

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

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

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

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. 

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

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

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

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.

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. 

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

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

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

Thanks @Jaime Izuzquiza and @James Taylor for the participation. It is clearing the landcape. 

Regards.

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.

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. 

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

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

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