Hi Gabrielle, As I have been going through the code that communicates the process engine (used both by BPMN and SWF) and the decision one, there is certainly room for improvement there and I agree with you that this should be refactored to use a common approach for inter engine communication avoiding existing code duplication. Therefore I suggest writing a proposal in a different thread so we can work together on that after version 10 has been released. In fact, I'm willing to do so ;) I propose the subject "Using efesto for process and decision engine communication" I would like to remark (probably is clear to everyone, but just in case) that this exercise is not actually related with the PR that has been opened, which just affects the SWF parser (so it recognizes the DMN keyword) and does not touch the existing infrastructure within the process engine to communicate with the decision engine, just made use of it as it currently available.
On Tue, Apr 16, 2024 at 2:22 PM Gabriele Cardosi <[email protected]> wrote: > Hi all! > I basically see two topics in this thread. > On one side there is the SWF business domain, the features it offers to > users (e.g. invoking DMN, or other engines), etc., and I think this has > been sorted out in previous comments. > The other, implicit, one has a broader scope: the option to "combine" > different engines, which is a very interesting feature. > We already have that in place, e.g. DMN -> PMML, BPMN -> DMN, and IINW > there are others, and the currently open PR (that for the moment being is > acceptable, IMO), does not create something new from implementation POV, > but reflects the underlying issues: > > 1. engines-integrations are all based on hard-binding (at dependency > level) of different engines, and that could easily ends-up in another > circular dependency loop > 2. the same problem is faced and solved in different ways, or with > copied-and-pasted code > 3. there is not a common, clear design for what is basically the same > behavior/requirement; and that prevent the creation of one single > solution > to manage the same problems (e.g. integration with external > communication > channels, message exchanges, etc); so that every engine-team is forced > to > dedicate time to solve "integration" issues, instead of working on the > engine-specific features > > > I really hope that the current discussion will help to bring to > attention the above issues, so that we could improve our codebase as a > whole, providing a better design/API. > > M2C > > Gabriele > > Il giorno mar 16 apr 2024 alle ore 13:07 Tibor Zimányi < > [email protected]> > ha scritto: > > > Hi Francisco, > > > > thanks for clarification on the mailing list. As I wrote in my first > > e-mail, I am not against it. I just want to be sure, this is a thing that > > is known publicly, not just from non-official conversations. > > > > For me personally, I don't see the reasoning to have DMN in Sonataflow, > > because DMN is specified as a business friendly (mainly for business > > people, not so technical ones) specification. All things you mentioned, > > that can be executed, are pure infrastructure functions, highly technical > > ones. However, with the clarifications, I will not block this. It is just > > my opinion. I always thought of Sonataflow as a low level orchestration > > platform and not a business automation workflow engine. I would be very > > interested in the opinion of others about this. > > > > Best regards, > > Tibor > > > > On Tue, Apr 16, 2024 at 12:04 PM Francisco Javier Tirado Sarti < > > [email protected]> wrote: > > > > > Hi Tibor, > > > There is not any plan, not expectation, that SonataFlow will execute > > BPMN. > > > That's absurd from my point of view. > > > However, executing a decision rule, which always has inputs and > outputs, > > > maps well with the SWF function idiom (an idiom that already allow a > SWF > > > definition to invoke REST services, GRPC functions, Java code, Python > > > scripts, JQ expressions and Camel, among another stuff). A DRL unit > does > > > not map so well and I do not think applies to the SWF idiom (can be > > forced > > > but I do not feel natural, because a DRL unit, implies the existence of > > > Java POJO as model, which is not an idiom in the SWF spec), that's why > it > > > has not been implemented. > > > About "strategic implications' ', integration with DMN was already > > > discussed as a "nice to have" capability two years ago and was not > > > implemented because of time constraints. Recently it has been raised > > again > > > and now I have time to implement it. Since it was an easy > implementation > > > that does not have project wide implications (or affecting the incoming > > > release), I do not feel there was a reason to discuss it here. > > > Now that we are discussing and has been explained, do you still see any > > > issue? > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 16, 2024 at 10:06 AM Tibor Zimányi < > [email protected]> > > > wrote: > > > > > > > Hi Ricardo, > > > > > > > > "About DRL, same thing. It should be the next step. And having all > > these > > > > technologies playing together out of the box, I believe is what the > > > > community expects from the projects from KIE." > > > > > > > > This is actually the reason why I started the topic in this thread. > > > Because > > > > what the community expects cannot be decided on informal chats. So > what > > > is > > > > the expectation with these changes please? Is it expected from your > > > > perspective e.g. that Sonataflow will also execute BPMN in the > future? > > > What > > > > is the proposal along these changes please? These kinds of things > need > > to > > > > be discussed officially. If not, I will -1 it personally, till we > have > > an > > > > agreement on the mailing list, because this may have strategic > > > implications > > > > around the whole KIE project. > > > > > > > > Best regards, > > > > Tibor > > > > > > > > On Mon, Apr 15, 2024 at 6:29 PM ricardo zanini fernandes < > > > > [email protected]> wrote: > > > > > > > > > Hi Tibor! > > > > > > > > > > > why we have two workflow engines in the KIE project > > > > > > > > > > We just have one workflow engine with two models. BPMN and CNCF > > > > Serverless > > > > > Workflow. Adding support to the former was a strategy our community > > > > > envisioned at the time to leverage the serverless/cloud platforms. > > > Also, > > > > it > > > > > adds support to orchestrate services and events natively from > > > > Kubernetes. I > > > > > don't want to extend too much on this and I don't want to start > > > > discussing > > > > > now why we add support to CNCF Serverless Workflows as I understand > > > this > > > > is > > > > > already something the community agreed to support. > > > > > > > > > > Regarding calling DMN from SonataFlow, as Francisco just explained, > > was > > > > > just a matter of adding a new function type to the parser since we > > > > already > > > > > support it from our main core workflow engine. Users now will be > able > > > to > > > > > run DMN from their serverless applications, which I think is pretty > > > neat. > > > > > It covers a wide of use cases out there (like orchestrating > services > > > and > > > > > using DMN in between invocations, pushing events from a DMN > > invocation, > > > > > etc.). This will surely add to the DMN and SonataFlow projects more > > > > > traction. > > > > > > > > > > About DRL, same thing. It should be the next step. And having all > > these > > > > > technologies playing together out of the box, I believe is what the > > > > > community expects from the projects from KIE. To exemplify how this > > > will > > > > > work, take a look at this Camel example with SonataFlow: > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-examples/tree/stable/serverless-workflow-examples/serverless-workflow-camel-routes > > > > > > > > > > The idea would be the same. Drop the DMN file in your project, > > declare > > > a > > > > > function for it, and call it in an operation state [1]. > > > > > > > > > > Cheers! > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://github.com/serverlessworkflow/specification/blob/main/specification.md#operation-state > > > > > > > > > > On Mon, Apr 15, 2024 at 1:04 PM Francisco Javier Tirado Sarti < > > > > > [email protected]> wrote: > > > > > > > > > > > Hi Tibor, > > > > > > Thanks for opening the topic. > > > > > > This PR adds support for invoking a DMN file from SonataFlow. > > > > > > This PR takes advantage of the fact that DMN file invocation is > > > already > > > > > > supported by jbpm engine and code generator and that the jbpm > > engine > > > is > > > > > > already being used both by SonataFlow and BPMN parsers/code > > > generators. > > > > > > Therefore what this PR does is add DMN support (in a similar way > > that > > > > is > > > > > > done to BPMN parser) to the sonata workflow parser by just > > > recognizing > > > > > the > > > > > > idiom ( a new custom type as per Serverless Workflow > specification) > > > > > > Therefore, Nothing needs to be changed in the jbpm engine or in > the > > > > coge > > > > > > generator. > > > > > > > > > > > > > > > > > > On Mon, Apr 15, 2024 at 5:01 PM 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Tibor Zimanyi > > > > > > > > > >
