Wouldnt it be nice...

[Griffiths, Mark]

Instance linkages can also have check function modules/start conditions.  If you use transaction SWEINST you will also see a copy button which could help you create the relevant entries.
 
You will have to do some testing to see what happens to the instance data underlying each linkage (if there are duplicated entries you could still have issues).
 
Regards,
 
Mark
 
SAP UK
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Alon Raskin
Sent: 04 November 2004 11:15
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Wouldnt it be nice...
 
 
Thanks everyone for their input. The only shortfall of this approach is that it only deals with triggering events. I was more interested in Instance events 'Wait for' steps in the workflow...
 
Regards,
 
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 Dart, Jocelyn
Sent: Thu 04/11/2004 09:39
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Wouldnt it be nice...
 
 
 
Or even better than check function modules - just use start conditions to do the same thing.
Far less coding involved.  Remember the start condition is checked at the time the event is raised, i.e.
before triggering the workflow or being added to the event queue.
Jocelyn
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of R Tannert
Sent: Thursday,4 November 2004 5:24 AM
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 = 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 = 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
>function module) where I could programmatically determine whether an
>event is delivered immediately or queued?
>
>
>We have a requirement where if an event is raised by an interface we
>would like it queued but if its raised by a user then we would like
>to deliver it immediately.
>
>Another situation could be that we may want to deliver an event
>immediately if there are no other events for that instance that are
>queued. However, if there are other events for that instance in the
>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