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