<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr"><span>Thank you Mike for the detailed answer.</span></div><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr">My problem is that I do not know how to solve it, for me it is a basis performance task. What resources should be added in order to avoid such delays in TRFC processing? Dialog work processes, background work processes, database buffer?</div><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr">My only concern is that this delay seems to happen only in this particular workflow, I did not found such delays in background steps for other workflow templates. Could it be related to the fact that the background step has "Advance with dialog" checked and the job is initially started by the dialog user that completed the previous step? I do not know why it was set up like this, I did not developed the workflow.</div><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr"><br></div><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr">Thank you,</div><div id="yui_3_16_0_1_1426498266551_4622" dir="ltr">George</div><br> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;" id="yui_3_16_0_1_1426498266551_4663"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1426498266551_4662"> <div dir="ltr" id="yui_3_16_0_1_1426498266551_4661"> <hr size="1"> <font size="2" face="Arial" id="yui_3_16_0_1_1426498266551_4660"> <b><span style="font-weight:bold;">From:</span></b> Mike Pokraka <wug@workflowconnections.com><br> <b><span style="font-weight: bold;">To:</span></b> SAP Workflow Users' Group <sap-wug@mit.edu> <br> <b><span style="font-weight: bold;">Sent:</span></b> Sunday, March 15, 2015 10:16 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: Poor background steps performance<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1426498266551_4684"><br>Hello George,<br><br>Bit of a late reply, but in case you're still facing this issue, here goes:<br><br>This delay has nothing to do with the Workflow system itself. As you<br>already observed, once execution starts, it's pretty quick. It is doing<br>exactly what it is supposed to. When it creates the tRFC, it says to the<br>SAP system "Please execute this FM with these parameters". If resources<br>are available, SAP will do it. Else it goes into it's internal queue and<br>gets processed whenever it has time.(This incidentally is one of the<br>reasons why one should never rely on things happening in a certain time or<br>even sequence).<br><br>Enough resources assigned is meaningless without knowing what was going on<br>in the system at that particular time. You could look at the job log for<br>some clues. If a large batch of <whaterver> happens at the time your<br>workflow wants to do it's thing, there may be contention for 15 minutes<br>and then the system is fine again.<br><br>In other words, this looks perfectly normal from a workflow perspective.<br><br>Regarding event queue, it's main function is to spread peak loads. It's<br>only really relevant if you have more workflows than the system can handle<br>(e.g. if you have a process kicking off 100+ workflows). The event queue<br>stores them and the job will start n of them every time it runs, thus<br>spreading sudden spikes. If your processes are manual or not subject to<br>spikes then they do not need to be in the queue.<br>A secondary function of the event queue is to be able to channel all the<br>workflow starts to a specific server group if it is so configured. You can<br>check this out for yourself in SWEQADM, there is some good doco in the<br>transaction and the F1 help.<br><br>Hope that helps,<br>Mike<br><br><br>On Thu, March 5, 2015 9:47 am, <a ymailto="mailto:george_caramaliu@yahoo.com" href="mailto:george_caramaliu@yahoo.com">george_caramaliu@yahoo.com</a> wrote:<br>> Hello everyone,<br>> I need an advice because I am out of options.I have a complex workflow<br>where from time to time some background steps are executed by the system<br>with delay. There is no delay coded inside or set up on the step, as<br>long<br>> as it happens only when the system is overloaded.The problem is that the<br>workflow is creating the background step successfully, in the technical<br>log I see the messages "Background work item created" and "Background<br>processing started" immediately after the previous step was completed,<br>but<br>> the next entry in the log for the background step with "Execution<br>started"<br>> is created with 5 to 60 minutes delay, varying randomly (as attached).<br>Once the execution is started the step is completed very fast, so it is<br>not a problem of the code inside.<br>> The basis consultants checked and it seems that the system has enough<br>TRFC<br>> resources assigned in SMQS and recommended to change the settings in<br>SWEQADM regarding event queue administration, more specific the<br>parameters<br>> (no of events per read access) for background job execution for event<br>delivery.In my system I have the event queue enabled for 9 events and in<br>this specific workflow one of this queue enabled event is used, but I<br>cannot imagine how the background job execution for event delivery could<br>influence the processing of a background task that is already created<br>but<br>> not processed by TRFC.<br>> Any suggestion is welcomed, I am considering also to remove the event<br>from<br>> the event queue, as I never had any issues with non queued events, or to<br>increase further the no of events per read access. By the way, does<br>anyone knows what exactly this background job for event queue processing<br>does? It is executed each 2 minutes for a predefined no of events but in<br>the test system the events are triggered and processed immediately, I<br>expected that the events would be processed only by this job, but is<br>seems<br>> it is not the case.<br>><br>> Thank you,George CaramaliuSAP Workflow/ABAP consultant <br>>   _______________________________________________<br>> SAP-WUG mailing list<br>> <a ymailto="mailto:SAP-WUG@mit.edu" href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>><br><br><br><br>_______________________________________________<br>SAP-WUG mailing list<br><a ymailto="mailto:SAP-WUG@mit.edu" href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br><br></div> </div> </div> </div></body></html>