Hi Enrique, maybe I couldn't express the concept well. But let's say that the DI has the catalog of all the existing ProcessDefinitions.
To mark a definition as "unavailable" is kind of logically remove it from the Catalog. On 2024/07/04 09:59:00 Enrique Gonzalez Martinez wrote: > Hi walter, this won't give you the data you are aiming for. > > If you have two instances and one goes down the state will be set as not > available unless you compute something in the data index so at least you > will need more information or duplicate lines. This is unlikely to be the > responsibility of the data index. > > El jue, 4 jul 2024, 11:28, Walter Medvedeo <[email protected]> escribió: > > > Hi, the idea is to introduce the requirement/concept first, and summarize > > the impact on the information registered in the DI as much as possible. > > > > And thus, very summarized, the proposal is to include one more filed in > > the ProcessDefinitions information registered by the DI, that will let us > > know if a given definition is still "available" to create instances. > > > > That is a requirement we have from SonataFlow users. > > > > > > On 2024/07/03 20:50:20 Jason Porter wrote: > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > > 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]
