Question:
Hi All
I have a problem which I believe is linked to the COMMIT WORK command.
We are using SAP Portal to manage the creation and editing of Notifications in SAP R/3. The user can create a Notification using the Portal which calls a BAPI that then writes the information entered by the user to the SAP R/3 data base. This part works successfully. In the Portal immediately after a Notification has been successfully created the user is given the opportunity to edit it by adding additional items to the Notification from a list displayed in the Portal. This is done by the Portal calling a custom BAPI (Z_BAPI_ADD_ITEM) which in turn calls
BAPI_ALM_NOTIF_DATA_ADD
BAPI_ALM_NOTIF_SAVE
BAPI_TRANSACTION_COMMIT
in this order.
This is where my problem occurs. When a user adds a single item to the Notification form the list on the Portal the custom BAPI runs and executes the 3 standard BAPIs but the item is not written to the Notification on the R/3 database. None of the BAPIs return any error codes in SY-SUBRC or in the RETURN tables and structures and the required data is definitely being passed to the custom BAPI.
Then it gets really interesting. If the user then immediately selects another item from the list in the Portal and clicks on the button to add it to the Notification the custom BAPI executes successfully and the 2nd item is written to the Notification in SAP R/3.
I suspect that this problem has something to do with the COMMIT WORK performed in BAPI_TRANSACTION_COMMIT but I can't prove it as there are no error codes or error messages being returned by the BAPIs. I have tried using ENQUEUE_READ to check database locks before BAPI_ALM_NOTIF_DATA_ADD is called but it did not return any data.
Does anyone out there have any suggestion as to either what may be the cause or what steps I could take to try and track the problem down.
Regards
Bruce B
Answer:
Is the WAIT option set?
_________________
MattG.
Search SAPfans
Answer:
Yes. But the problem persists whether the WAIT option is set or not.
Regards
Bruce B
Answer:
Try calling FM DEQUEUE_ALL after each BAPI_TRANSACTION_COMMIT (also after the creation)
Answer:
I have problems with commitment too
_________________
Kind Regards,
Ron Johns
Answer:
I have tried calling FM DEQUEUE_ALL but it makes no difference. I have also tried using SM12 to check on locks while stepping through the code in Debug mode but it did not report any locks.
Regards
Bruce B
Answer:
I've been in the situation where the update process lags quite a bit behind the actual act of clicking the 'post' button, If you try and read the table immediately after yoiu have processed the post button the data has not been updated.
Break points tend to muddy the waters a bit as they execute an implied commit work, so whilst you're busy looking at something the update happens.
Have you unlocked your records before posting them ?
What happens if you exit the program immediately after the bapi_commit_work call ?
_________________
Regards
R
Abap KC
SFMDR
Answer:
This is done by the Portal calling a custom BAPI (Z_BAPI_ADD_ITEM) which in turn calls
BAPI_ALM_NOTIF_DATA_ADD
BAPI_ALM_NOTIF_SAVE
BAPI_TRANSACTION_COMMIT
in this order.
This is where my problem occurs.
Hi Bruce,
Maybe the problem is coused by asynchronous updates. Try to insert statement SET UPDATE TASK LOCAL just before BAPI_ALM_NOTIF_DATA_ADD call.
_________________
Best regards, Sergey Korolev