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.

about the process instance business key

heymjo

Hi,

I think that the business key concept in Activiti needs to be clarified. Currently there are 2 restrictions in Activiti with regards to this key AFAICT:

1) there cannot be 2 active process instances with the same business key:

alter table ACT_RU_EXECUTION
    add constraint ACT_UNIQ_RU_BUS_KEY
    unique(PROC_DEF_ID_, BUSINESS_KEY_);
‍‍‍‍‍

2) the process history is not capable of recording 2 instances of the same process definition with the same business key

alter table ACT_HI_PROCINST
    add constraint ACT_UNIQ_HI_BUS_KEY
    unique(PROC_DEF_ID_, BUSINESS_KEY_);
‍‍‍‍‍

In a way this is already conflicting IMO. I can start a process instance with key abc, complete it and then start a new one with the same key, but won't be able to complete() it because the history auditing will throw a unique key violation.

So, conceptually, what is the business key meant to be used for ? If we should use it to assign an application level reference to the process instance, why is it so restrictive ? IMO Activiti should not make any assumption for a business process and just let it start a process with whatever it thinks is meaningful for the business key. If the business allows starting 2 process instances for the same business entity so be it.

On the other hand, if Activiti insists on having unique business keys per process instance it should not allow us to start the process in the first place. That would require a (potentially expensive) history lookup on each process start, which is not ideal either.

See also http://forums.activiti.org/en/viewtopic.php?f=6&t=2922

Thanks

Find more posts tagged with

Comments

trademak

Well, we've chosen to implement it in a flexible way in the API, but with restrictions in the database.
You're right that probably a check should be done if the business key is already available in the history table.
Most users don't pass along a self-generated business key, but let Activiti choose one. Then it's working fine.

Best regards,

ronald_van_kuij

I disagree. What is the advantage of having an Activiti generated businesskey if there are other fields to use that are generated by Activiti like process instance id.

The unique constraint does not add anything in most cases and limits a lot in many… What is the problem with dropping the unique constraint. Everything seems to be still working correctly.

heymjo

Hi,

We removed ACT_UNIQ_HI_BUS_KEY and everything seems to be working still. I don't think there are assumptions in the Activiti code on ACT_UNIQ_RU_BUS_KEY, but i'm not sure. I will create a few unit tests and see.

heymjo

created http://jira.codehaus.org/browse/ACT-1230 for this.

funvin

I see ACT-1230 and it's dupe ACT-997 closed as won't fix, but for my current version of activiti (5.16.4), I don't see ACT_UNIQ_RU_BUS_KEY constraint on ACT_RU_EXECUTION table. Was this constraint dropped in any of the previous releases? What was the motivation behind it?

I think having this constraint helps in ensuring we don't end up with duplicate process instances in a distributed environment. It is possible to use some kind of distributed locking mechanism when creating process instances to ensure uniqueness and avoid race conditions, but that's complicated. Having business key as unique makes it so much more easier.

Is there any other way to achieve this?

_vinay_ @ zulily

trademak

Hi,

Yes the constraint was dropped. The reason was that there are some cases where the business key is not unique and some cases where you would like it to be unique. So we decided to drop the constraint, because you can always add the constraint manually or do an additional query before creating a process instance.

Best regards,

funvin

The problem with doing additional query is, there is no way to avoid race condition in a distributed environment without using distributed locks. I can add the constraint, but I am always wary of changing something I don't own and control. If in the future someone upgrades our version of activiti, the constraint could be dropped again.

So the new semantic of business key is just that it provides domain specific way of efficiently querying (cause it's indexed) the workflow process?

_vinay_ @ zulily