Worfklow Restart after system crash crashes system (ironic I know)

[Alon Raskin]

I have found some peculiar behaviour in transaction SWPC and wanted to share it with the group to see if anyone else had experienced this. 

 

We had a system crash in Production last week which had caused many workflows to 'hang'. We have been using transaction SWPC (Restart Workflow after system crash) to restart the 'hung' Workflows but SWPC has almost crashed our system again! 

 

Our workflows are mostly hung up on a wait step (which is a background step). Using transaction SWPC I noticed that the workflow is restarted under the User ID of the user running SWPC. This is fair enough as it maintains the audit trial in the WF log as to who restarted the workflow. 

 

But here is the unfortunate part. 

 

If I have a 10 step workflow all of which are background. The SWPC transaction will execute all of them under my user ID and enqueue every work item. The result is for every workflow I restart I get 10 entries in the enqueue table.  If I have a few hundred workflows to restart, I very quickly fill up the NQ table and an overflow occurs. Not good. The only time the enqueue locks are released is if I back out of the transaction. IMHO, this should be changed so that the NQ locks are released once the workflow has restarted.

 

This brings me to the next point:

 

I am sure this problem is happening because the advance with dialog flag is still set on each step and therefore all 10 steps are being executed synchronously. I am curious to hear what you guys do? Do you uncheck the advance with dialog flag at the Workflow level (even for background workflows) or are most people like me (lazy) and tend to forget to switch it off?

 

BTW, I logged this with OSS.

 

Alon

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060629/ebc81fcd/attachment.htm