Hi, yes, it's a sort of deployment/un-deployment marker, but in a higher level of abstraction.
We use the term "available" to make it conceptually separated from any particular setup/platform or deployments strategy, given the so much possibilities that people can use with kogito. (docker compose, standalone JVM's, k8n, etc, DI as a separate service, DI as a collocated service, etc) And thus, by saying for example "unavailable", we are not indicating details about the underlying setup. Instead, we are just saying, for that ProcessDefiniton you can't create instances anymore. Regarding 1: I'm not sure if I understand Enrique. But, if you are suggesting to execute a graphql query to see how many process instances are still alive for a given ProcessDefinition, and based on that, determine if that definition is still "available" to create new instances. This do not resolve the requirement. Because the fact that you don't have instances right now, doesn't mean that the ProcessDefiniton is not available anymore. Users create instances at any time. On the other hand, If you suggest to execute a graphql query to see if the ProcesDefintion is there, and, based on that determine if it's "available" or not to create new instances. This don't resolve the requirement. Because, independently of the setup you use, the DI never deletes ProcessDefinitions from DB. Independently if you decided that you don't want to work with that definition any more, it remains in DB forever. This is why we are looking for that minimalist approach to resolve the requirement. Regarding 2: yes, the platform handles the deployment. And the event is sent to the DI to only populate the "status" field indicate the availability/unavailability. On 2024/07/04 05:46:22 Enrique Gonzalez Martinez wrote: > Hi guys... This is a deployment/undeployment event. > Regarding the process definition is not really an event but it is mixed in > there. > 1. you can already check database to check how many process at a certain > version are to see if a deployment is required or not. The status should > not be required anyway. > 2. Regarding how to handle deployment should be done somehow by the > platform. So issuing the events should be enough > > Cheers > > El mié, 3 jul 2024, 22:50, Jason Porter <[email protected]> escribió: > > > 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]
