Timing Issue

I wish to share a common incident in custom SAP code regarding what is colloquially called a 'Timing Issue'. This is a programming error that results in a clash when calls to functions or BAPI's results in an independent asynchronous background update process.

The phenomenon is well-known, but this issue spans concepts of units of work,locking and process handling. It is surprising but even standard code contains conflicts on these issues.

In any other language - like java - these would be fairly separated into a session synchronization issue and a database update issue. Within an integrated SAP environment, ABAP coding is typically done in tightly integrated code which handles db updates, locking contention and session handling. SAP has several constructs dealing with all of these items.

Here's a quick overview :
DB Updates : SAP LUW mechanism allow several updates to be processed together or not at all (commit work/rollback).
Locking : SAP locking mechanism allows to check whether an update is contentious and/or wait until previous updates are finished (ENQUEUE / DEQUEUE functions).
Session Handling : SAP allows a single stream of code to raise and handle several processes (these are SAP Basis processes - as opposed to processes in windows or unix) the most common of which are :

• call function ... [starting new/ in background/in update] task
• submit ... via job... : allows submission of a report via background job
• perform... on commit : does not create a new process but allows delay of bundled processing to the end of the current LUW ie next commit.

This are well documented in SAP's help functions regarding "Programming Database Updates" .

In Practice

BAPI's are used by SAP programmers to enable updates on the database. Direct Updates (using SQL commands) are almost always never used except in custom dialog transactions.

BAPI's have been well-documented during the last couple of years. They still leave something to be desired - but they are typically usable. But it does not help that Standard BAPI's are developed by different SAP groups and don't have standardization as to handling of locks, updates, call types, commits etc.

lets consider a code :
call function 'BAPI_DOCUMENT_CREATE'. " creates a document
call function 'BAPI_DOCUMENT_PROCESS'. " processes document


The internal call type of the BAPI_DOCUMENT_CREATE will determine whether the call to BAPI_DOCUMENT_PROCESS will be successful.

For example : If a lock is held exclusively by BAPI_DOCUMENT_CREATE until the end of the transaction - then BAPI_DOCUMENT_PROCESS could fail if it uses a background job submit.


Parting Comment
When dealing with bundled update requirements, interfacing or dialog construction it would be most handy if the programmer pays a little bit more attention with the SAP constructs on locking, updates and process handling.

... I'll talk about some scenarios in the future. Until then, good coding and ethical consulting to all of you.