I am not exactly sure what the proposal is here. I see a bunch of background info for this new feature, but I don't see an actual proposal.
On 2024/07/03 15:06:21 Walter Medvedeo wrote: > Hello Guys, > > > Let me share some requirement we have. > > > Right now, as part of the ProcessDefinition information we store in the > Data Index, we record for example the processId and the serviceURL. > > That information is good for users to know, for instance, which are the > existing ProcessDefitnions, and, based on that information, they can for > example start a new process instance by concatenating the serviceURL + “/” > + processId. > > In the context of a SonataFlow Operator driven setups, users need to know > if a ProcessDefinition is still “available”. > > For example, users can deploy a WF, use it for some time, and then, decide > to un-deploy it. From this point, no more instances of that workflow can be > created. The user has just decided to remove that deployment from the > ecosystem. > > However, in the data-index, that definition is still recorded. And users > want to keep it there, since they want to keep consistent information about > the already executed instances etc. (The intention is to not introduce any > information deleting procedure at the DI, etc.) > > On the other hand, users need a way to filter which definitions are still > “available” by using the standard graphql api. > > What we are evaluating is to include a “status” field in the > ProcessDefinitions, with the values available/unavailable, and, that will > be updated as usual via ClouldEvents. In the case of SonataFlow, those > events will be produced by the operator, which governs the > deployment/undeployment, etc. Other setups might just ignore that field. > > Note: we are looking for a very minimalist approach that lets us record > the situation, and facilitate SonataFlow users to query that situation by > using the standard Graphql api. > > This is not any sort of more elaborated clustering > management/monitoring/etc. solution. > > Independently of fine grained details about the event to introduce, which > carries more or less the information we are already sending in the other DI > events. > > From the point of view of let’s say non SonataFlow setups, do you guys see > any objections? > > Regards, > > Walter. > ResponderReenviar > Añadir reacción > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
