Hi Francisco, To be honest I think this is not a bad idea but I would leave the states aside and focus on the data events stuff. * You can always compute if a process is in waiting state because there are nodes with an enter date but not exit date in that regard. * Another way to compute the waiting state is to see if the entry is not COMPLETED or ABORTED.
What I mean is that if ACTIVE and WAITING are synonyms there is no point to add a state but just to produce virtual engine events like we do with the SLA process instance state event to mark the batch. If you want to mark somehow the end or start of the transaction like we do with the SLA it is fine by me you just need to produce those during operations over the process state but you won't be able to tell when a process is RUNNING (so to speak) because of the problems derived of how we manage events. Cheers :) El jue, 27 mar 2025 a las 14:45, Francisco Javier Tirado Sarti (<[email protected]>) escribió: > > I forgot to add the word "potentially" for data index users. > Right now, since events that are consumed by data index are only sent when > the workflow returns control to the caller (and it return control when is > waiting for something to happen) ACTIVE is equivalent to WAITING, > However, if we decided, in future, to increase the number of events to > improve data index feedback (for example, by publishing an event when the > workflow starts execution) that distinction will start making sense. > > On Thu, Mar 27, 2025 at 2:38 PM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > I have opened https://github.com/apache/incubator-kie-issues/issues/1892 > > describing the issue. Let me elaborate here a bit more, currently we have > > following possible workflow states > > <https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/api/kogito-api/src/main/java/org/kie/kogito/internal/process/runtime/KogitoProcessInstance.java#L29-L34> > > > > > > int STATE_PENDING = 0; > > > > int STATE_ACTIVE = 1; > > > > int STATE_COMPLETED = 2; > > > > int STATE_ABORTED = 3; > > > > int STATE_SUSPENDED = 4; > > > > int STATE_ERROR = 5; > > > > > > The idea is to add an additional one, STATE_WAITING, that will be set when > > the workflow > > > > return control to the caller (BoundaryEvent nodes mainly) > > > > This will allow Data Index users to know if the workflow is active-waiting > > or active-running. > > > > > > For all other purposes, the workflow will still be active. Therefore, > > implementation wise, everyplave in where there is state == ACTIVE, we > > should should state=WAITING (Ill probably add an isActive() method with > > this check) > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
