correlations using BP address

[Florin Wach]

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