Check FM issues 4.6c

[Gavin Mooney]

Rick,

How about using the event queue and configuring one of the two events
to go into the queue? That way your CFM for the queued event will find
the WF triggered for the non-queued event (if there is one). Much the
same as the delay step, but maybe a bit neater.

Regards,
Gavin

2008/1/11, Sample, Rick <Rick.Sample at gbe.com>:
> I am "sure" (functionally) it is not setup in a standard way!
>
> Yes. In my CFM I have a CASE for RELEASESTEPCREATED and CHANGED. Check
> if started, etc.
> The problem is, both events trigger at exact same time and
> when both run, they both come back with no wrkflw started. (see CFM
> code)
>
> EXIT after RAISE, yep! I know (blush).
> I removed it as soon as I e-mailed. Had it there to exit loop and do
> something else before raise workflow_off. (good eye though! lol)
>
> We have changed the design and I no longer need to trap for this CHANGED
> event and
> start wf. Nothing to do with this issue, but the design has changed.
>
> I am still going to work on this issue. More than likely, like you said,
>
> something not setup correctly and raising two events due to the way it
> is functionally configed. (Not my area)
> But, you do understand why two events are getting raised.
>
> After PO create, the RELEASESTEPCREATED is not triggered unless the
> release strategy has changed.
> The CHANGED event will trigger on any change.
>
> I need to find where these events get raised. If you know, please
> forward to me.
> (But this issue has to go on back burner for now)
>
> Thanks for the help Ravi!
> Rick
>
>
>
>
>
> ________________________________
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Ravi Dixit
> Sent: Thursday, January 10, 2008 4:44 PM
> To: sap-wug at mit.edu
> Subject: RE: Check FM issues 4.6c
>
>
> Hi Rick
>
> Try this out in your check FM, if the event is CHANGED then check if any
> workflows have been triggered, if yes then raise exception, this will
> prevent the workflow from triggering for CHANGED. When the event is
> RELEASESTEPCREATED, again check if there is another workflow, if there
> is KILL it or may be raise an exception as a workflow is already in
> process otherwise do not raise an exception and the workflow for
> RELEASESTEPCREATED would trigger.
> Normally, if you have defined your Rel Strategy correctly this situation
> wouldn't happen, a RELEASESTEPCREATED event would be triggered for all
> POs, so check that, may be with a functional guy.
> Finally, you have an EXIT after RAISE, which is unnecessary as it would
> never be called after the RAISE.
>
> Best Regards
> Ravi Dixit
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>