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.

Re-running a workflow for a business key

jenguran

If I have a workflow with key "Workflow A" and a business entity named "My Customer", start a process instance for them and then cancel it, trying to restart it throws an error because of ACT_UNIQ_HI_BUS_KEY. The same thing happens if I run through the workflow for them and then try to run it again. Is this intended?

Does it really matter if the same workflow has been run (or canceled) sometime in the past for this business key?

Thanks,
Jerry

Find more posts tagged with

Comments

frederikherema1

Hi,

The idea of the business-key is to have your own unique identifier for a process-instance (be it historic or not), independant of the ID's in activiti. So when a process has been started with that ID ever (and history isn't turned off), it cannot be started again.

If you really want to reuse a certain business-key (eg. due to cancelation of process), you should first delete the historic process instance (HistoryService.deleteHistoricProcessInstance()), this will remove all history data.

ronald_van_kuij

Hi,

The idea of the business-key is to have your own unique identifier for a process-instance (be it historic or not), independant of the ID's in activiti. So when a process has been started with that ID ever (and history isn't turned off), it cannot be started again.

If you really want to reuse a certain business-key (eg. due to cancelation of process), you should first delete the historic process instance (HistoryService.deleteHistoricProcessInstance()), this will remove all history data.

Maybe there should be some relaxation in this. Think e.g. About te case where you have a car damage repair process. Using the licenseplate number or the chassis number is logical then, but a car can have damage multiple times. Deleting history would make bam things hard.

frederikherema1

Than it's best to just use a process-variable for this I guess (querying for those is possible too, so can be used exactly the same as business-key). I thought this was more of identifying a process with a single (and unique) identifier within your own app. So the license-plate fits better in variables I suppose

ronald_van_kuij

Yes, my example is not correct (it was early) . It seems to have been the intention of the businesskey to reference a unique instance in the domain model. So it should be a dossier number which is to be unique. Just like I aaaaaaaaalways advocated that past years 🙂

Querying by variable is something I never did. Since if you share the engine in different apps and have requirements to find instances based on different types of variables, the number of indexes explodes and performance crumbles if you have no other option to limit the search first (e.g. processname). So we 'always' did that in the domain model.

jenguran

Cool, thanks for the answers. I'll switch to using a process-variable instead.