Proposal: a new API to end a process
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2013 04:50 AM
Hi all,
what do you think about creating a new API to end a process? Will it have some drawbacks?
Thanks.
Bye
Franco
what do you think about creating a new API to end a process? Will it have some drawbacks?
Thanks.
Bye
Franco
Labels:
- Labels:
-
Archive
12 REPLIES 12

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-15-2013 02:00 PM
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…
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…
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-16-2013 06:23 AM
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
- create apull request yourself of course 😉
- create a jira issue with a link to this forum post so we can plan it

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-29-2015 06:35 AM
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.
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.
