Announcement:
wanna exchange links? contact me at sapchatroom@gmail.com.
Posted by
Admin at
Reply from Pierre_Richer on Mar 15 at 1:39 PM Hi Robert,
Did you encapsulate the BAPI within an RFC? I did it using STARTING NEW
TASK and it works.
For locking mechanism, you can create your own using a kind unique process
ID for that LUW representing batches.
You have to find a way to identify the Batches as a unique process id and
use it with your own locking mechanism. If the user try to modify this
batches the relevant process id is locked, unlock at the end when released.
During that time, the other RFC process Tries to lock the Batches to
perform his updates. As soon as there a free window, Lock perform updates
Unlock. Worst case, the user will have message if he tries to modify
during RFC updates.
Or park all the updates in a Z table and run a batch job during night, as
long as the updates won't overwrite what the user has done during the day.
Maybe I'm not clear enough.
Pierre,
| | | ---------------Original Message---------------
From: Robert Seehafer
Sent: Friday, March 15, 2013 1:13 PM
Subject: Asynchronous Update of Objects (Batches)
Hi Pierre,
Unfortunately I cannot set the locks myself as I am calling a BAPI which is already doing the lock.
Now I try to call the BAPI via background task because I hoped to see it in SM58 if it fails.
But in background task nothing happened. The BAPI seems not to be executed at all.
Robert |
| Reply to this email to post your response. __.____._ |   _.____.__ |
