Poor background steps performance

[Mike Pokraka]

Hello George,

Bit of a late reply, but in case you're still facing this issue, here goes:

This delay has nothing to do with the Workflow system itself. As you
already observed, once execution starts, it's pretty quick. It is doing
exactly what it is supposed to. When it creates the tRFC, it says to the
SAP system "Please execute this FM with these parameters". If resources
are available, SAP will do it. Else it goes into it's internal queue and
gets processed whenever it has time.(This incidentally is one of the
reasons why one should never rely on things happening in a certain time or
even sequence).

Enough resources assigned is meaningless without knowing what was going on
in the system at that particular time. You could look at the job log for
some clues. If a large batch of <whaterver> happens at the time your
workflow wants to do it's thing, there may be contention for 15 minutes
and then the system is fine again.

In other words, this looks perfectly normal from a workflow perspective.

Regarding event queue, it's main function is to spread peak loads. It's
only really relevant if you have more workflows than the system can handle
(e.g. if you have a process kicking off 100+ workflows). The event queue
stores them and the job will start n of them every time it runs, thus
spreading sudden spikes. If your processes are manual or not subject to
spikes then they do not need to be in the queue.
A secondary function of the event queue is to be able to channel all the
workflow starts to a specific server group if it is so configured. You can
check this out for yourself in SWEQADM, there is some good doco in the
transaction and the F1 help.

Hope that helps,
Mike


On Thu, March 5, 2015 9:47 am, george_caramaliu at yahoo.com wrote:
> Hello everyone,
> I need an advice because I am out of options.I have a complex workflow
where from time to time some background steps are executed by the system
with delay. There is no delay coded inside or set up on the step, as
long
> as it happens only when the system is overloaded.The problem is that the
workflow is creating the background step successfully, in the technical
log I see the messages "Background work item created" and "Background
processing started" immediately after the previous step was completed,
but
> the next entry in the log for the background step with "Execution
started"
> is created with 5 to 60 minutes delay, varying randomly (as attached).
Once the execution is started the step is completed very fast, so it is
not a problem of the code inside.
> The basis consultants checked and it seems that the system has enough
TRFC
> resources assigned in SMQS and recommended to change the settings in
SWEQADM regarding event queue administration, more specific the
parameters
> (no of events per read access) for background job execution for event
delivery.In my system I have the event queue enabled for 9 events and in
this specific workflow one of this queue enabled event is used, but I
cannot imagine how the background job execution for event delivery could
influence the processing of a background task that is already created
but
> not processed by TRFC.
> Any suggestion is welcomed, I am considering also to remove the event
from
> the event queue, as I never had any issues with non queued events, or to
increase further the no of events per read access. By the way, does
anyone knows what exactly this background job for event queue processing
does? It is executed each 2 minutes for a predefined no of events but in
the test system the events are triggered and processed immediately, I
expected that the events would be processed only by this job, but is
seems
> it is not the case.
>
> Thank you,George CaramaliuSAP Workflow/ABAP consultant 
> Â Â _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>