Have you ever encountered issues with enqueue locks or drafts that were not removed automatically?
We recently faced exactly this situation in one of our systems and were finally able to identify the root cause and resolve the issue.
Background
Draft data is persisted in the draft tables of the respective entities. The table names are defined in the BDEF of the draft-enabled Business Object.
In addition, administrative information is stored in I_DraftAdministrativeData.
Drafts do not use normal locks. Instead, they rely on enqueue locks. These were specifically introduced to maintain draft locks even when the original ABAP session no longer exists between two roundtrips (stateful application behavior on top of a stateless protocol).
RAP Draft Lifecycle
RAP uses two background mechanisms to manage the draft lifecycle:
Lock Expiration (15 minutes)
In SAP GUI, a session timeout would terminate the ABAP session. As a result, both unsaved changes and the associated locks would be lost.
For Fiori applications, this behavior has been improved through the draft concept. After 15 minutes, draft locks expire and are removed, while the draft data itself remains available. The user can resume working on the draft later if required.
In this situation, other users can continue working on the same object and may overwrite the draft changes (with an appropriate warning, of course).
Draft Cleanup (28 days)
Draft instances are deleted 28 days after the last modification.
Once a draft has been deleted by the cleanup process, the pending changes can no longer be resumed.
Technical Details
Lock expiration is handled by an AutoABAP job that runs every five minutes. The job can be found in transaction ST03N.
It calls the method CL_DRAFT_LIFECYCLE_MANAGER=>RUN, which eventually executes the branch responsible for EXPIRY_LOCKS.
In addition, there is a technical background job that executes report RSDRAFT_LIFECYCLE_MANAGER (see SJOBREPO).
This report also calls the same lifecycle manager. However, it executes the first part of the logic within the IF statement, which is responsible for draft cleanup.
Root Cause in Our Case
In our system, the AutoABAP job was running every five minutes as expected. However, a global lock had existed for more than three weeks: SDSP_DLH_LOCK_EXPIRY.
The lock had been set in client 000 and was never released.
As a result, the lock expiration job was effectively blocked and had no effect at all during that period.
To make matters worse, the draft cleanup report was terminating with a short dump every morning at 4:00 AM, exactly when the technical cleanup job was scheduled to run.
The root cause turned out to be an issue related to a Purchase Order attachment. An error message ultimately resulted in a RAISE SHORTDUMP statement being triggered. After bypassing the affected record in the debugger, the cleanup completed successfully and the draft was deleted.
Conclusion
If you notice that draft locks are not expiring or drafts are not being deleted after the retention period, it may be worth checking the following:
- Global locks such as SDSP_DLH_LOCK_EXPIRY
- Dumps in ST22 during the runtime of the technical job executing RSDRAFT_LIFECYCLE_MANAGER
- Debugging CL_DRAFT_LIFECYCLE_MANAGER=>RUN
Hopefully this helps someone facing a similar issue.
