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

[Mike Gambier]

For those of you not on 4.7+ you may also be interested to know that 
RSWEQSRV has a tendancy to overun and respawn multiple batch jobs to issue 
the same events from the queue if you're pretty agressive on your SWEQADM 
settings. (We deliver 100 events every minutefrom the queue!).

This meant we saw multiple Workflows kicked off for the same event which 
caused havoc for a while until we worked out was going on.

To get round this we have cloned the prgram and made our version more 
self-aware by checking for running jobs and self-terminating if an earlier 
job is already running.

Thanks SAP for not building any kind of event locking : (

MGT

>From: "Mike Gambier" <madgambler at hotmail.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: sap-wug at mit.edu
>Subject: RE: Worfklow Restart after system crash crashes system (ironic I 
>know)
>Date: Thu, 29 Jun 2006 12:51:07 +0000
>
>Alon,
>
>Almost certainly that's a bug with RSWWDHEX that we've had to bypass here
>too.
>
>The standard SAP report experiences a lock overflow when it tries to lock
>all of the Wait step entries in SWWWIHEAD.
>
>In the end our SAP guy (Trevor Ticehurst, who may know) hatched a cunning
>plan to create a copy program that avoided this.
>
>MGT
>
> >From: "Alon Raskin" <araskin at 3i-consulting.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: <sap-wug at mit.edu>
> >Subject: Worfklow Restart after system crash crashes system (ironic I 
>know)
> >Date: Thu, 29 Jun 2006 08:43:16 -0400
> >
> >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
> >
> >
>
>
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug