correlations using BP address
Mike Pokraka
wug at workflowconnections.com
Fri Mar 5 04:32:12 EST 2010
Hi Paul,
I don't think there's anything SAP or anyone can do. This is simply a
performance tradeoff. As Florin explained, the V1 update is the one that
determines a transaction as 'complete'. Usually this contains most of the
data we need, and the event mechanism is supposed to guarantee that all
the data is available once the event is published. V1 usually contains
everything that is crucial to the integrity of the database (all key
tables) and data that can be written later is submitted to the database
via a V2 update (usually texts, addresses and the likes) and performed
asynchronously by the database.
This is what SAP have deemed an optimal performance tradeoff, and there
will always be a minority of cases where this is not ideal. Doing
everything synchronously would slow the system down by more than a little
bit.
Cheers,
Mike
On Wed, March 3, 2010 6:07 am, Paul.Bakker at osr.treasury.qld.gov.au wrote:
> 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
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
More information about the SAP-WUG
mailing list