Thank you Enrique for properly detail what I had in mind :) — Alex
On Mon, May 6, 2024 at 1:11 PM Enrique Gonzalez Martinez < [email protected]> 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 < > [email protected]> 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 <[email protected]> > 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 < > > > [email protected]> 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. > > > > > > > > > >
