Event queue configuration

[Michael Pokraka]

Hi,
Nice bit of info Alon.
Just thought I'd throw in some of my ideas on question 1:
 
A very simple indication is the time the RSWEQSRV job takes to run when
fully loaded with more than the 'events per read access' events - just ch=
eck
the job log. Start with the system default 20 and increase by 10. Job
runtimes up to 30 seconds is safe as it should usually run every minute. =
If
you see any longer runtimes you need to consider that a secondary load on
the system may cause it to run longer than 1 minute. What happens then is
that one job overlaps with the next... it does not cope well once it star=
ts
doing that, I've seen duplicate events and many other strange things.
 
The more techo answer: Since events and WF's use up dialog sessions on th=
e
app servers, firing more events than dialog sessions is bad. OTOH, too
little and it takes too long. A good starting point is about 1/2 your
available dialog sessions (the propellerheads in basis will be able to te=
ll
you that). Do mention the time of job as most systems switch configuratio=
n
profiles at night. Slowly increase the number over consecutive runs until
you see performance problems / longer SWEQSRV runtimes.
 
As Alon said - a lot of load testing is the only real indication you'll g=
et.
 
Cheers
Mike
 
Alon Raskin wrote:
> Hi Patrice,
>
> We too are an IS-U site using event queing. Our volumes are also simila=
r.
>
>
> 1. What we found are some issues with the job that is executed to deliv=
er
> the events. We ended writing our own. An example of one of the issues w=
e
> found are:
> a) One event has two receivers. The batch job has no such concept so it=
s
> happy to trigger one of the event receivers but leave the other one for=
 the
> next run. This caused us issues and so we wrote our version of RSWEQSRV
> which ensured that all receivers of a particular event were triggered d=
uring
> the same run.
>
> As for your question, I am afraid we are not aware of any formula. We d=
id a
> lot of load testing and hence determined the optimal amount of events t=
hat
> should be delivered. The answer will vary depending on what your workfl=
ows
> do when they trigger and what size system/db server you have. Best way =
is to
> get some techy nerds (you know the guys with propeller hats) and get th=
em to
> give you the answer.
>
> 2. As I mentioned in point 1, we wrote our own monitoring tool. I wasn'=
t
> involved in the performance analysis so I dont really have access to th=
at
> code but again, I say 'Bring out the Propeller Heads' (think of Bring o=
ut
> the Gymp from Pulp Fiction).
>
> 3. One BIG thing we found is that when we switched on the event queue i=
s
> that some of our workflows stopped working. We saw error like 'INSTLN i=
s not
> a valid object' etc. Turns out that this has happened because people ha=
ve
> been calling SWE_EVENT_CREATE directly rathern then the macro
> swc_event_create. The problem with calling the FM SWE_EVENT_CREATE dire=
ctly
> is that it does not convert the container to persistent mode so that th=
e
> data commited in the table SWEQCONT is wrong (ie. the key is not stored=
 but
> rather a runtime identifier). Then when the event queue job tries to de=
liver
> the event, the container data is determined to be rubbish. Take a look =
at
> the inbox of the WF admin and see if you have any mails that could shed=
 some
> light on your emmacase.created problem.
>
> Alon Raskin
> e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com>
> w: http://www.3i-consulting.com
>
> ________________________________
>
>> From: SAP Workflow on behalf of Patrice Nolin
> Sent: Fri 22/10/2004 13:35
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Event queue configuration
>
>
>
> Hi,
>
> We have 2 problems with the event queue administration:
>
> 1. We are supposed to have batch jobs that will generate between 100000=
 and
> 600000 events (from 5-6 different events) by night depending of the tim=
e of
> the year. Those events will be place in the event queue ("Linkage activ=
ated"
> check box on those events in tx SWETYPV). Is there a formula or way to
> determine the values of the "background job" tab, like "Number of event=
s per
> read access", of the SWEQADM tx?
>
> 2. Can we use a tool to analyse or customise that number? If you use it=
 in
> your company, how did you determine it?
>
> 3. Also, we have a workflow listening to the event emmacase.created. Wh=
en
> it's not sent in the event queue, it's working find and the wf executes
> perfectly. When it's in the event queue, we can see in the log that the
> batch job releases the event, but no WF is start. Anyone has a suggesti=
on
> why or what to do?
>
> Thanks for your help
>
> Pat
>
>