Hi Enrique, Thanks for the explanation As I said, the proposal is trying to implement the concept of shared context information between workflows. In a particular domain, several and *independent* workflows might want to share the same set of process variables (and its values). One way of implementing that, without really changing the core you are mentioning, is to have a workflow that sets the context (the context setting can be automated itself) and the other workflows (the domain ones) that use it by including the context as part of the input parameters. The other way will be for workflows (of that particular domain) to explicitly read the context using some primitive (so you will have to know that a particular variable is in the "context"). I found this latter less desirable than the former. The workflow designer knows that the workflow has a certain input, it really does not care how this input is provided. It is true that through events or REST invocation, this merging can be manually done (in fact, this is what the user is currently doing, it reads the output from Data index and manually add to the input of the workflow to be executed), but I think it is a reasonable request to ask for some facilities to perform this merge using just runtimes infrastructure (without DI being present). It is true that the whole domain, at least in theory, can be modelled as a huge workflow (this was in fact my first proposal to the user, but they were not really appealed by it, I can try again though), where the first part is the "context" setting and then you can have multiple branches (one per each independent workflow) waiting for human intervention. In this approach, every independent workflow can be invoked as a subflow (triggered by an event or http call). But we need to check how the whole thing will be visualized in DataIndex. So far, there are following options 1) Implement shared context through input parameters. There are two alternative implementations: a) Change Kogito ProcessService (which is not part of the engine) to perform the merge if configuration is present and add interface to existence persistence addon to store the output when the process finishes if the configuration is present, b) Do not touch any existing class, add an addon (only active for users that want this behaviour) that listen for process start and perform the merge there, with an additional addon for each supported DB to read the data to be merged-, This is more implementation work than a), so you now understand why I'm writing so much to adopt a) :) 2) Do not implement shared context, but write the whole domain as a single workflow that invokes independent workflows as subflows based on event triggering. We need to check how this is visualized in Data Index and monitoring.
On Mon, May 6, 2024 at 7:11 PM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > Hi Francisco, > Workflow engine is based at the very core in two different primitives: > events and activities. > > Events are something that happens that initiates and execution. > Catch/throw events of any type, timers, conditions... > An activity is something that produces some sort of computation unit like > script, user taks, etc.. > > Anything that starts a process should be achieved by an event (start), and > a human task is not really an event of any kind. > > There is a primitive called start event with parallel multiple set to true > that covers multiple events definitions that must happen in order to start > a process. We don't have this sort of implementation right now in the > engine.( It is really hard to make it work and requires careful design) but > should be your use case if we had it. One event for process being finished > and other event triggered by some human sending a start with its inputs. > > That being said, about this idea: > > This sort of idea will introduce into the very core of the engine human > tasks as events. I dont see any justification to do that. > > As we did mention at some point, human task will become an entire subsystem > on its own as it does not fit the requirements to be a proper subsystem > with the features we had in v7. > > This introduce a concept of process orchestration based on humans input > which defeats the purpose of a workflow as you are introducing an arbitrary > way of subprocess execution or interdependent process based on humans. It > is not the same of using the output of a human task to trigger the > execution of a subprocess that using human input as a some sort of gateway > event. > > How to perform this: > As Alex mention you can achieve this in a very simple way. > 1. Process finish and send a message to a kafka queue > 2 - third party system gets the events and allows you to manipulate the > input > 3 - it sends to a queue > 4 - process listening to kafka triggers a start event. > > If you dont like the third party system you can create a very simple > process that reads from a stream, allows you to modify the input and sends > the outcome to another stream. > > Cheers > > > > El lun, 6 may 2024, 17:16, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Alex, I might be missing something, but I do not think this scenario can > be > > covered through event consumption. The key part is that workflows of > type B > > are manually executed by users, which will provide its own set of > > parameters. Workflow of type A is just setting a variable context which > is > > shared by all workflows of type B. To simulate such context without > > introducing the concept into the workflow definition itself, the > properties > > setup by A should be passed as input of B. > > > > On Mon, May 6, 2024 at 5:05 PM Alex Porcelli <porce...@apache.org> > wrote: > > > > > Isn’t this already achievable using events with different topics? > > > > > > - > > > Alex > > > > > > > > > On Mon, May 6, 2024 at 11:02 AM Francisco Javier Tirado Sarti < > > > ftira...@redhat.com> wrote: > > > > > > > Hi, > > > > This is related with issue > > > > https://github.com/apache/incubator-kie-kogito-runtimes/issues/3495 > > > > We have one user which would like to reuse the result of one workflow > > > > execution (let's call this workflow of type A) as input of several > > > > workflows (lets call them workflows of type B) > > > > > > > > Workflow A is executed before all B workflows. Then B workflows are > > > > manually executed by users. The desired input of B workflows should > > be a > > > > merge of what the user provides when performing the start request and > > the > > > > output of workflow A. In order to achieve this, it is expected that > > users > > > > include, in the start request of workflow of type B, the process > > > instance > > > > id of workflow A (so rather than taking the output of A and merging > it > > > for > > > > every call, they just pass the process instance id) > > > > > > > > In order for this approach to work, output of workflow A has to be > > stored > > > > somewhere in the DB (Currently runtimes DB only stores active process > > > > information). Since we do not want all process to keep their output > > > > information in the DB (only workflows of type A), workflows of type A > > has > > > > to be identified somehow > > > > > > > > But before entering into more implementation details, which I would > > like > > > to > > > > know is if this is a valid case both for BPMN or not. The > > implementation > > > > implications are pretty relevant. If a valid use case for both BPMN > and > > > > SWF, we can implement this functionality in the kogito core, there we > > can > > > > take advantage of existing persistence addons and add the newly > > required > > > > storage there. If not, we need to provide a SWF specific addon for > each > > > > existing persistence add-on with the additional storage. > > > > Let's share your thoughts. > > > > Thanks in advance. > > > > > > > > > >
