Check FM issues 4.6c

[Gavin Mooney]

Really? Were both events still processed at the same time? You tried
it with one event in the queue and the other one not going into the
queue, right?

2008/1/11, Sample, Rick <Rick.Sample at gbe.com>:
> Tried it with / without event queue. No soap!
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Gavin Mooney
> Sent: Friday, January 11, 2008 10:03 AM
> To: SAP Workflow Users' Group
> Subject: Re: Check FM issues 4.6c
>
> 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
> >
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>