Update: Workitems not completing after receiving terminating event

[Dart, Jocelyn]

Robin,
As explained in the book there are TWO reasons for turning on the event queue: volume handling and error capture. Be careful not to confuse the two!
 
Error capture is to ensure that any event linkages in error are captured  so that they can be redelivered.
Error catpure should *always* be turned on in my view from 4.6C - this is the "Behaviour on Error Feedback" setting in SWEQADM/Basic Data - and in my view should always be "2 Mark linkage as having errors" in a QAS/PRD system, and "3 Don't deactivate linkage" in a DEV system.
 
Volume handling has absolutely nothing to do with error capture.  Volume handling is about slowing down the raising of events to avoid peak loads impacting the rest of the system and that's all. This should only be turned on if you really need it and needs to be set in the individual triggering event linkage.
 
If you are getting messages about system overloaded, it could just mean that there are errors in SM58 and no-one has been resolving them.  So check that out first.   And check your tRFC settings with your system administrators.
 
If you are concerned about the queue order, suggest you put your query into OSS and get an answer/recommendation from the horses mouth.
 
Regards,
Jocelyn
 
 
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Workflow Developer
Sent: Thursday,26 August 2004 10:44 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Update: Workitems not completing after receiving terminating event
 
Greetings,
 
I have managed to find a way around this problem by activating the Event Q (SWEQADM), scheduling the background job and setting the event queue option for the Event Linkage. The workitem now completes, but the downside is the delay in the event linkages while waiting for the next execution of the background job.
 
SAP recommends turning on Event Q only when performance is an issue because of creation of a large number of events in a brief period, e.g., via a batch program.We have never turned on the Event Q in our 4.6c systems and have never had failed linkages, even at peak loads. I cannot figure out why direct event linkage does not work in our 6.2 dev system, which has negligible load. The application is raising two events, with a total of four linkages, two to function module receivers and two to WORKITEM receiver. This should not be sufficient by itself to cause the  "System overloaded" tRFC status. Is there some configuration of  tRFC or other BASIS setting that will increase the tRFC throughput? I would appreciate any suggestions on what might be causing this bottleneck.
 
Besides the delay in event linkages, I  recall reading some posts here, that the events are not guaranteed to be delivered from the Q in the order created. This can lead to illogical cases such as a RELEASED event preceding a CREATED event. Can you confirm if out of sequence delivery can take place and if it is possible to control it?
 
Thanks in advance for your time and expertise.
 
Regards,
 
Robin Sahasranam
 
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
Workflow Developer
Sent: Friday, August 20, 2004 11:32 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Workitems not completing after receiving terminating event
 
 
Greetings,
 
We have upgraded our development system from 4.6c to 6.20 sp41. One of our
custom workflows which has an asyncronous dialog step does not complete even
after the terminating event is received, when executed from the Business
Workplace in R/3. This happens for new workflows instantiated in 6.20 as
well as those created in 4.6c.
 
The dialog task in question executes a Call transaction in the method. When
I execute the transaction asynchronously (directly without executing work
item) the process works flawlessly and the workflow completes normally.
 
The event log (SWEL) shows that the terminating event was received and
the receiver SWW_WI_COMP_EVENT_RECEIVE was started correctly. The
workflow log also shows that the "terminating event received".Yet the
workitem status does not change to "completed and the "stale" workitem
remains in the Inbox. Also, the error correction batch job SWERRE
does not notify the workflow administrator of an error even after the
workitem remains "in process" status for over 24 hours.
 
When executing with ABAB debugger on, I noticed that the Commit Work
command in the called transaction (which creates the terminating event) took
several minutes to execute (usually it completes in 1-2 seconds). During
this time the event log initially shows the following:
 
Action: Receiver started correctly
RFC status: System overloaded, repeat immediately by batch
 
The transaction SM58 shows status "Transaction is executing".
 
After the Commit Work completes, the RFC status message disappears from the
Event Log.
 
We usually have the Event Queue turned off. But I tried testing with the
Event Queue turned on and it made no difference.
 
Thanks in advance for any assistance you can offer.
 
Robin Sahasranam
Workflow Administrator/Developer
World Bank
 
 
---------------------------------
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
 
 
---------------------------------
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.