Wouldnt it be nice...

[Alon Raskin]

Rob/Kevin (and Mark who emailed me directly),
You all came up with the same idea and its great. Thanks.
 
Regards,
 
Alon Raskin
e: araskin at 3i-consulting.com
w: http://www.3i-consulting.com
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of R
Tannert
Sent: 03 November 2004 18:24
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Wouldnt it be nice...
 
Alon,
 
Until your wish for a "queue or not to queue" function for type-linkage
entries comes true, it seems to me that you could handle the situations
you described with check functions.  In each case where you want to call
the same receiver function or trigger the same workflow either via an
event queue or not, create two type-linkage entries in SWETYPV for the
event and receiver, each with a different receiver type, obviously, with
a different, diametrically opposed, check function, and with the "enable
event queue" checkbox checked or not as appropriate.
 
In the case where you want to call a receiver function (a) immediately
if the event is raised by a normal user or (b) with an event queue if
the event is raised by an interface, you could:
 
a. Create a type-linkage entry for the event with receiver type
IMMEDIATE, receiver function Z_WHATEVER, check function
Z_SW_CHECK_NORMAL_USER, "enable event queue" unchecked.  In the check
function determine whether sy-uname fits your criteria for "normal"
users, and raise an exception if not.
 
b. Create a type-linkage entry for the same event with receiver type
QUEUE, receiver function Z_WHATEVER, check function
Z_SW_CHECK_NOT_NORMAL_USER, "enable event queue" checked.  In the check
function determine whether sy-uname fits your criteria for "normal"
users, and raise an exception if so.
 
You're guaranteed that only one of the two event receivers will be
called.
 
If you want to trigger a workflow under the same conditions, you could:
 
a. Create a type-linkage entry for the event with receiver type =3D the
workflow ID and receiver function SWW_WI_CREATE_VIA_EVENT (as usual),
check function Z_SW_CHECK_NORMAL_USER, "enable event queue" unchecked.
 
b. Create a type-linkage entry for the event with receiver type =3D the
workflow ID + "Q" (e.g., WS12345678Q) and receiver function
ZSWW_WI_CREATE_VIA_EVENT, check function Z_SW_CHECK_NOT_NORMAL_USER,
"enable event queue" checked.  In receiver function
ZSWW_WI_CREATE_VIA_EVENT just strip the "Q" from the receiver type and
call SWW_WI_CREATE_VIA_EVENT.
 
This is much less elegant than your proposal (come to think of it, it's
not elegant at all), but it should work for now.
 
Rob
 
>Wouldn't it be nice if we could have an exit (like the Receiver type=20
>function module) where I could programmatically determine whether an=20
>event is delivered immediately or queued?
>
>
>We have a requirement where if an event is raised by an interface we=20
>would like it queued but if its raised by a user then we would like to=20
>deliver it immediately.
>
>Another situation could be that we may want to deliver an event=20
>immediately if there are no other events for that instance that are=20
>queued. However, if there are other events for that instance in the=20
>queue then we would like to queue that event too....
>
>Hope does spring eternal.
>
>Alon Raskin
>e: araskin at 3i-consulting.com <mailto:araskin at 3i-consulting.com>
>w: http://www.3i-consulting.com