Problems with timing issues - WFs CFM starts before DBcommits

[Rick Sample]

Did you here that "whooshing" sound? That was the sound of the reply
going right over my head.
I need a little help here. I am a newbie newbie. I am thrilled that I
got as far as I have gotten.
(I have on had a couple of SAP classes and not WF. And I have only been
OJT for 6 weeks)
 
Can you point me to some reference to help my understand of the
receiver event as opposed
to the CFM? Preferable from the SAPhelp library. This is the only real
resource that I have
until I get the book "Practical Workflows..."
 
I will be hunting in the SAPhelp files until I can figure out some sort
of intelligent response.
 
Thanks all!
 
Gotta laugh at yourself or it is sure that someone else will!
 
 
>>> tnn at ornl.gov 8/29/2002 2:34:51 PM >>>
Rick,
 
Since you're trying to respond to an SAP-delivered event, one easy
solution is to use your function as a receiver function rather than a
check function.  In the receiver function module you're virtually
assured the database commit will have taken place, so you can perform
your evaluation with confidence.  Then if you want to start the
workflow, your function could either call SAP_WAPI_CREATE_EVENT (or
SWE_EVENT_CREATE) to generate a second triggering event for the
workflow or call SAP_WAPI_START_WORKFLOW (or SWW_WI_START_SIMPLE) to
start the workflow directly.  Some will object that using a receiver
function in place of a check function wastes resources, but if  your
process isn't such a high-volume process, don't worry about it.  I
vote for simplicity and maintainability over performance concerns
every time.  In 4.6C the transaction to link the workflow event to
the receiver function module is SWETYPV.  I've forgotten what it is
in earlier versions.
 
You might also check for a customer exit that enables you to get the
data you need in your check function module.  This is unlikely to be
a fruitful search but is worth a quick look.
 
Rob
 
 
>Nope! But thanks for the attempt.
>
>per Stephan Becker reply,
>>>You can't do the wait, because the CFM runs in the context of the
>caller.
>Confirmed. The wait statement in the CFM is in the same context. It
>just delays the problem.
>
>>>Possible solution: Pass the info you need in the event parameter
>container;
>>>if it's a SAP standard event you're using, you'd need a
modification
>(with
>>>probably the best reasoning for a modification in a long time), or
>you could
>>>ask SAP to make the change for you (don't hold your breath *g), or
>you could
>>>instead raise a custom event in a suitable exit and pass the
>information yourself..
>
>Here is a few more details.
>WF def with type linkage to BO "LIKP Changed" event. Fairly straight
>forward.
>
>I would think that something is happening in the LIKP obj or linked
>obj.
>And, the table update is not completing until the " LIKP Changed"
event
>terminates. ?
>
>Details on how-to "Pass the info you need in the event parameter
>container;"
>I just don't have the experience. Do you have any reference material
to
>review?
>Any examples, links, etc.?
>
>
>
>
>>>>  skeohan at mit.edu 8/29/2002 12:01:22 PM >>>
>Hi Rick,
>
>You could try to put in an ABAP statement
>
>WAIT up to 60 seconds.
>
>That is just one solution.  I am sure our other experts will have
>other
>solutions.
>Sue
>
>Rick Sample wrote:
>
>>  I have a WF with Check Func Mod that starts and completes before
my
>DB
>>  is updated.
>>  My CFM executes a SELECT to examine a field state.
>>
>>  What is the best methodology to delay (set timer?) the CFM to
allow
>the
>>  DB commit.
>>
>>  Please be kind. I am a newbie!
>>  Rick Sample