Event Raised - WF-BATCH Configured - No Workflow

Morris, Eddie eddie.morris at sap.com
Fri Sep 13 02:45:42 EDT 2013


Hi James,

Do you have WORKFLOW_LOCAL_XXX registered in SMQS by any chance? (Queuing of tRFC's)

If so please make sure there are enough resources to cope with high load situations as well as  regular traffic. Maybe looking at increasing Max Conn and Max Runtime and if you have not assigned an AS Group in SMQS then maybe do so to ensure specific servers are available to SMQS. If the resources for SMQS are not sufficient then you start seeing a backlog in SM58 and delay in workflow execution of tRFC's.

Also if you have situations where many events are created at once I would suggest you use the event queue if possible and stagger the delivery....saves the system from being overwhelmed.

If you do not have WORKFLOW_LOCAL_XXX registered in SMQS then simply ignore all the above :)

Regards,
Eddie

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of James Johnson
Sent: Thursday, September 12, 2013 9:31 PM
To: SAP Workflow Users' Group
Subject: RE: Event Raised - WF-BATCH Configured - No Workflow

Hi all,

As promised, here's an update - we fixed the issue. The fix in my instance requires the Basis team to conduct a number of resolution actions.

Cause of the issue: poor performance in table access of SWWWIHEAD and SWW_WI2OBJ, ARFCSSTATE, ARFCSDATA, ARFCRSTATE, TRFCQOUT, TRFCQIN, TRFCQSTATE and TRFCQDATA tables (the first two being core workflows, the rest being Basis tables).  A time-out was occuring on the tRFC used to request workflow creation in the instances where a dialogue process was attempting to be used.  The process was dialogue (instead of background) as the events/workflows affected were created under the user's name instead of WF-BATCH.

Fix: One-off rebuild of the index for SWWWIHEAD and SWW_WI2OBJ, in addition to the update of the statistics for those tables.  Recommendation to Basis for a daily process to be instigated going forward, where indexing is rebuilt for the above Basis tables (due to their rapid expansion and contraction in size, the index rapidly degenerates).  The affected tRFCs (where events delivery didn't create the associated workflow) were re-executed by Basis and all workflows were produced.

Result:  Event delivery now causes the associated workflow to be produced, in 0.5 seconds compared to a time-out occuring after 10 minutes.  Happy workflows means happy James :).

Best Regards,
James Johnson

E-mail:JJohnson at uk.ibm.com
Mobile: 07908715224 or 07920870270



From:        James Johnson/UK/IBM at IBMGB
To:        "SAP Workflow Users' Group" <sap-wug at mit.edu<mailto:sap-wug at mit.edu>>,
Date:        11/09/2013 11:30
Subject:        RE: Event Raised - WF-BATCH Configured - No Workflow
Sent by:        sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>
________________________________



Hi Ed,

That's a pretty daring approach, deleting stuff out of workflow master data tables usually results in bad things.  Yes, we got the same issue in production, the BASIS guys are looking into the RFC statuses in SM58, SCN also suggested authorisation to execute RFCs as a possible issue but they haven't changed in this case (and before this issue manifested, there was a period where workflows were creating, just with a ~8 hour delay after being delivered from the event queue). Next test is amending the workflow to 'general task,' will let everyone know how the issue gets resolved :)

Best Regards,
James Johnson

E-mail:JJohnson at uk.ibm.com
Mobile: 07908715224 or 07920870270



From:        Edward Diehl <edwarddiehl at hotmail.com<mailto:edwarddiehl at hotmail.com>>
To:        "SAP Workflow Users' Group" <sap-wug at mit.edu<mailto:sap-wug at mit.edu>>,
Date:        10/09/2013 19:22
Subject:        RE: Event Raised - WF-BATCH Configured - No Workflow
Sent by:        sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>
________________________________



Thanks, James.
We were able to get workflows going again by deleting bunchs of stuff out of SWWWIHEAD, etc.  When we copied production to the test system it was a total misfit from a capacity standpoint.  Perhaps now I can get them interested in deleting/archiving old data.

Did you get that same RFC status message?


Ed Diehl
"Success consists of going from failure to failure without loss of enthusiasm."


________________________________
To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
Subject: Re: Event Raised - WF-BATCH Configured - No Workflow
From: JJOHNSON at uk.ibm.com<mailto:JJOHNSON at uk.ibm.com>
Date: Tue, 10 Sep 2013 18:46:58 +0100

Funnily enough, this exact same issue to my client, happened over the last couple of days.  I did the workflow analysis and passed it over to our BASIS team.  If I get any response back I'll post to the group for information.

Best Regards,
James Johnson

E-mail:JJohnson at uk.ibm.com
Mobile: 07908715224 or 07920870270



From:        Rick Bakker <rbakker at gmail.com<mailto:rbakker at gmail.com>>
To:        "SAP Workflow Users' Group" <sap-wug at mit.edu<mailto:sap-wug at mit.edu>>,
Date:        09/09/2013 23:28
Subject:        Re: Event Raised - WF-BATCH Configured - No Workflow
Sent by:        sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>
________________________________



Hello Ed,

Try OSS Note 1025249 - Entries in transaction SM58 "hang"
"If a large number of deadlines are due at the same time, some of the entries in transaction SM58 may hang. The entries have a workflow destination WORKFLOW_LOCAL_<xxx> (xxx denotes the client) as the target system."

regards
Rick


On Tue, Sep 10, 2013 at 5:44 AM, Edward Diehl <edwarddiehl at hotmail.com<mailto:edwarddiehl at hotmail.com>> wrote:
We're on SAPKB70107 - ECC 6.0

We did a client copy from production to the test system.  WF-BATCH was configured after some test data did not produce workflows.  After that we STILL are not getting workflows.  The Events go into the queue, as designed.  When released the events show green, but at the bottom of the event display under RFC status:
"System overloaded, repeat immediately by batch"

Okay, so a couple of questions:
Has anyone out there seen this before?
What does system overloaded mean?
And what batch process/program is it talking about?

Any feedback would be appreciated.

Thanks,
Ed Diehl



Ed Diehl
"Success consists of going from failure to failure without loss of enthusiasm."


_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_______________________________________________ SAP-WUG mailing list SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20130913/24fa6f7d/attachment-0001.htm


More information about the SAP-WUG mailing list