Business processes are not usually handled by one application program – multiple applications are involved that exchange data with each other and that have to access some of the same data. If an application makes changes to an object, there must be a safeguard to prevent a second application from accessing the same object before the changes have been completed. In a logical SAP System, software developers can use the SAP lock concept to do this.
Cross-system processes may require a cross-system and cross-transaction lock, which the SAP lock concept has not covered until now. The Cross-System Lock (CSL) provides a mechanism that makes these locks possible.
You can use the CSL to create cross-system locks for objects. The CSL is contained in the standard SAP software as of SAP Web AS 6.10 but it can also be imported into older Basis Releases (for Basis Release 4.6B, for example). A prerequisite for using the CSL is therefore a corresponding Basis Release that already contains CSL functions.
The CSL is based on the token concept: Application programs that need to access the same data compete for a token that is assigned to this data. The program that owns the token can access the data. Using this lock concept, the CSL can create locks of the following duration:
· A simple cross-system lock, which remains until the end of the Logical Unit of Work (LUW) of the application that requested the lock. The duration of the lock is therefore the same as that of the SAP lock concept.
· A cross-transaction lock, which can cover any number of LUWs in different systems.
Here the CSL is used with function modules of the EnqueueObjects API:
· All calls from an application program to the CSL are local.
· For the core calls of the CSL there are also ‘mass-enabled’ function modules. In this way you can transfer a whole table with lock requests to the CSL, instead of having to call a function module for each table entry.
You can use Customizing to make the following settings:
· Activation or deactivation of the CSL for each logical system
· Standard lock objects have to be mapped onto a cross-component and cross-release lock object type. You can define various mappings in Customizing, and also override the rules about how to determine a mapping at runtime.
There is also a monitor for CSL locks, which can be used to query the status of the lock logic, and to cancel locks that have not been released yet.
The token manager assumes that the tokens are independent. CSL tokens are therefore objects that are moved and locked independently of one another.
Two processes in a scenario for the cross-system flow of goods clarify the use of the CSL: Change Order and Convert Unchecked Deliveries (Udel). In both processes, an order has to be changed. Since the objects order and delivery are dependent on each other and are in different systems, both processes are cross-system and are divided into multiple LUWs (see below).
The standard SAP lock mechanism protects the application object in an SAP instance and within an SAP LUW (dialog and update). In our scenario, however, the duration of the lock covers all subprocesses. It begins in the initial subprocess and ends with the last of the directly or indirectly dependent subprocesses:
These processes require that the order is locked for multiple LUWs. This is not possible with the SAP lock concept alone. The Cross-System Lock (CSL) concept enhances the SAP lock concept and enables a cross-system lock that lasts for multiple transactions.