Tibor, Well, back to when Drools evolved and expanded to become what today is Apache KIE..... one unique value proposition back in the days was to offer graphical visualization of rules orchestration, starting with .rf which later evolved to bpmn support.
Of course it's possible to do everything using Rule Units, or even without rule units... you can (as crafted by Toshiya) you can do it using rulegroups and only DRLs. Is it the best approach? I personally don't think so... - Alex On Thu, Jan 16, 2025 at 11:05 AM Tibor Zimányi <[email protected]> wrote: > > Hi Alex, > > I think the orchestration could be done with rule units instead of using a > BPMN process to orchestrate the rule execution. However maybe I am missing > some context about rule units and I am wrong. > > Best regards, > Tibor > > > > Dňa št 16. 1. 2025, 15:40 Alex Porcelli <[email protected]> napísal(a): > > > Thank you Toshiya for the reference. > > > > Let me step back ignoring kjar and etc... and ask: could you share how > > users can accomplish the same with the current state of the > > technology? > > > > Use case description: > > As a user, I need - using java api - add thousands of objects to > > working memory and orchestrate 4 or 5 different ruleflow groups and, > > at the end of the execution, access the working memory and iterate > > over the working memory content. > > > > - > > Alex > > > > On Wed, Jan 15, 2025 at 4:32 AM Toshiya Kobayashi > > <[email protected]> wrote: > > > > > > Ah, thanks, > > > > > > This one: > > > https://lists.apache.org/thread/t3o842mbj03c57cg5yw3tmo25qf2br1t > > > > > > > > > On Wed, Jan 15, 2025 at 6:15 PM Enrique Gonzalez Martinez < > > > [email protected]> wrote: > > > > > > > Hi toshiya > > > > Search in *this* list drop legacy runtime in workflow. It is a > > proposal. > > > > > > > > El mié, 15 ene 2025, 9:47, Toshiya Kobayashi < > > [email protected]> > > > > escribió: > > > > > > > > > Thanks, guys. > > > > > > > > > > I searched https://groups.google.com/g/kogito-development , but I > > cannot > > > > > find the discussion about kjar. Anyway, Kogito hasn't supported kjar > > from > > > > > the beginning, so it's a very old story. > > > > > > > > > > Having said that, options seem to be: > > > > > > > > > > A) Create a small subset of bpmn parser and engine (apart from the > > kogito > > > > > bpmn code base), which aims at only ruleflow (Start, End, Rule, > > Gateway). > > > > > > > > > > pros: Users can use the existing bpmn editor to author ruleflow > > bpmn > > > > > files. > > > > > No need for a migration tool. > > > > > > > > > > cons: It will likely have some duplication with the kogito bpmn > > code > > > > > base. > > > > > > > > > > B) Create a new feature to support ruleflow. e.g. only changing > > > > > ruleflow-group with/without conditions. It may or may not be like .rf > > > > file > > > > > > > > > > * Note: This option's pros and cons are ambiguous as the details > > are > > > > not > > > > > yet defined > > > > > > > > > > pros: The implementation may be smaller than bpmn > > > > > > > > > > cons: Developing a migration tool would require some effort. (or no > > > > > migration tool) > > > > > Developing an authoring UI tool would require some effort. > > (or no > > > > > authoring tool) > > > > > > > > > > C) Just guide how to migrate ruleflow to drl and java code. > > > > > > > > > > pros: No additional development > > > > > > > > > > cons: Probably it's not possible to create a migration tool. It may > > > > > require a large effort if a user has lots of ruleflows > > > > > > > > > > Any thoughts? > > > > > > > > > > Toshiya > > > > > > > > > > On Mon, Jan 13, 2025 at 6:13 PM Enrique Gonzalez Martinez < > > > > > [email protected]> wrote: > > > > > > > > > > > Jason, > > > > > > At the moment we dropped support for legacy runtime kjar is not a > > > > > supported > > > > > > scenario in workflow. > > > > > > > > > > > > El vie, 10 ene 2025, 17:24, Jason Porter <[email protected]> > > > > > > escribió: > > > > > > > > > > > > > I think however this ends up being decided by this list, we > > should > > > > > post a > > > > > > > conclusion/example/summary/something to the [email protected] > > > > > <mailto: > > > > > > > [email protected]> list so anyone search that list can see > > the > > > > > > results. > > > > > > > > > > > > > > Somewhat related to that, do we want to try to migrate people > > from > > > > the > > > > > > > Google Groups list to the users list now that 10.0.0 is released? > > > > > > > > > > > > > > -- > > > > > > > Jason Porter > > > > > > > Software Engineer > > > > > > > He/Him/His > > > > > > > > > > > > > > IBM > > > > > > > > > > > > > > > > > > > > > From: Alex Porcelli <[email protected]> > > > > > > > Date: Friday, January 10, 2025 at 01:41 > > > > > > > To: [email protected] <[email protected]> > > > > > > > Subject: [EXTERNAL] Re: [DISCUSSION] ruleflow kjar use case > > > > > > > Thank you, Toshiya, for bringing this up to ML. > > > > > > > > > > > > > > For context, I’d like to remember that there are no Drools or > > jBPM; > > > > > both > > > > > > > are components of Apache KIE. > > > > > > > > > > > > > > As of today, Apache KIE 10 supports kjar; Toshiya's example > > proves > > > > > that. > > > > > > > Therefore, this could be considered a bug, not a new use case. > > > > > > > > > > > > > > Enrique, regarding parity between runtimes, it’s not necessary to > > > > > provide > > > > > > > the same level of feature support for all of them, so the scope > > of > > > > rule > > > > > > > flow could be narrowed. > > > > > > > > > > > > > > What I believe we can’t do is be dysfunctional and force drops of > > > > major > > > > > > > features after a major release without a proper heads-up or an > > > > > > alternative > > > > > > > path. > > > > > > > > > > > > > > - > > > > > > > Alex > > > > > > > > > > > > > > On Fri, Jan 10, 2025 at 12:10 AM Enrique Gonzalez Martinez < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > Hi toshiya > > > > > > > > > > > > > > > > Kjar is not supported in workflow as the main focus is codegen. > > > > > > > > Supporting in memory compilation would lead us to support two > > > > > different > > > > > > > > runtimes and integration with drools. > > > > > > > > At this point it might be working because the legacy runtime is > > > > still > > > > > > > there > > > > > > > > but any attempt to support this in kogito will get pushed back > > as > > > > we > > > > > > are > > > > > > > > removing thr old runtime therefore kjar wont work. There are > > > > several > > > > > > > > reasons for it. From how big the effort would be to parity > > features > > > > > in > > > > > > > both > > > > > > > > runtimes. > > > > > > > > So the answer is no. We should not. > > > > > > > > > > > > > > > > El vie, 10 ene 2025, 4:20, Toshiya Kobayashi < > > > > > > [email protected] > > > > > > > > > > > > > > > > escribió: > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > Since Drools 8, in other words, since jBPM was moved into > > Kogito, > > > > > the > > > > > > > > > ruleflow (drl + bpmn) kjar use case has been dropped, because > > > > > Kogito > > > > > > > > > doesn't support kjar. A user is facing a migration problem ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://kie.zulipchat.com/#narrow/channel/232677-drools/topic/Errors.20when.20moving.20from.20last.20Drools.207.20release.20to.20drools.208 > > > > > > > > > ) > > > > > > > > > > > > > > > > > > The combinations may sound confusing. > > > > > > > > > > > > > > > > > > - drl + bpmn in kogito service is supported. (See > > > > > > > process-quarkus-example > > > > > > > > > in incubator-kie-kogito-examples) > > > > > > > > > - drl in kjar is supported (See kie-maven-plugin in > > > > > > > incubator-kie-drools) > > > > > > > > > - drl + bpmn in kjar is the topic of this thread > > > > > > > > > > > > > > > > > > I created an example with KIE 10.0.0 + drl + bpmn + kjar. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/tkobayas/kiegroup-examples/tree/master/Ex-ruleflow-10.0.0 > > > > > > > > > (Adding org.kie.kogito:jbpm-bpmn2 dependency) > > > > > > > > > > > > > > > > > > ``` > > > > > > > > > mvn clean install -DskipTests > > > > > > > > > mvn test > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > It seems to work fine so far. (It has an issue with "import" > > > > > > handling, > > > > > > > > but > > > > > > > > > I worked around it using FQCN. It's another story...) > > > > > > > > > > > > > > > > > > Having said that, shall we revitalize the ruleflow kjar use > > case? > > > > > > > > > > > > > > > > > > I think of these points: > > > > > > > > > > > > > > > > > > 1. Confirm the supported scope : No persistence. Limited > > nodes > > > > > > (Start, > > > > > > > > End, > > > > > > > > > Rule, Gateway?) > > > > > > > > > 2. Consult jbpm developers because the new jbpm has been > > targeted > > > > > > only > > > > > > > > for > > > > > > > > > kogito service use cases (= requires quarkus or springboot, > > and > > > > > > depends > > > > > > > > on > > > > > > > > > codegen. Am I correct?). Any caveats to support kjar? > > > > > > > > > 3. Create test cases in kogito-runtimes? > > > > > > > > > > > > > > > > > > Especially, about 2... Any concern about supporting kjar with > > > > jbpm > > > > > (= > > > > > > > > > org.kie.kogito:jbpm-bpmn2)? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Toshiya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
