> could you share how users can accomplish the same with the current state of the technology?
Here are examples to demonstrate migration from drl + bpmn in 7.74.0.Final (Ex-ruleflow-bpmn-7.74) to only drl in 10.0.0 (Ex-ruleflow-drl-10.0). https://github.com/tkobayas/kiegroup-examples/tree/master/Ex-ruleflow-migration We can manage ruleFlowGroup with drl. I also added a small util class for convenience (Utils.java). This is something like what I wrote as "C) Just guide how to migrate ruleflow to drl and java code." The Sample-ruleflow.drl looks a little verbose, but not too bad, I think. ruleflow with conditions) https://github.com/tkobayas/kiegroup-examples/blob/master/Ex-ruleflow-migration/Ex-ruleflow-drl-10.0/src/main/resources/com/sample/Sample-ruleflow.drl ruleflow without conditions) https://github.com/tkobayas/kiegroup-examples/blob/master/Ex-ruleflow-migration/Ex-ruleflow-drl-simple-10.0/src/main/resources/com/sample/Sample-ruleflow.drl Toshiya On Fri, Jan 17, 2025 at 1:49 AM Enrique Gonzalez Martinez < [email protected]> wrote: > Hi Alex, > > The only reason working memory exists in BPMN is to be used in > conditional nodes which does not make much sense IMO. (the replacement > for java conditional was already on the way) > This was dropped at some point in kogito (don't know the reasons why) > but makes sense as working memory access does not make sense from the > workflow engine. > How to orchestrate something like you are referring is more rule engine > side. > > El jue, 16 ene 2025 a las 17:05, Tibor Zimányi (<[email protected]>) > escribió: > > > > 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] > > > > > > > > > > -- > Saludos, Enrique González Martínez :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
