Scaffolding & modifying the generated DecisionModels.java

[Rhett S]

Hello,

(thanks for the great kogito tool.)

We've kogito-scaffolded our project to build our REST Endpoints. Then, we copied the 9 generated java class fields in target (including DecisionModels.java) into our src folder. 

We then made changes to DecisionModels.java.

Question: How would we get our changes in src/.../DecisionModels.java compiled?

(It seems that Quarkus Kogito is ignoring them & rebuilding new in the target.)

thanks, Rhett

[Daniele Zonca]

Hi Rhett,

The scaffolding feature is very experimental and as far as I remember it is not possible to customize "model code" (like DecisionModels) and keep the rest of the logic enabled.

I don't have a real answer to your question so can you try to better describe your need?

For example it is already possible to disable REST generation using properties like kogito.generate.rest.decisions (see documentation https://docs.kogito.kie.org/latest/html_single/#ref-kogito-runtime-properties_kogito-configuring ), then just inject DecisionModels (https://github.com/kiegroup/kogito-runtimes/blob/main/integration-tests/integration-tests-quarkus-norest/src/test/java/org/kie/kogito/quarkus/dmn/TrafficViolationTest.java#L35-L36) and use it in your custom REST.

But you mentioned the customization of DecisionModels class too and this is not supported yet.

Which type of changes/missing features is DecisionModels not supporting for your use case?

Daniele

--
You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/6a149c68-8a85-4eac-a7ec-f5353646df19n%40googlegroups.com.

[Rhett S]

Hi Danielle,

Thanks for the response. And thanks for clarifying that scaffolding is experimental. And another thanks those two pointers (disabling REST generation via app props and the idea about the DecisionModels component)- I will definitely practice on them.

What's my motivation to customize the DecisionModels class? 
Well, I was interested in experimenting with another source for my DMNs other than the default resources folder. Perhaps a directory of blob DMNs in Azure storage. Or the results of SELECT query (text column with DMNs XML) from a mySQL. Generalize this a bit- decoupling the DMNs from the resources folder all together- and fetching the XML from an external source at code-regen time, and/or compile time, and/or deploy time. (May seem crazy or unnecessary!)

We will also look into another approach: adding DMNs dynamically to resources folder as part of CI/CD process and leaving the kogito generated code perfectly alone. :-)

Thanks for attention and time. Appreciate any further ideas you have on my scenario. Rhett 

[Matteo Mortari]

Hi Rhett,

that is a very interesting but also very heavily customized use-case.

> ... fetching the XML from an external source at code-regen time, and/or compile time, and/or deploy time. (May seem crazy or unnecessary!)

I am not going to judge the merits of your use-case :)

Beyond what Daniele suggested, in this fully customized scenario you are more using Drools-as-a-library, and you might want to take a look at DMNRuntimeBuilder and kie-dmn-openapi modules.

Both are internal APIs so they might change at any time, and we don't recommend using them directly, but if you are looking for a way to completely handle the build process e2e based on your custom requirements, they might come in handy. The first is the underlying mechanism to generate a DMNRuntime based on generalized resources, the latter is to generate JSONSchema to be used in the OpenAPI descriptor.

> We will also look into another approach: adding DMNs dynamically to resources folder as part of CI/CD process and leaving the kogito generated code perfectly alone. :-)

This to me sounds more easy to do, and more robust :)

This way you can also benefit from the DMN Validation phase(s) we included as part of the Kogito codegen!

Hope this helps,

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/24d5cb40-dc75-4aae-84a2-c6c70e396060n%40googlegroups.com.

--

Matteo Mortari

linkedin.com/in/matteomortari

youtube.com/MatteoMortari

[Daniele Zonca]

Hi Rhett,

Thanks for the clarification, now I better understand your needs :)

A general comment is that Kogito is designed to run on k8s so it leverages the idea of immutable deployments so that k8s can restart/rolling/scale-up/scale-down each deployment/pod without any shared/in-memory status.

The use case you are mentioning is definitely reasonable, it also has many implications to consider related to deployment mode and the general lifecycle:

- Target deployment environment? A containerised environment like k8s?

- Scalability requirement? Multiple replicas/horizontal scaling?

- 24/7 availability? No downtime/rolling updates? 

As also Matteo mentioned, the option to perform a similar activity during CI/CD pipeline seems probably the most reliable.

Daniele

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/CAHOoiEr1H6fk%2B-6FnwuA2taauhQr-ejgsm83mhRYNk_p%2ButcQQ%40mail.gmail.com.

[Edoardo Vacchi]

I would also like to add that for custom REST endpoint, you may want to look at the new experimental API that is landing on 1.13 (due for release somewhere around next week)

https://blog.kie.org/2021/09/kogito-api-incubation.html 

The "incubation" name means that, although experimental and unstable, this will be stabilized into the supported API.

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/CAPpKWi6EH15NQDaBA_60%3DGxocTEe%3DTsJ6MrHBqN2BBRZtikFRQ%40mail.gmail.com.

[Ravi Mangalagiri]

I have been going through all the threads, trying to find if my question has been answered. This thread is the closest!

I do have a similar requirement but with a twist of handling multiple versions.

Use Case:

DMNs are stored in git (feature based development). A 'release' git branch is maintained to handle its version (release-1.0.0, release-2.0.0) 

During build all the dmn artifacts are validated and packaged in a jar and upload to Nexus. This means i have dmn-1.0.0.jar and dmn-2.0.0.jar for both the releases

I am taking Danielle's approach of adding DMNs dynamically to resources folder of the microservice as part of CI/CD process and leave kogito to generate rest endpoints/swagger openapi.json. 

But my requirement needs microservice to support both the versions of the DMNs

Issue:

When I unzip the jar,  as I have same dmn name and namespace in both the jars, one will override the other.

Approach:

For Example: if I have 'policies.dmn' with namespace 'org.sample.dmn' in dmn-1.0.0.jar. And a policy rule change  in the same 'policies.dmn' causing it to have a new release 'dmn-2.0.0.jar'

I plan to play with the namespaces: 

unzip dmn-1.0.0.jar and introduce a 'version' in the namespace org/sample/dmn/1_0_0 and then unzip the dmn-2.0.0.jar with org/sample/dmn/2_0_0 and so on... This way I have all the dmns in the same resource folder.

And as Mattio suggested explore DMNRuntimeBuilder and kie-dmn-openapi modules to generate rest endpoints/swagger openapi.json

I also want to support endpoint url like http://localhost:8080/policies?version=1.0.0

Any suggestion?

[Rhett S]

Hey Ravi,

I appreciate your topic.

Kogito does not support versioning. full-stop. You can name your DMNs like "flight-rebooking~v1", "flight-rebooking~v2".. but that will only get you so far. Particularly because your client won't know in realtime what DMNs and versions are available. You could however write a new web controller that provides an inventory listing of the auto-wired decisionmodel object. from there, the clients could get a list of DMNs available, find the most recent version, and then execute on kogito's auto-generated controller.

Beyond that, I recommend building a custom DMN engine.

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/3b849e86-8071-4dfd-8024-17dcb4d5f0fcn%40googlegroups.com.

[Matteo Mortari]

Hi,

just to add, you don't necessarily need to write any custom code/logic if the Kogito application is managed with "multiple versions" in a cloud-native context such as Kubernetes, etc.

For instance, you could manage "application versioning" with an Ingress definition for example: https://kubernetes.io/docs/concepts/services-networking/ingress/#simple-fanout .

Or analogously in a service mesh like Istio.

These are contexts where "API versioning" blueprints are available not only considering the application logic needs, but all other non-functional requirements too.

Hope this helps,

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/CAMVsg7ABMUd8o24NGk-dfhfmSSeuiv5x8T_MbCdt0QTw2shS-w%40mail.gmail.com.

[Rhett S]

+1 MM. solution could also be done on network/orchestration. 

You received this message because you are subscribed to a topic in the Google Groups "Kogito development mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kogito-development/mOlgQ2nJzis/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/CAHOoiEo%3D85FV_pRKqKqXn77f7xmHCvdaDn7PR0KW7-DFMWUzrg%40mail.gmail.com.