input and output random names in dmnDefinitions.json

[francisco boato]

 Hello, 

Im using kogito 1.20 under spring-boot for creating DMN models in one project, then, dmn are invoked from another project (lets callit controller-app) using Rest call.

To implement the invocation from the controller-app to the kogito app, I use openapi code generator maven plugin, that generates a client based on api-docs.yaml and dmnDefinitions.json.

Im struggling because every time i create a new dmn and then regenerate the client i have to modifiy all invocation to every dmn (even if no changes made to the previous dmn).  The reason is that for every new dmn, kogito modify the name of inputs and outputs of every dmn  (giving what seems to be random numbers such as inputSet1, ... inputSetN).

For example this is a generated class by Kogito:

I would like to know if there is a way to establish the input and output name from the editor, doing so, I will be able to fix the class name for input and output, regardless of other changes.

Greetings,

Francisco

[Matteo Mortari]

Hi Francisco,

thank you for reaching out; I believe I see what you mean: if say a Kogito maven project has 7 DMN models inside, the InputSetN on the OpenAPI will not correspond to the "same" model after each `mvn clean install` of the same Kogito project. Did I get it correctly?

If yes, I would like to kindly ask you to create 2 separate JIRAs, please:

The first one, to capture the Enhancement you described as:

> I would like to know if there is a way to establish the input and output name from the editor

This one, you can make sure it's labeled somewhere for Tooling.

The second one, in the meantime, I could check if there is a way to accommodate some heuristic directly on the backend.

This second one, you can make sure it's assigned to me.

I am thinking that at least I could try to have a consistent ordering of the DMN model while producing the OpenAPI (eg: order by name, namespace) this way for as long as the DMN model coordinates {name, namespace} do not change, the numerical order will be the same.

Alternatively, where possible, instead of the more stable numbering order, plug-in the use as suffix of an escaped label from the model name; this should be even more convenient when adding a new model.

What do you think?

Hope this helps, let us know when the 2 JIRAs are created, please.

Ciao,

MM

--
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/ca28f78d-6b0a-4648-9e4e-f72c4db047f7n%40googlegroups.com.

--

Matteo Mortari

linkedin.com/in/matteomortari

youtube.com/MatteoMortari

[francisco boato]

Thank you Matteo!!  ... before i create the 2 jira issues, I would like to ask if the following situation should also be reported:

This is a fragment of a resourceApi class generated by kogito corresponding to a DMN DecisionService:

As you can see the input and output are named have double underscore "__" prefix, this are the only models with this format (because in another dmn model it has been used the InputSetDS114 and OutputSetDS114 ... without underscore).

This causes me a problem, because when using openapi (JAVA) code generator plugin for create the dmn client.... there is a conflict of class name, because the generator try to "camelcase" the models names (no "modelpropertynaming=original" config option available for java generator) .... so it goes in error because there will be 2 classes with the same name.

I Would like to know if this naming convention (double underscore prefix) in Kogito is something that could be avoided .... otherwise I think I will not be able to auto-generate the client for invoking the DMN model

Francisco

[Matteo Mortari]

Francisco,

thank you for mentioning this; that's exactly the kind of feedback I'm always looking for: I never-noticed / was-not-aware-of this limitation in the OAS toolchain.

Feel free to add this new comment and all your observations in the second JIRA.

Even better, if you could provide a simplified reproducer, that would be ideal.

For example, a git repo containing a very minimal Kogito app with enough "dummy" DMN models to exhibit this problem, and the command you use to run the OpenAPI toolchain which creates the problem you have described.

I mention this because I get an understanding of this issue based on your observation and I do believe I understood it, but a minimal reproducer would make it certain :)

Thank you and looking forward to hearing from you about the JIRAs

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/9fa71879-7da6-433c-b1e4-5ec43f1da950n%40googlegroups.com.

[francisco boato]

I created https://issues.redhat.com/browse/KOGITO-7154 on JIRA. 

I tried to replicate the problem of the underscore prefix in a simpler case  .... but i could not find the reason why this situation is created, as soon as i eliminate some dmn all the names auto-generated changed and the underscore prefix would be no longer present.

By the way ... i hope i were able to explain the situation ... it was not easy (for the problem nature and my poor english ), however i'm available to give further details (if needed)

Francisco.

[Matteo Mortari]

Thank you Francisco and no worries, we'll clarify as needed as iterating on potential solution(s) for it.

Kindly don't forget to track a separate issue for the Tooling, to capture an earlier observation:

>I would like to know if there is a way to establish the input and output name from the editor

for the tooling team.

Ciao,

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/1a6c7431-47bb-4f54-9c1d-ee8fef79d70cn%40googlegroups.com.

[francisco boato]

Hi. Just created https://issues.redhat.com/browse/KOGITO-7158 .