Workflow auto task pausing - not able to rerun

we have had instances where we had auto activites fail and a lot of times we were able to rerun the method or rerun using API commands like

resume,c, ... or restart,c, ....

but we have also had instances where the auto activity paused and we were not able to rerun the method by double clicking on the task through workflow history and rerun the method.

None of the API commands worked. Lot of time we kept getting this message

[DM_WORKFLOW_E_ACTION_NOT_ALLOWED] - This operation is not allowed when the state is acquired for workitemid ....

the workflow history for that task showed

<auto activity task name> Acquired Delegate <user name>

Normally the report would show

<task name> Finished Completed <user name>

All our auto activities are run under repository owner account.

Just wondering did anyone else experience such a behavior in their workflow history report ?? and what does that mean or why does that occur (for auto activity it goes into an acquired and delegate status).

I have also played around with changing the r_runtime_state in dmi_workitem to dormant etc ... or the r_runtime_state in dm_workflow to dormant, Failed etc ... but to no help.

Thanks in advance.

Find more posts tagged with

Comments

fenil

acquired-delegate wf history.jpg

Added screen shot of the workflow history where it shows Acquired Delegate for an auto activity.

JorgKrause

Hi,

Assuming that this is custom workflow method (java), can you check your JMS logs,

You will probably see some exceptions that can give you further details.

In addition, you should have failure notifications in supervisors inbox, maybe installation_owner inbox.

Check these notifications, they should provide you fiurther details.

Regards

Jørg

fenil

I think my post was more about how or why the workflow reaches that weird Acquired / Delegate state, if there were issues with the workflow, then it should be paused and I should be able to rerun it.

E.g. We use forms in our workflows in WebTop. there were instances were the form did not get checked in when the user clicked finish. The next step was a auto activity and it failed because it was trying to update a form attribute and it was checked out.

So we go checkin the form (or do a cancel checkout), and then we should be able to rerun the method but it goes in this weird state and this is what we see in history report and are not able to rerun that activity.

Hope this is not too confusing

JorgKrause

fenil wrote:Hope this is not too confusing

Well, not easy to reconstruct the scenario, of course

The aquired state indicates that your wf method actually has started execution, no idea where the delegate comes from.

Did you find anything interesting in the log files? This could possibly shed some light about what happened.

Regards

Jørg

fenil

Sorry for the late reply.

The logs don't help much. The logs do tell me the issue like form was checked out (using above example) but it does not give any other info which would help me understand this Acquire - Delegate behavior of a auto method