Determine if another event was simultaneously raised for same object?

Thu Mar 1 08:37:22 EST 2012

Hi Mike,

Thanks for the suggestion.  I was able to solve the current problem by identifying what conditions trigger 'significantly changed' and handle it in the change document event linkage.  But the technique you suggest looks like it might help with another issue that we have. It's one to tuck away in the toolbox, anyway!

Margaret

-----Original Message-----
From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On Behalf Of Mike Pokraka
Sent: Monday, February 27, 2012 4:59 AM
To: SAP Workflow Users' Group
Subject: RE: Determine if another event was simultaneously raised for same object?

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
>

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug