nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Proposal: a new API to end a process

f_lombardo

Hi all,

what do you think about creating a new API to end a process? Will it have some drawbacks?

Thanks.

Bye

Franco

Find more posts tagged with

Comments

frederikherema1

"Ending" a process externally is not really BPMN-compliant, if it's not modeled in explicitly ()

However, we have a method on the runtime service which terminates an existing process. The process will just stop, only any "execution-listeners" -which are defined on "event=end" of the process- will be called:

<br> /** Delete an existing runtime process instance.<br>&nbsp;&nbsp; * @param processInstanceId id of process instance to delete, cannot be null.<br>&nbsp;&nbsp; * @param deleteReason reason for deleting, can be null.<br>&nbsp;&nbsp; * @throws ActivitiObjectNotFoundException when no process instance is found with the given id.<br>&nbsp;&nbsp; */<br>&nbsp; void deleteProcessInstance(String processInstanceId, String deleteReason);<br>&nbsp;&nbsp;&nbsp; <br>

f_lombardo

Does this method "clean up" the history of the process?

Thanks.

Bye

Franco

frederikherema1

It does not, you're required to delete the HistoricProcessInstance using the HistoroService, AFTER you deleted the runtime one.

f_lombardo

Uhm… IMHO it sounds a bit confusing: I have to delete a process in order to end it, while the "delete" API doesn't delete it completely…

Anyway I'll try.

Thanks a lot.

Bye

Franco

jbarrez

The reason for this is that some companies want to keep an audit trail of the history, even when things are deleted.

frederikherema1

The same concept as completing a process is applied, once completed it doen't exist anymore in the runtime. History is kept for audit-trail as Joram said.

dimitrihautot

Hello,

For my business case, I need to be able to delete active (i.e. not completed) process instances.
However, for selected users, these deleted instances should be visible.

I am already using the API suggested method
void deleteProcessInstance(String processInstanceId, String deleteReason);for that purpose.

However, I don't see a way to query the (Historic)ProcessInstanceQuery interfaces to include these deleted instances: methods "finished()" and "unfinished()" seem to only take into account the "complete" status of a process instance. Am I wrong?

Thanks!

jbarrez

these deleted instances: methods "finished()" and "unfinished()" seem to only take into account the "complete" status of a process instance. Am I wrong?

Indeed that is correct.

When you query the historic process instance by id, don't they just show up in the query results?

frederikherema1

Perhaps we need a similar query-possibility as we have for HistoricTasks:

<br>/** Only select historic task instances with the given task delete reason. */<br>&nbsp; HistoricTaskInstanceQuery taskDeleteReason(String taskDeleteReason);<br>

When deleting a process, a reason can be passed. If we allow for HistoricProcessInstances to be queries on that, you can differentiate between those processes. A current workaround is maybe to inspect the "end-activity" to see if it has reached the actual end-event or not…

dimitrihautot

Hello team and community,

Indeed, the HistoricProcessInstanceQuery allows to select both running and deleted instances.
As suggested by Frederik, the "end-activity" can be used as a filter, and refinement can be made on "delete reason" string.

So there is definitely a way to find out deleted instances, but as suggested, having a filtering API on the query would be the best.

Thanks for your support, and apologies for delayed feedback…

jbarrez

The easiest to get that in the engine is:

- create apull request yourself of course 😉
- create a jira issue with a link to this forum post so we can plan it

avikganguly

Extremely helpful thread.

Basically, what I understood from it is that the runtime traces of the instance gets deleted keeping the historic instance for audit.

I was kind of hoping that it was a soft delete at the runtime-level as well. That way, it would be very easy to implement an undo delete method in case the process instance needs to be returned to the active pool after inspection from higher roles in the role hierarchy.

Maybe, what I am saying is not sounding BPMN compliant but there are already a lot of process instances in the rejected state which needs this feature and remodelling the workflows to have a different state like "On Hold" is not sounding like a great option because of migration issues.