Although it may look like a simple integration, we should also evaluate the affinity between the technologies, as already pointed out in this thread. There's a general agreement that DMN and SWF are for different target audiences, and—besides being asked by a community member—we don't necessarily need to implement "just because" without a proper evaluation of the possible confusion that this might create.
There's also the aspect related to procedures. Although small codebase changes, introducing such integration between components that target different abstraction layers would - at minimum a HEADS UP email so this could be discussed before implemented. It has been mentioned in the thread that this feature was discussed years ago... but neither other members of the community nor I was in the room where this was discussed, nor did we have minutes available with such information - so we need to be thoughtful and use the proper Apache channels (ML!) to communicate and discuss the direction of things. Personally, I find this integration to be a bit confusing. However, I won't -1 if we clearly state that this is an experimental feature and likely to be replaced in the future with a more suitable format, such as yaml-based decision tables (if I recall correctly, such a format was mentioned). - Alex On Tue, Apr 16, 2024 at 2:34 PM Francisco Javier Tirado Sarti <[email protected]> wrote: > > The fact that the new SWF DMN module is optional is probably better > perceived in the example PR > <https://github.com/apache/incubator-kie-kogito-examples/pull/1906/files#diff-482ece0498351646309f2a00000bd4702c2aae92771e0abc79ff0c85abb8f197R79-R86>. > Users will have to explicitly add the two linked modules in order to have > the feature available in quarkus. > > > > On Tue, Apr 16, 2024 at 8:29 PM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > Hi Mark, > > Yes, the new SWF DMN module is optional (this can be easily checked in the > > PR > > <https://github.com/apache/incubator-kie-kogito-runtimes/pull/3468/files#diff-f770ef88ba3f52f02edbcf80521cd6e34959e819ec7da4169b55e38a5562b37f> > > ). > > Besides that, we are going to work, as part of a proposal from Enrique, to > > pull out the RuleSetNodeInstance from the process engine core and move it > > to a different module. Once this is done, the DMN dependency will indeed be > > optional for SWF or any other parser built on top of the process engine. > > Currently, to avoid including DMN in the set of dependencies for SWF, we > > setted it to optional explicitly in the jbpm-flow pom > > <https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/jbpm/jbpm-flow/pom.xml#L63> > > (an approach that is a bit hacky and usually indicates you need to improve > > your design, as we are doing ;) ) > > > > On Tue, Apr 16, 2024 at 4:26 PM Mark Proctor <[email protected]> wrote: > > > >> All workflow definitions need decision capabilities and will be delegated > >> to some subsystem or external system. > >> > >> I think decisioning is orthogonal enough to workflow (BPMN or SWF) that we > >> shouldn't be too worried, as long as it is not coupled in any way and > >> fully > >> optional. Also, the complexity (or technical burden) introduced by any > >> integration is probably not at a level that I think anyone needs to be > >> overly concerned. Or at least we should ensure that any decision > >> capability > >> is optional, for the end-user, and the implementation is not creating any > >> long term burden. I don't believe the proposal is going against anything > >> I've said here. > >> > >> I do agree that I'm not sure DMN as a format is the best fit for SWF, and > >> I > >> know Matteo did some POC work showing a format that was more aligned. > >> However, that work isn't available yet and is currently paused; we need to > >> pick it back up again. In the meantime, as long as it's kept optional I > >> have no concerns if there is community demand for DMN with SWF > >> > >> Mark > >> > >> On Mon, 15 Apr 2024 at 16:01, Tibor Zimányi <[email protected]> wrote: > >> > >> > Hi everyone, > >> > > >> > I noticed multiple discussions on Zulip and also a PR opened (1) about > >> > executing DMN from Sonataflow. I am opening this thread (because I > >> didn't > >> > notice one), so we can discuss, if we want to do it. First of all, I > >> want > >> > to write, I am not against it. I just want us to be completely sure, > >> that > >> > it is what we want to do. Because from my perspective, it opens multiple > >> > other discussions about the KIE workflow portfolio. One of them could > >> be, > >> > why we have two workflow engines in the KIE project, if we want to > >> execute > >> > all file types from everywhere (I read discussions on Zulip about DRL > >> being > >> > executed from Sonataflow too). It could imply, that we need a portfolio > >> > consolidation and similar, because we are able to execute DMN and DRL > >> from > >> > the BPMN workflow engine. > >> > > >> > What are your opinions please? > >> > > >> > Best regards, > >> > Tibor > >> > > >> > (1) https://github.com/apache/incubator-kie-kogito-runtimes/pull/3468 > >> > > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
