Wrong identity links

[cgiuliano]

Dear all,
I've implemented some workflows that are started by different sales agents.
Now I see that the ACT_HI_IDENTITYLINK table contains several rows related to sales agents that didn't actually start the specified process instance and hadn't been assigned any task in such workflow. That is strange and is preventing me from getting accurate results when I query the historic processes using the 'involvedUser' filter: a user's query returns process instances that don't belong to him together with the correct ones.

Has anyone any idea on when and what might have added the wrong rows in the identity link table? The sales agents only start a process and then they are no more involved in the process; only one agent is involved within a process instance as the starter user.

Thank you all!
Regards,
Carlo

[cgiuliano]

I'm sorry,
I forgot to add that my workflows are started and managed through Alfresco 4.2.e CE.
I'm trying to find the "culprit" who's adding the incorrect identity links and everything led me to Activiti engine, but I might be wrong.

Regards,
Carlo

[jbarrez]

Can you post the rows in the ACT_HI_IDENTITYLINK table for your processes?
identity links are added for initiator, assignee, candidate groups etc.

[cgiuliano]

Hello Joram,
Thanks a lot for your reply.

The ACT_HI_IDENTITYLINK table contains, for example, the following rows for the process instance 6016538
ID_     | GROUP_ID_  | TYPE_       | USER_ID_ | TASK_ID_  | PROC_INST_ID_
————————————————————————-
6016541 | NULL       | starter     | G9037224 | NULL      | 6016538
6016818 | NULL       | participant | R6371251 | NULL      | 6016538
6050758 | NULL       | participant | L8009157 | NULL      | 6016538
6050777 | NULL       | participant | C4600868 | NULL      | 6016538
6050810 | NULL       | participant | E2835851 | NULL      | 6016538
6215473 | NULL       | participant | G6711794 | NULL      | 6016538
6231132 | NULL       | participant | I5273429 | NULL      | 6016538
6278962 | NULL       | participant | R0784787 | NULL      | 6016538
6345306 | NULL       | participant | E4854347 | NULL      | 6016538(I haven't found a better way to include the table contents here…)

The processed had actually reached the following assignees (in the order)
G9037224 (the starter)
R6371251
C4600868
R6371251
C4600868
I5273429
E2835851
E2835851
while the following had never been involved:
L8009157
G6711794
R0784787
E4854347The "intruders" are all sales agents, i.e. they are the only one allowed to start a workflow and they never have any task assigned.

Thanks for your help.
Kind regards,
Carlo

[jbarrez]

Okay, so there are two ways these user ids could have been added:
- they are candidate users
- they are involved with the task

if the above does not mach your process, then something is wrong. There must some logic that adds these participants.

[cgiuliano]

Hi Joram,
I've tried to find out when the wrong rows are added and found the following.

Looking at the IDs inserted into the involved table, I've derived that the wrong writings occur exactly at the end of a multi instance loop. For instance the following user task is included into a multi instance loop, but actually instanced only once, because the 'act_assignees' variable contains an ArrayList with just one user name ('R6371251') for this specific step.

<userTask id="stepA03" name="Lince" activiti:formKey="axwf:newCustReviewTask">
   <extensionElements>
      <activiti:taskListener event="complete" class="org.alfresco.repo.workflow.activiti.tasklistener.ScriptTaskListener">
         <activiti:field name="script">
            <activiti:string>
               <![CDATA[
                  execution.setVariable("axwf_reviewComplete", true);
               ]]>
            </activiti:string>
         </activiti:field>
      </activiti:taskListener>
   </extensionElements>
   <humanPerformer>
      <resourceAssignmentExpression>
         <formalExpression>${reviewAssignee}</formalExpression>
      </resourceAssignmentExpression>
   </humanPerformer>
   <!– For each assignee, task is created –>
   <multiInstanceLoopCharacteristics isSequential="false">
   <loopDataInputRef>act_assignees</loopDataInputRef>
   <inputDataItem name="reviewAssignee" />
   <completionCondition>${axwf_reviewComplete}</completionCondition>
   </multiInstanceLoopCharacteristics>
</userTask>

By comparing the outcome in ACT_HI_DETAIL and ACT_HI_IDENTITYLINK tables for the specific process instance, I'd derived that the wrong row in the ACT_HI_IDENTITYLINK has been inserted between the update of the variables 'axwf_reviewComplete' and 'nrOfCompletedInstances'. This should occur just after the loop condition has been checked.
ACT_HI_DETAIL (all rows of type "VariableUpdate")
ID_    |NAME_                     |VAR_TYPE_   |REV_|TIME_                  |BYTEARRAY_ID_|LONG_|TEXT_
7219700|bpm_assignees             |serializable|1   |2015-07-30 00:24:44.087|7219699      |NULL |NULL
7219702|bpm_packageItemActionGroup|string      |1   |2015-07-30 00:24:44.120|NULL         |NULL |read_package_item_actions
7219707|axwf_notifUserNameList    |serializable|0   |2015-07-30 00:24:44.127|7219706      |NULL |NULL
7219708|axwf_reviewComplete       |boolean     |1   |2015-07-30 00:24:44.127|NULL         |1    |NULL
7219710|nrOfCompletedInstances    |integer     |1   |2015-07-30 00:24:44.133|NULL         |1    |1
7219711|nrOfActiveInstances       |integer     |1   |2015-07-30 00:24:44.137|NULL         |0    |0
7219716|nrOfInstances             |integer     |0   |2015-07-30 00:24:44.143|NULL         |2    |2
7219718|nrOfCompletedInstances    |integer     |0   |2015-07-30 00:24:44.143|NULL         |0    |0
7219720|nrOfActiveInstances       |integer     |0   |2015-07-30 00:24:44.143|NULL         |2    |2
7219724|loopCounter               |integer     |0   |2015-07-30 00:24:44.143|NULL         |0    |0
7219726|reviewAssignee            |string      |0   |2015-07-30 00:24:44.147|NULL         |NULL |C4600868
ACT_HI_IDENTITYLINK
ID_     | GROUP_ID_ | TYPE_       | USER_ID_ | TASK_ID_ | PROC_INST_ID_
7160779 | NULL      | starter     | A5440140 | NULL     | 7160776
7161056 | NULL      | participant | R6371251 | NULL     | 7160776
7219709 | NULL      | participant | G5530297 | NULL     | 7160776
7219728 | NULL      | participant | C4600868 | NULL     | 7160776
7219761 | NULL      | participant | E2835851 | NULL     | 7160776
7293043 | NULL      | participant | I5273429 | NULL     | 7160776
As you can see the ID_ '7219709' has been used to insert a row in the ACT_HI_IDENTITYLINK table - that is exactly the wrong row. Such ID is right between the IDs used to log the updates to the two mentioned variables.


Do you believe I might be on the right way to reconstruct the issue?
Do you please have any suggestion?

Another thing I was thinking about is that the isolation mode in the MS Sql Server we are using is set to "snapshot isolation". This is the setting strongly adviced by Alfresco when using MSSql.
Is that compatible with Activiti? Can it be part of this problem, maybe due to the fact that the 'act_assignees' variable is serialized as a bytearray?

Thanks a lot in advance.
Best regards,
Carlo

[cgiuliano]

Hello everyone,

Further to my last post I've notice that the ACT_HI_IDENTITYLINK table always include rows without a process_instance_id_.
That sounds strange and I'm wondering what that is aimed at.
Do you have the same behaviour?
ID_      GROUP_ID_  TYPE_    USER_ID_  TASK_ID_ PROC_INST_ID_
1011667  NULL       starter  B0729710  1011644  NULL
1011700  NULL       starter  B0729710  1011677  NULL
1023552  NULL       starter  B0729710  1023530  NULLThanks to anyone who wants to help me on this issue.
Best regards,
Carlo