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.

Workflow entry found in ‘ACT_RE_PROCDEF’ but not in ‘ACT_RE_DEPLOYMENT’ table

sandeepkhatri01

Hi,

We are using activiti 5.13. Recently, we came across a scenario where while deleting a workflow we got exception saying - “could not find a deployment”. When we investigated it, we found that there is an entry in ‘ACT_RE_PROCDEF’ table for given workflow, but corresponding record does not exist in ‘ACT_RE_DEPLOYMENT’ table workflow.

Our understanding is whenever we deploy workflow; activiti maintains the record in 'ACT_RE_PROCDEF' and 'ACT_RE_DEPLOYMENT' table. At the time of workflow delete operation Activiti engine deletes the process definition from ACT_RE_PROCDEF table and then its deployment record from ACT_RE_DEPLOYMENT table.

We have hundreds of workflows in system which has entry in ‘ACT_RE_PROCDEF’ but not in ‘ACT_RE_DEPLOYMENT’ table.
Does anyone come across this scenario? Or give us pointer in which activiti will keep the record in ‘ACT_RE_PROCDEF’ but not in ‘ACT_RE_DEPLOYMENT’ table ?

Thanks in advance
Sandeep K

Find more posts tagged with

Comments

jbarrez

Hmm that sounds very strange - normally when a deployment is deleted, the process definitions are deleted too.

Do you know which method is being used that could have deleted the deployment?

You mention you have hundreds of these. Does that mean you've got hundreds of different process definitions?
If not, maybe this could be related to testing?

sandeepkhatri01

Below is the code snipped which is executed when we send delete workflow request.
_______________________________________________________________________________________________________________________________________
List<ProcessDefinition> processDefinations = repositoryService.createProcessDefinitionQuery()
                .processDefinitionKey(processId).list();
        for (ProcessDefinition definition : processDefinations)
        {
            repositoryService.deleteDeployment(definition.getDeploymentId(), true);
        }
_______________________________________________________________________________________________________________________________________
This is taken from testing environment (controlled one) where people deploy workflows based upon their scenarios. Above code is executed when delete workflow request is made. Any pointer what could have happened ?

jbarrez

No, the 'true' in deleteDeployment does mean 'cascade', ie remove all process definitions.

Can you verify, if this code is executed, if the deployment is still there? I checked here, but in my unit test they are gone.

sandeepkhatri01

This code is executed for sure. If I delete a workflow now, I can see that, all the relevant entries from 'ACT_RE_PROCDEF’ and ‘ACT_RE_DEPLOYMENT’ table are removed. I am just wondering in what scenario we will end with having entry in ACT_RE_PROCDEF table and not in ACT_RE_DEPLOYMENT table.

On a different note -
Just checked Activiti schema - There is not any FK constraint on ACT_RE_PROCDEF table referring back Id_ column of ACT_RE_DEPLOYMENT table. Any particular reason for this ? May be this will give me some clue.

Thanks,
Sandeep K

jbarrez

No, cant remember the reason why that was done (this is provably five year old code …). I have no idea how this could have been caused, as far as i know all the regular api methods do not allow it