Determine if another event was simultaneously raised for same object?

[Mike Pokraka]

Hi Margaret,

A technique I've used successfully is to 'forward' events by using a
custom event handler to republish a new event.

I first came across the idea from Jocelyn as a method to translate BOR
events into OO events, but it has a number of uses and may work for you.
I've used it a few times to rejig the meaning of 'SIGNIFICANTLYCHANGED'
from SAP's definition to the customer's logic.
For example, for BUS2105.SIGNIFICANTLYCHANGED you can code a receiver
ZCL_PURCH_REQ->ON_EVENT that raises events ZCL_PURCH_REQ->VALUECHANGED or
QTYCHANGED as applicable. To create the receiver, either implement
interface BI_EVENT_HANDLER_STATIC on a class and put your code into the
ON_EVENT method, or use a FM copied from one of the other handlers.

Not suitable for high-volume events as it does double up on the number of
events the system processes, but for something like a PO approval it works
very well.

Regards,
Mike



On Tue, February 21, 2012 2:30 pm, Hilsbos, Margaret A wrote:
> Rick and Jocelyn,
>
> Thanks for your inputs. That's pretty much what I was thinking, but I
> wasn't sure.
>
> Rick, I agree with not looking at the event table, and I like your
> suggestion. In any case, as both of you pointed out, the potential timing
> issue would have to be handled.
>
> Meanwhile, by further investigation, I found that there is indeed a way
> I'll be able to determine from the change document whether the other event
>  should  have been raised (not as good as knowing if it really was raised,
> but hopefully that's not a major distinction!) - either or both of release
> status and release strategy will have changed  - if neither of those
> changed then the new workflow will do A & B; if one or both of those
> changed it will only do A.
>
> Thanks again. I can always count on this group to clear my brain fog on a
> question.
>
> Margaret
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Dart, Jocelyn
> Sent: Tuesday, February 21, 2012 5:24 AM
> To: SAP Workflow Users' Group
> Subject: Re: Determine if another event was simultaneously raised for same
> object?
>
> Hi, Also just remember you can't guarantee event order. Nothing wrong with
> your current approach IMHO. Jocelyn
>
> Sent from my iPhone with many apologies for the spelling, grammar and any
> other deficiencies
>
> On 21/02/2012, at 6:49 PM, "Rick Bakker"
> <rbakker at gmail.com<mailto:rbakker at gmail.com>> wrote:
>
>> Hello,
>>
>> If I understand correctly, you have events X, Y and Z.
>>
>> You want X to start off a workflow W1 and have it do ActionA, and then
>> also do ActionB but only if Y or Z have not occurred.
>>
>> One way to do this would be to have Y and Z both listed as triggering
>> events for another workflow, W2, which does nothing but start and stop.
>>
>> Then, W1 can test for the presence of W2 to know if Y and/or Z have
>> occurred and whether ActionB then needs to be done.
>>
>> Of course, W1 can only look at the past, not the future, so timing may
>> be an issue. I assume all the events have the same object key.
>>
>> --
>> You could also cheat and look in the event table but that is not
>> recommended - the event trace could be turned off at any time.
>>
>> regards
>> Rick Bakker
>> hanabi technology
>>
>> On Tue, Feb 21, 2012 at 8:42 AM, Hilsbos, Margaret A
>> <Margaret.Hilsbos at dayzim.com<mailto:Margaret.Hilsbos at dayzim.com>>
>> wrote:
>>> Hi workflow experts,
>>>
>>>
>>>
>>> I have an interesting problem that probably has a simple answer, but
>>> it’s not coming to me, so I’m hoping someone can help.
>>>
>>>
>>>
>>> For our custom purchase requisition workflow (BUS2105), we want to
>>> handle a new custom event that is raised when a certain custom field
>>> is changed.  If only our new event is raised, we want it to do two
>>> things – let’s call them ActionA and ActionB.  But, if the
>>> SignificantlyChanged event and/or ReleaseStepCreated is also raised
>>> (according to normal SAP logic and customizing settings), then we
>>> want the result of our custom event to only be ActionA. So, when our
>>> custom event is raised, I think it needs to know what other events
>>> were also raised for the same object and the same save action.
>>>
>>>
>>>
>>> What would be the best way to determine whether other events were
>>> raised?
>>>  Or is there a different way to look at this problem altogether?
>>>
>>>
>>>
>>> Further info:
>>>
>>>
>>>
>>> ·         We’re using change document BANF to raise the custom
>>> event, with
>>> field restrictions limiting it to changes in our custom field. The
>>> custom event is defined on a delegated subtype of BUS2105.
>>>
>>> ·         The existing workflow definition listens for
>>> SignificantlyChanged
>>> and cancels the current workflow, because a new workflow will be
>>> started on ReleaseStepCreated.  I expect to add our custom event here
>>> and/or trigger a separate workflow to handle the additional
>>> processing.
>>>
>>>
>>>
>>> Thanks for any suggestions!
>>>
>>>
>>>
>>> Margaret Hilsbos
>>>
>>> Senior Business Systems Analyst
>>>
>>> Corporate IT, Day & Zimmermann
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SAP-WUG mailing list
>>> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto: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
>