correlations using BP address

Wed Mar 3 01:07:29 EST 2010

Florin,

Those are fantastic hints. Thanks very much for sharing that with us. I
especially like the idea of raising a 'ChangeCompleted' event.

I have gone with the Event Queue for now. It seems to work fine. I am using
it to space out the delivery of events to 1 every minute
(for my specific event linkage only). No extra coding required!

It is a shame that we have to go to such lengths to compensate for delays
in updates; but I don't know what SAP can do about them.

cheers
Paul

             "Florin Wach"                                                 
             <florin.wach at gmx.                                             
             net>                                                       To 
             Sent by:                  "SAP Workflow Users' Group"         
             sap-wug-bounces at m         <sap-wug at mit.edu>                   
             it.edu                                                     cc 

                                                                   Subject 
             02/03/2010 05:11          Re: correlations using BP address   
             PM                                                            

             Please respond to                                             
               "SAP Workflow                                               
               Users' Group"                                               
             <sap-wug at mit.edu>                                             

Good Morning, Paul,

I'm not familiar to correlation at all, but I still would like to comment
on some tricky event-commit-timing-problems:

1) The check function module

The check function module will most probably not help you very much, as the
check-FM is likely to be processed BEFORE or DURING the commit statement
(which depends on the programming of the transaction block). I was never
succesfull in a stable solution using the WAIT statement, at all. Within
the UPDATE TASK it will just extend the processing time, until the rest is
posted (which you're waiting for). So sometimes there's no parallelism
taking place within the check-FM

2) The receiver function module

Another case is the processing time of the receivery function module, which
is USUALLY being processed after the V1 commit on a secondary parallel RFC
dialog process. The V1 update data should be available at that time. So
what I do in such cases is to put the coding of the CHECK function module
into the coding of a receiver function module (having mostly the similar
interface), and call the original (SAP) receiver function module
afterwards, if the check was passed.

3) De-coupling/Re-Sending of the events

To avoid complex coding within 2) you can choose to create a second event
(e.g. ChangeCompleted) from a receiver function module and continue with a
normal event linkage with THAT event. In the check-FM there, a WAIT step
would help.
I was really in a situation, where both techniques didn't help and the
resend was slightly too fast, so I did enhance the event with a new
event-container element "COUNT" and populated that through the check-FM,
adding 1 each time, while the check-FM looked at the database for
existence. If not succesful, it would raise another event again, counting
upwards. To avoid endless loops I stopped at five.

4) Nowadays

Having the new enhancement features with ECC 6.00 (e.g. creating an
implicit enhancement point 'at the end/beginning' of (any) a function
module), I would create my own event-coding at a time, where the entries
are finalized on the database. This is much more safe than 2) or 3) and
none of the solution is release-safe anyways.

May these hints be of help.

With the very best wishes,
Florin

-------- Original-Nachricht --------
> Datum: Tue, 2 Mar 2010 14:17:33 +1000
> Von: Paul.Bakker at osr.treasury.qld.gov.au
> An: SAP-WUG at mit.edu
> Betreff: correlations using BP address

>
> Hi,
>
> Sorry for the long post..
> I am using workflow correlations to react to a  (BusinessPartner)
> BUS1006.CREATED event.
>
> My correlation is based on the name and address of the business partner
> (for example ' Joe Blow / 21 Jump St').
> This works beautifully when I test it via SWUE, but NOT when a BP is
> created for real. The correlation is NEVER made.
>
> My theory is that the address record for the BP is not  fully committed
> when the BUS1006.CREATED event is raised...
> (Which makes correlations a little hard to use!).
>
> So the obvious solution is to put a delay in, to ensure that the event is
> not delivered until the address record is created.
>
> I tried delaying the delivery of the event by piping it through the event
> queue, and delivering one per minute.
> This worked (hooray!), but I vaguely remember hearing negative comments
> about using the event queue to delay event delivery.
>
> Another option I considered is to put a 'check function' on the event
> linkage with the correlation manager, that simply has a 'wait for n
> seconds' ABAP command inside it.
>
> Can anyone provide advice on this? Has anyone faced a similar problem?
>
> cheers
> Paul B
>
> PS thanks to the guy who explained workflow correlations in a recent WUG
> post, and recommended oss note (1335009)
> I owe you a beer!
>
>
>
******************************************************************************************************************************************************

>
> Only an individual or entity who is intended to be a recipient of this
> e-mail may access or use the information contained in this e-mail or any
of
> its attachments.  Opinions contained in this e-mail or any of its
attachments
> do not necessarily reflect the opinions of Queensland Treasury.
>
> The contents of this e-mail and any attachments are confidential and may
> be legally privileged and the subject of copyright.  If you have received
> this e-mail in error, please notify Queensland Treasury immediately and
erase
> all copies of the e-mail and the attachments.  Queensland Treasury uses
> virus scanning software.  However, it is not liable for viruses present
in
> this e-mail or in any attachment.
>
>
******************************************************************************************************************************************************

>
> _______________________________________________
> 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