WorkflowWS14500014

[Former Member]

Hello everyone

Issue with SRM item level workflow problem.

The evernt BUS2121.RESTARTAPPROVALSTEP is getting trigger by one of the approvers according to the workflow log. I checked in the step Wait for Restart within WS14500014 and the WF log mentions there is a event getting created with that object key from the approver himself. The step gets logically deleted because the forks involving the wait for restart ends and the other branch actually has the code I need to execute to get the right approvers.

I checked the SWEL for the trace of the event and it shows that the approver has created it. However the problem has started to happen only today and approver has not done anything different. Have tried with event logs, event linkages, change SC etc... didnt help. I have checked Note 733133 however the problem is opposite.

I checked the time logs with the sc change and event creation but no luck, the user has not done anything different from the normal.

Could you please help me figure out how was this event BUS2121.RESTARTAPPROVALSTEP triggered? In what cases does the event happen? (I checked with SC changes etc.. but was not able to recreate it in the development/testing system)

You help will be appreciated.

Thank you very much

Swetha

[former_member190818]

Hi Swetha,

I'm facing the same problem which you have mentioned in your thread. Once one of the approver approves the SC, the RestartApprovalStep is getting triggered and it logically deletes both the approvers workitem and it resends to same user.

Can you please let me know what have you done to solve this issue.

I request others to give some inputs.

Regards,

JMB

[Former Member]

The user seems have the approved the SC after a long gap. In the FM BBP_WFL_DIN_APPR_CONTAINER_SET , there is a check for the DB values and approver values. In my case there was custom functionality too, which was included for the workflow restart condition.

[Former Member]

I had this problem and the solution was to remove a line of code from the BADI that cleared ITEM_APPROVAL_OBJ before rebuilding in the BADI code.

My best guess is that the BADI is called from 'who knows where' and 'who knows when', so don't mess with it too much. Keep it simple and it works a treat. Get an Index value wrong, clear the output tables and rebuild them and it all goes horribly wrong and takes ages to debug.

[Former Member]

Hello Swetha,

We are facing exactly the same problem as mentioned in this post from the past 3 days.

May I know what are the steps you have taken to resolve this issue? Any updates would be appreciated.

Thanks and Regards,

Sandeep

[Former Member]

The event comes from the BBP_WFL_DIN_APPR_CONTAINER_SET within which certain customer specific conditions are defined and during this time the workflow was acting craxy bcoz of which the container values dont match the DB values and restart executed. No changes from SC as such necessary for this event to get triggerred

[imthiaz_ahmed]

Two things:

1. Check whether there is any WF security changes happened at the role level or at the user level

2. Check any recent changes to this BADI BBP_DOC_CHANG_BADI, sometimes this also causes problem.

Regards, IA

[Former Member]

Thanks for the reply.. I had checked them too.. no version changes since 2-3 months.