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

Reply via email to