CROSS SYSTEM LOCK (BC-CST-EQ)

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/3e/5f673b19f27654e10000000a114084/content.htm
Created on January 29, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure.
Subtopics from other structures are not included.
2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior
notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software
vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of SAP AG in Germany and other countries. Please see www.sap.com/corporate-
en/legal/copyright/index.epx#trademark for additional trademark information and notices.
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 20
TABLE OF CONTENT
1 Cross System Lock (BC-CST-EQ)
1.1 Overview and Concepts
1.1.1 The Token Concept
1.1.2 Converting the Token Concept
1.1.3 Points of Contact Between CSL and SAP Locking Concept
1.1.4 Lock Object Types
1.1.5 Duration of a CSL Lock
1.1.5.1 Cross-System Locks
1.1.5.2 Cross-Transaction Locks
1.1.6 Process Flow of a Token Request
1.2 Programming with the CSL
1.2.1 Function Module Overview
1.2.2 Process Flow for Cross-System Locks
1.2.3 Process Flow for Cross-Transaction Locks
1.2.3.1 Application Example
1.3 Customizing Settings
1.3.1 Activating the CSL
1.3.2 Mapping Onto Lock Object Types
1.3.3 RFC Ports
1.3.4 SERM Model of the Customizing Data
1.4 CSL Monitor
1.4.1 Selection Criteria
1.4.2 Results List
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 2 of 20
1 Cross System Lock (BC-CST-EQ)
Purpose
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.
Scope of Functions
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.
Constraints
The token manager assumes that the tokens are independent. CSL tokens are therefore objects that are moved and locked
independently of one another.
Example
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.





PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 3 of 20



1.1 Overview and Concepts
This section gives you an overview of the CSL. The information contained here is aimed at developers, administrators, and consultants. It gives you the basic
knowledge necessary for using the CSL. The following sections contain detailed information about each topic:
Programming with the CSL, Customizing Settings, and Monitoring.




1.1.1 The Token Concept
This section deals with the token concept, which the CSL uses.
Critical Sections
Since processes can run in parallel in different systems or in the same system certain parts of a program must run without affecting another program. These
parts are called critical sections. In a critical section, the program accesses data that can be changed by other programs, too. This can cause problems if a
certain process (a calculation, for example) has not finished. Another example is if multiple systems need to access one system resource (a printer, for example).
Mutual Exclusion with Tokens
The token concept is a distributed solution that guarantees that during a critical section, only one program has access to an object in the memory, a database
table, or a system resource, for example. The idea is simple. For the object (or objects) that can be accessed exclusively only, there is a token. Before a
program can access the object, the object has to be owned by the token. If another program (in another system, for example) owns this token, that program must
wait until the token has been released again.





1.1.2 Converting the Token Concept
Mapping the Token
The
token concept is illustrated by introducing a token: Whoever has the token may edit a corresponding object. To apply this concept, you do not necessarily need
the token itself; you just need to know whether an application has the token.
This is how the CSL proceeds. There is no tangible token but the CSL knows where it is currently located. The CSL saves this information in database tables by
using the token manager. In this way, the CSL can query the status of a token, or determine its current location. The CSL updates the information about the token in
the CSL tables of the systems that are involved in a query.
All the database tables that the CSL uses are cross-client.
Identifying the Token
In the CSL, a key is used to identify a token uniquely. This key consists of three parts:
01. The logical system, which consists of the system name and client (
BCECLNT000, for example) as the physical namespace.
The name of an ABAP Dictionary lock object as a type specification (
EVVBAKE for a request, for example).
This type specification is dependent on the application and the component, which is why it is mapped onto an independent
lock object type by the CSL.
The lock argument or multiple concatenated lock arguments of the ABAP Dictionary lock object to identify a particular instance of the lock object (
4711 to lock a particular request, for example).
The last two parts of the key correspond to the specifications that you make for a DDIC lock object in the SAP lock concept. The CSL does not, however, require
that the DDIC lock objects that are entered in the key actually exist (see also:
The CSL and the SAP Lock Concept).
Token Manager
The CSL is a distributed program for cross-system locks. This means that the token administration cannot be controlled by a central system. Instead, there is a
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 4 of 20
token manager for each logical system:
If an application requests a token that is, a cross-system lock from the CSL, the CSL uses the token manager to determine the status of the token. The
application then either receives notification that it now has the token, or that another application has already requested the token. To see how a token manager
determines the current owner of the token, see
Process Flow of a Token Request.
Master System and RFC
Each token has a master system. This is the logical system that is specified in the key of the token (see above) where the token was generated.
If an application requests a token, the application calls a function module of the CSL in its system. The CSL then uses the token manager to determine where the
token is. The token manager communicates with the master system using an RFC connection if there is no information available locally about the requested token.
The CSL uses information that is available locally to find the token directly. If the token is already available locally, it is not necessary to call the
master system.
A prerequisite for using the CSL is therefore a configured RFC connection between the systems that are involved.
Statuses of the Token
If a token has not been requested, no token manager knows that it exists (that is, the token is not listed in a CSL table). For a calling program, this means that the
token is not available locally (and never was), and is available in the master system. After the token manager has generated a token, the token has one of the
following statuses:
Status Meaning
FREE The token exists in the system and is available. This means that no
application currently owns the token.
H FREE
(locked transiently)
The token is locked by a standard
cross-system (but not cross-transaction) lock. The owner of a token can extend
the duration of a lock to a cross-transaction lock. Otherwise, the application
uses the PSCOPE parameter to determine whether the lock is automatically
released at the end of the dialog or at the end of the update.
REFD The token exists in the system but it is not available and there are no
references to the token. This status applies to
cross-transaction locks only, which use a reference counter mechanism.
MOVD The token has been requested by another logical system and moved there.
The status of a token therefore refers to the state in a particular logical system. This means that a token can have a different status in two different logical systems.
For example, a token can have the status
MOVD in a master system, and in another system that currently has the token, it can have the status REFD.





1.1.3 Points of Contact Between CSL and SAP Locking
Concept
Lock Objects
In both locking concepts, locks are obtained using additional objects:
The SAP locking concept protects database objects using a lock object in the ABAP Dictionary. Competing programs try to access the same lock object
before they make changes to the database object. The programs must actually use the lock object so that they can request locks.
The CSL protects objects using a unique token. For the CSL it does not matter what is protected by the token mechanism. It is also important that all the
programs that want to make changes to an object request a lock from the CSL.
From a technical point of view, DDIC lock objects are not comparable with CSL tokens. The CSL uses tokens (database table entries) to
manage the object locks. The standard lock uses entries in the lock table of the enqueue server (not in the database) to manage the object
locks.
Where locks are referred to in this documentation, these are CSL locks. (To make this clearer, the term CSL lock is used.) Locks of the SAP locking concept are
referred to as a standard lock.
The CSL Locks Dedicated Objects Only
The key of a CSL token contains the name and the (concatenated) lock arguments of an ABAP Dictionary lock object, as well as the logical system. This
suggests at a first glance that the CSL uses this standard lock object for a CSL lock, too. However, this is not the case. The CSL uses the name of the standard
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 5 of 20
lock object including lock arguments for the sole purpose of identifying a token. Therefore, if an application requests a CSL lock, the standard lock is not used.
SAP recommends that you encapsulate the request for a standard lock and the request for a CSL lock in one call (of a function module or a
method, for example).
If you want to lock logically identical objects in multiple systems (replicates, for example), and they are locked locally with different standard
lock objects, you can assign them to one token with a
lock object type of the CSL.
The CSL still uses standard lock objects since parallel processes of a logical system compete for one token. Access to the token table (
CSL_MTLK) is therefore protected by a standard lock so that a maximum of one (sub)process can access a token at once.
Releasing Locks
Locks can be explicitly released using the function modules of the CSL. Since the assignment of a token in the token manager is protected by a standard lock,
CSL locks are released at the end of an update at the latest (implicit DEQUEUE_ALL). The CSL provides a procedure to retain locks for multiple LUWs (see:
Duration of a CSL Lock).




Lock Object Types
A token key contains the logical system, the standard lock object, and the lock argument (or concatenated lock arguments). The last two
parts of the key are used to identify the standard lock object within a system.
Internally, the CSL maps the name of the standard lock object onto a lock object type. Before you can use the CSL, developers must
define the lock object types in the Customizing function. Changes to lock object types in a production system can cause problems if
tokens have already been generated.
Lock object types are cross-release and cross-component, and enable you to assign local objects in different systems with different
standard lock objects to one token.
Using the Lock Object Type
In CRM, requests are replicated from the ERP System into the CRM system. If you want to use the CSL in this scenario to lock the
replicated objects in multiple systems, remember that the request in the CRM system uses a different standard lock object than in the
ERP system, but both objects must be locked if changes are made. This is where the lock object type comes into play. For lock
requests, the CSL uses a lock object type and a defined mapping of the standard lock objects to this type to recognize that it is the
same token that is requested.
The CSL does not support mapping for the logical system or the lock argument of the token. This means that, for this example, the
CRM developers and the ERP developers have to agree on a request number and a logical system for calling the CSL.






1.1.5 Duration of a CSL Lock
The CSL provides two types of lock:
Cross-system lock. This lock terminates at the latest once the LUW of the application program has ended that requested the CSL lock.
Cross-transaction lock. This lock terminates when there are no more references to a token.
The cross-transaction lock is an enhancement of the cross-system lock.




PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 6 of 20
1.1.5.1 Cross-System Locks
The application that requests a CSL is in an SAP LUW that consists of a dialog and an update. When a lock has been requested, the application can decide
when the cross-system lock will automatically be released again. That is why the
CSLEO_ENQUEUE function module has the PSCOPE parameter:
PSCOPE
=1: Implicit release of the token at the end of the dialog
PSCOPE
=2: Implicit release of the token at the end of the update
Locally, standard locks are used for the cross-system locking of a token. Once a token is locked, the status is set to H
FREE (locked transiently) since the system releases the cross-system locks when it releases the standard locks. The locks are released implicitly according to
the value of PSCOPE either at the end of the dialog or at the end of the update.
Since the CSL builds on the standard lock mechanism, the cumulation principle can be adopted directly. Regardless of
PSCOPE, the locks that were requested with CSLEO_ENQUEUE are cumulative. This means that the owner of this type of lock can request a lock more than once if
the first request was successful. See also: Cumulating Locks.
The CSL extends the token concept for locks that need to be kept longer. The CSL uses a reference counter mechanism for this (see also:
Cross-Transaction Locks).
Cross-system locks can be explicitly released by the corresponding owner using the
CSLEO_DEQUEUE module.




1.1.5.2 Cross-Transaction Locks
Stopping Cross-System Locks
Simple cross-system locks always terminate implicitly when the SAP LUW of the application terminates that requested the CSL. A CSL can also be stopped for
multiple LUWs. To do this, the application program in the LUW generates a reference to the cross-system lock (a reference to the token), which is then transferred
to an application program in another LUW. The CSL recognizes at the end of the update that there are still references to the token and rejects all requests from
other applications that do not have a reference.
The LUW where the first CSL is requested is also called an initial LUW. The LUWs that receive the references are also called dependent
LUWs since they are dependent on the initial LUW due to the business process. References are requested using the function module
CSLEO_ADDREF.
A prerequisite for a cross-transaction lock is a lock request by the initial LUW (function module
CSLEO_ENQUEUE) with PSCOPE=2 (standard lock duration until the update).
Using References
When a reference is assigned to a token, the CSL increases the counter for the token by one and sets the status of the token to
REFD. The reference is assigned to the LUW of the application that requested the lock. The CSL recognizes from the counter at the end of the update that there are
still references to the token. If the reference counter is larger than 0, the CSL remains.
That is why the cross-transaction lock is also called a reference counter mechanism.
To reset the counter, the assigned references have to be used. The application that created a reference must transfer it to another application (by RFC or as part of
an IDoc message, for example). First, the application program has to transfer the reference to the CSL in the dependent LUW (
CSLEO_USEREF module). The reference then has authorization to lock the token using the CSLEO_ENQUEUE module. The dependent LUW can then request
additional references, which it can transfer to other LUWs. The concept can be cascaded.
The CSL cannot remember the sequence in which the references were requested. This means that the references can be used in any
sequence by dependent LUWs.




1.1.6 Process Flow of a Token Request
Assigning a Token to a Token Manager
The CSL assigns a token to a token manager so that it can note the current state of a token. How is a token localized if there is no central token manager for the
CSL to contact? Instead of a central token manager, each token has a
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 7 of 20
master system. This is the logical system of the token key where the key is generated by the CSL.
Requesting and Localizing the Token
Before a
critical section, programs request a token (also known as a lock) by calling a local function module (CSLEO_ENQUEUE). The CSL then uses the token manager in
this system to determine whether the token already exists or if it existed previously. That is, whether there is an entry for the token in the token manager table. If
so, the CSL reacts according to the status:
01. If the status is
FREE (assignment is NOT locked by a standard lock), the CSL assigns the token to the application.
If the status is H
FREE (assignment is locked by a standard lock) or REFD, the CSL triggers the FOREIGN_LOCK exception.
If the status is
MOVD, the token has been moved to another system. The CSL then contacts the token manager in the system that is indicated by the status.
If no entry for the requested token exists in this system, the CSL then contacts the master system to determine the status of the token. The master system
determines the CSL from the token key.
There are now two options in the master system:
The token already exists. The CSL then proceeds in the same way as the steps above.
The token does NOT exist. It is generated by the token manager in the master system and is moved to the system that requested the token.
This means that the token can be determined by the entries in the corresponding token manager. If the token is free, the CSL moves it to the system that
requested it; if it is NOT free, the CSL triggers the
FOREIGN_LOCK exception.
If a token manager is unable to find the token in the system that is referenced by the
MOVD status, the CSL triggers the INCONSISTENCY exception because the CSL database tables are inconsistent.
Moving the Token
Once a free token has been found in a system, the CSL locks this token in this system and in the system that requested the token. The CSL uses a standard lock
to do this so that local requests are rejected. The CSL then sets the status in the former system to
MOVD and in the latter system to H FREE. Strictly speaking, a token is not moved, but the information is updated about the current owner of the token in the linked
systems.




1.2 Programming with the CSL
You can use the CSL to realize two elementary application cases:
Cross-System Lock (within an LUW)
Cross-Transaction Lock (possible for multiple LUWs)
The lock objects (the CSL tokens, that is) are independent of each other. This means that there are no interdependencies when locking, referencing, or moving two
tokens. The application cases in this section therefore look at exactly one lock object.
Prerequisites
For both application cases, the CSL must be activated, and every token must be assigned to a lock object type. You can also activate the CSL for certain lock
object types only. The necessary RFC connections must be set up (see also:
Customizing Settings).
You are not allowed to use the CSL in perform-on-commit routines.





1.2.1 Function Module Overview
For more information, see the function module documentation in the system.
CSL Basis Modules
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 8 of 20
Name Use
CSLEO_ENQUEUE Requests a CSL lock or a certain token. If the token is not available locally, the
module performs a synchronous RFC to move the token. The synchronous
RFC can trigger a database commit.
CSLEO_DEQUEUE Releases the standard lock of a token. Even if this module is not called, the
runtime environment releases the standard locks at the end of the dialog or the
update (depending on how long the lock was set for in
CSLEO_ENQUEUE by PSCOPE).
CSLEO_ADDREF Adds a token reference. The reference can be used with
CSLEO_USEREF.
CSLEO_USEREF Uses a token reference that was transferred from another subprocess. After the
call, lock requests to the same token are successful.
For information about using the
CSLEO_ENQEUE and CSLEO_DEQUEUE modules, see also: Cross-System Locks and Process Flow for Cross-System Locks. For information
about using the CSLEO_ADDREF and CSLEO_USEREF modules, see also: Cross-Transaction Locks and Process Flow for Cross-Transaction
Locks.
Modules for Mass Processing
Each of the four basis modules of the CSL has a counterpart that you can use to request, release, or use more than one lock or reference. The names of the
modules consist of the abbreviation
ARR (for array) and the module name of the call: CSLEO_ARR_ENQUEUE, CSLEO_ARR_DEQUEUE, CSLEO_ARR_ADDREF, CSLEO_ARR_USEREF. They are also
called array modules.
The array modules have exactly one parameter the
PPARAMTABLE table parameter and the exceptions of the corresponding basis module. Depending on the basis function, the table has a different row type but
the structure is the same:
The component names of the table fields correspond to the import and export parameters of the basis function but they have
I or E as a prefix so that you can differentiate between them.
Every row type has included a structure for the exceptions of a single call. After the call, the CSL fills these exceptions with the contents of the
SY-SUBRC and SY-MSG* fields (they have the same name with the added prefix SY-). A triggered exception (E) of the array module indicates that at least one of
the corresponding entries in PPARAMTABLE in the SUBRC component contains the value E. If there are multiple calls that have triggered exceptions, the array
module returns the value with the highest priority.
These function modules have to be used for mass locks. The application therefore profits directly from the performance optimization of the
CSL.
Miscellaneous
Name Use
CSLEO_FLUSH_ENQUEUE Sends accumulated lock requests. You accumulate lock requests by setting
the
PCOLLECT import parameter of the CSLEO_ENQUEUE function module. This is
similar to the collect mechanism of standard locks.
CSLEO_CHECK_EFFECTIVENESS Checks the effectiveness of the CSL for a given lock object type.






1.2.2 Process Flow for Cross-System Locks
In this scenario we want to lock an object from system X in LUW A of system Y in all systems. System X is therefore the master system of the corresponding
token. The process flow assumes that the token is not available locally in system Y (this is possible due to previous lock requests).
Prerequisites
The CSL exists in system X.
The CSL is activated in system Y for the lock object type that is assigned to the token.
Process Flow
The application in system Y calls the
CSLEO_ENQUEUE function module during the dialog of LUW A. If the prerequisites are not met, the call has no effect.
If the token is free when the lock is requested, the CSL moves the token from system X to system Y. This move is subject to its own transactional logic (LUWs
A* and A**), which is independent of the application LUW A in system Y.
The graphic below illustrates this process flow. The red arrow shows the duration of the CSL. The CSL begins with the standard locking of the token in system X.
This is required for blocking local lock requests while the token is being moved. The CSL ends with the release of the standard lock of the token in system Y. This
release occurs implicitly at the end of LUW A.
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 9 of 20
When the lock is requested in system Y, the CSL first checks whether the token exists. If it does not, the CSL tries to locate it. In the example, the
token is found in its master system (system X). If the token is not locked there, it is taken (LUW A**) and entered locally (LUW A*).




1.2.3 Process Flow for Cross-Transaction Locks
In this scenario we want to lock a token from system X in LUW A in system Y. This lock has to last until the end of LUW B in system Z. The lock therefore has to
last longer than the technical transaction. The application requests a reference R in LUW A so that the reference counter of the CSL increases. Reference R is
forwarded by the application to another LUW B in system Z and used there. After LUW B has been updated, the runtime environment releases reference R
implicitly.
Prerequisites
The CSL exists in system X.
The CSL is activated in system Y for the lock object type that is assigned to the token.
The CSL exists in system Z.
The function modules
CSLEO_ADDREF and CSLEO_USEREF have no effect if these prerequisites are not met. Compare also the prerequisites for the CSLEO_ENQUEUE function module.
See Process Flow for Cross-System Locks.
Process Flow
The application calls the
CSLEO_ENQUEUE function module during the dialog of LUW A and receives the token. The application can now edit the objects that need to be protected
exclusively.
The application calls the
CSLEO_ADDREF function module (usually after the protected objects have been processed) in the dialog or when LUW A is updated, and receives reference R.
This means that the lock remains after the CSL has been updated.
The application of LUW A transfers reference R in a message to an application in LUW B in system Z.
The application in LUW B in System Z first has to call the
CSLEO_USEREF function module and transfer reference R to the CSL. Lock requests in this LUW with the CSLEO_ENQUEUE call are now successful.
When LUW B is updated, a call is dropped in system Y by using a transactional RFC in the PERFORM-ON-COMMIT routine of the CSL. The lock reference is
released in this way.
The graphic below illustrates this process flow:
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 10 of 20
Cascading the Application Case
After the reference has been used in the dependent LUW B, it can be repeated in the same way. You can execute the
CSLEO_ADDREF function module in LUW A as often as you want, and communicate the added R references in various dependent LUWs B. The LUWs therefore
usually form a tree structure with the initial LUW A as its root.




1.2.3.1 Application Example
An example in the scenario from the cross-system flow of goods shows cross-transaction locks in use. In the following graphic, the function module calls are not
listed. The following syntax is used instead:
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 11 of 20
Call in Graphic Function Module
CslEnqueue(O) Lock request using
CSLEO_ENQUEUE for a token for object O
CslAddRef(O):R A reference for the token for object O is added. The reference R is returned
(function module
CSLEO_ADDREF).
StdEnqueue(O) A standard lock for object O is requested (using the function module that was
generated by the ABAP Dictionary for the standard lock object).
CslUseRef(R) Reference R is used (function module
CSLEO_USEREF).
In the example, an application in a delivery system (on the right-hand side) has to convert unchecked deliveries for a sales order (or for a sales order item), and
therefore requests a lock for the relevant order in LUW A (CslEnqueue()). In this case, the token is free and so the CSL is able to grant it. For the return message to
the order system (on the left-hand side), the application of the delivery system requests reference R1 (CslAddRef()). This ensures that even after LUW A has
finished, additional lock requests are rejected. If there are requests, the CSL triggers the
FOREIGN_LOCK exception for them.
In the example, the application of the delivery system transfers reference R1 to a dependent LUW B asynchronously in an IDoc message to the return message
in the order system. The application in the order system announces reference R1 in LUW B (CslUseRef()), which means that the subsequent CslEnqueue() and
CslAddRef() calls are successful. As a result of the CslUseRef() call, reference R1 is released. The whole process is, however, not yet complete because the
unchecked deliveries have to be updated after the order has been saved.
For this purpose, the application in the order system generates reference R2 and transfers it to a dependent LUW C. In the example, this happens
asynchronously in an IDoc that is sent to where the unchecked deliveries are being processed in the delivery system. This application announces reference R2
in LUW C of the CSL (CslUseRef()). This produces the same result as mentioned above.
Internal Process Flow
The calls of the CSL functions in dependent LUWs are forwarded to the home token manager of the lock. The home token manager of a lock is the same as the one
for the initial LUW of a lock. In the example, it is the token manager of the delivery system. A token is always contained in the home token manager of the last lock.
The lock requests are processed internally in the CSL as follows:
01. LUW A:
01. The lock is requested in this LUW for the first time (CslEnqueue() call with
PSCOPE='2' in the dialog). The corresponding assignment of the token to the token manager is protected and read by the SAP standard enqueue. The token is
free and the lock is granted. (If it is not in the token manager yet, it is moved there.) The standard lock contains a unique ID, is noted internally in the dialog, and
forwarded to the update by using an update module of the CSL. The standard enqueue causes requests from other LUWs to be rejected.
When reference R1 is requested (CslAddRef() call in the dialog or in the update), the CSL checks whether a corresponding lock (with
PSCOPE='2') exists. This is the case so reference R1 is generated with a unique ID, noted internally (if it is in the dialog, then with an update module), and
returned to the caller. The reference counter of the CSL internal lock is increased.
A
COMMIT WORK leads to the execution of the PERFORM-ON-COMMIT routines of the CSL that are registered with the update task. This routine evaluates the
internally noted locks and references. Reference R1 is updated and the token is written to the database (or rather the corresponding assignment of a token
manager to a token). The reference counter now displays 1 and the status is REFD. The ID of the LUW and of the lock, the current user, and the time of the lock
are all set for this lock, too.
The implicit standard dequeue at the end of the update (implicit
DEQUEUE_ALL) resets the standard locks. The token remains locked for the CSL since the reference counter is 0.
LUW B:
01. The application in the order system announces reference R1 (CslUseRef() call with
PSCOPE='2' in the dialog). This is noted as an internal lock (the same as for the initial lock - see step 1a). This results in the subsequent lock request
(CslEnqueue) and then the reference is added (CslAddRef). The CSL uses reference R1 to determine the ID of the initial lock (LUW, NUM).
The application in the order system requests the lock (CslEnqueue() call with
PSCOPE='2' in the dialog). The lock is internally noted as granted by using the CslUseRef() call. The new request therefore only causes the cumulation counter
for each lock to increase (there is a counter for locks with scope 1 and for locks with scope 2). The lock is granted without having to communicate with the home
token manager.
The application in the order system requests reference R2. The process flow is the same as the one described in step 1b for LUW A.
Depending on whether the CSL was activated with reference tracking or not, the following happens during
COMMIT WORK:
If reference tracking is activated, the AddRef():R2 call, which happens asynchronously in the
PERFORM-ON-COMMIT routine in the updater by using a transactional RFC (UP2), and the implicit release of reference R1 are communicated to the home token
manager of the lock and recorded there. In the example, the reference counter does not change; it remains as 1, which means that the lock is retained.
If the reference counter is activated without reference tracking, R1 and R2 are settled internally, and there is no communication with the home token manager of
the lock.
01. LUW C:
01. The application in the delivery system announces reference R2. The process flow is the same as in LUW B.
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 12 of 20
02. The application in the delivery system requests the lock (CslEnqueue() call with scope 2 in the dialog). The process flow is the same as in LUW B the lock
is granted.
03. In the
PERFORM-ON-COMMIT routine in the updater, COMMIT WORK synchronously decreases the reference counter of the token and the release counter of R2, if
reference tracking is activated. This happens in such a way that the release of the reference does not collide with lock requests. The reference counter is then set
as 0. The lock is finished and the token is free again.
Only in the token manager of the master system does the system write synchronously to the database. If LUW C were to occur in another logical
system, the implicit ReleaseRef(R2) would be communicated asynchronously to the token manager of the master system of the lock by using a
transactional RFC (as for LUW B).





1.3 Customizing Settings
You can control the following for the CSL in the Customizing settings:
01.
Activation of the CSL
Mapping onto lock object types
RFC ports
A dedicated tool for Customizing settings does not exist yet. For all the Customizing tables of the CSL there are, however, maintenance views that are generated
by transaction SE54 and that can be processed by transaction SM30. The authorization group for maintenance is SCSL.
See also:
SERM Model of the Customizing Data.
Linked Systems
A term that is often used in connection with the CSL is linked systems. These are the following systems:
Systems in which applications in other systems can perform cross-system locks on objects
Systems in which objects are locked for other systems
Systems that are used for
routing purposes (as determined in the Customizing settings). See: RFC Ports and Routing.
These can be systems that due to the business process do not usually have to communicate with each other.
An order in the order system (A) could contain items that are forwarded to two delivery systems (L1 and L2), for example. The delivery systems have to use the
token (T) to lock the order when the delivery data is processed, but are otherwise unaware of each other. When L2 has the token, and L1 requests the token for the
first time, the CSL in L1 localizes the token in L2 by using system A. If the token is released there, the CSL in L1 retrieves the token directly from L2. Although L1
and L2 do not have to communicate with each other because of the business process, the CSL still has to create a connection between the token managers of
these systems. (If you do not want a direct connection, you can define a
routing.)
Consistency of Distributed Customizing Settings
To use the CSL, it must be available in each linked system. This means that the Customizing settings of the CSL in these systems has to be consistent. The CSL
does not support a central Customizing procedure or a cross-system adjustment of the relevant database tables. You can replicate the tables after the local
Customizing settings have been made:
The database tables
CSL_M, CSL_EOAC and CSL_EOTY must be identical in every system. For this reason, it is best to enter the data in these tables in one system and then to
replicate it in the other systems.
In all the other database tables, the CSL stores only information that is used locally in the corresponding system. Entries with the same key, however, have to
have the same data part in all systems. If this prerequisite is met, you can collect all the table entries in a table in one system after you have made the local
Customizing settings, and distribute the entries to all the linked systems from there.
This second point means that some entries are redundant, but inconsistencies are avoided.





PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 13 of 20
1.3.1 Activating the CSL
When a CSL function module is called, the system checks its activation by using two Customizing tables:
If the lock object type exists in the
CSL_EOAC table, the corresponding entry determines whether the CSL is activated for this lock object type. Entries in the CSL_EOAC table are optional.
If the lock object type does not exist, the CSL looks for the default token manager in the
CSL_M table. If there is an entry there, this determines whether the CSL is activated or not. If there is no entry, this is the same as an entry with an INITIAL
activation. This activation means that the CSL does not exist in the system (see below).
This also means that applications that use the CSL run even when the CSL is deactivated.
Activation Status for each Token Manager (Table CSL_M)
Fields in the Table CSL_M
Field Name Meaning Example
MSY Logical system for token manager (Manager
System)
ELOCLNT002
(System: ELO,
client: 002)
MNU Number of the token manager (Manager Number).
'01' is the default token manager.
01
AC Activation status (see below) NONE
(The CSL is available and deactivated.)

The activation statuses (field
AC) are fixed values for the domains CSL_AC:
Activation Status
Fixed Value Meaning
(INITIAL) The CSL is not available.
NONE The CSL is available and deactivated.
LC The CSL is available and is activated (without
reference tracking).
LCT The CSL is available and is activated (with reference tracking).

If you use the CSL, it must be activated in all the
relevant systems. To do this, you must enter for each logical system a default token manager that has the number 01 (MNU = '01'). Token managers that have
not been entered are treated as token managers that have been entered with the activation status INITIAL.
Activation Status for each Lock Object Type (Table CSL_EOAC)
For a token manager in table
CSL_EOAC, you can optionally enter your own activation for each standard lock object. The table consists of the same fields as the CSL_M table to determine the
token manager, and also contains the EOTYKY field to enter the lock object type.
Function modules of the CSP API enqueue objects have a
PACTIVATION parameter. The default setting for this parameter is SPACE so that the CSL_M and CSL_EOAC tables can be evaluated as described above. If the
value is not SPACE (NONE, LC, or LCT), the module overrides the Customizing settings for activation. This can be useful in special cases.




1.3.2 Mapping Onto Lock Object Types
Creating Lock Object Types (Table CSL_EOTY)
Mapping of standard lock objects onto a
lock object type has to be defined in Customizing by developers during the development phase. To do this, they enter the lock object types in the Customizing
table CSL_EOTY (the Z* namespace is reserved for customers). The entries are part of the delivery and serve as a selection criterion in the monitor.
The entries in table
CSL_EOTY have to be defined during the development phase after a system group has been set up. This means that if tokens exist, it is problematic to change
them.
Example
The following lock object types are available in the system for SAP Web AS 6.10:
Lock Object Type Meaning
SALES_DOCUMENT Order
PURCHASING_DOCUMENT Purchase order
DELIVERY Delivery
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 14 of 20

Creating Mapping Rules (Table CSL_EOME)
You enter the mapping rules in the database table
CSL_EOME:
Mapping rules are also known as mappings.
Fields in the Customizing table CSL_EOME
Field Meaning Example
EOMPKY Name of the mapping
The name must be the same as the component
name that the mapping is valid for. After a
transport, or after the table has been replicated in
other systems, the CSL can then select the correct
mapping using the components that exist in the
system.
SAP_APPL
EOTYKY Lock object type in table
CSL_EOTY
SALES_DOCUMENT
EODDKY Name of standard lock object in ABAP Dictionary EVVBAKE
Example (Continued)
The following standard lock objects are part of the SAP Web AS 6.10 delivery:
Standard Lock Object (ABAP Dictionary) Meaning
EVVBAKE Sales document only (order)
EMEKKOE Purchase document only (purchase order)
EVVBLKE Delivery only
These standard lock objects are mapped onto the following lock object types with the table
CSL_EOME:
EOMPKY (Mapping) EOTKY (Lock Object Type) EODDKY (Standard Lock Object)
SAP_APPL DELIVERY EVVBLKE
SAP_APPL PURCHASING_DOCUMENT EMEKKOE
SAP_APPL SALES_DOCUMENT EVVBAKE
SAP_DEFAULT DELIVERY EVVBLKE
SAP_DEFAULT PURCHASING_DOCUMENT EMEKKOE
SAP_DEFAULT SALES_DOCUMENT EVVBAKE

There are therefore two mapping rules for the lock object types:
SAP_APPL and SAP_DEFAULT.
Selecting the Mapping Rule
If there is more than one mapping rule, the CSL has to select one at runtime. There are two ways of configuring Customizing to determine the selection:
To explicitly assign a mapping to a token manager, you can make an entry in the Customizing table
CSL_MEOM.
It makes sense to give the mapping the same name as the name of the corresponding component. You can enter the relevant components in the table
CSL_EOMP and assign them a lookup of 1-N. The CSL uses this lookup to check in the logical system whether the component exists in the CVERS database table
(that is, whether the component exists in the system). The CSL selects the first mapping in the set order for this component.
The component names are determined by SAP. The development groups of a cross-component scenario must be in agreement on the components
and lookups so that the CSL can select the correct mapping in each system.
The CSL selects a mapping according to these table entries:
01. In function module calls of the CSL, the name of a standard lock object is always contained in the token key. The CSL gets all the mappings that are defined
for this object from the
CSL_EOME Customizing table.
Then the CSL uses the
CSL_MEOM table to check whether a mapping was explicitly assigned to the token manager in the function module call. If so, then this mapping is used.
If no mapping can be determined with this method, the CSL looks at the entries in the
CSL_EOMP table (components and lookup) according to the lookup 1-n. The first mapping that is also found in the table of the CVERS software components
because it has the same name is selected.
If the CSL cannot determine a mapping rule with this method, the
SAP_DEFAULT mapping is activated. The lookup for this mapping is 0 so that the CSL can recognize that it is not a component. The CSL therefore does not need
to check whether SAP_DEFAULT is entered in the CVERS.





PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 15 of 20
1.3.3 RFC Ports
The CSL tokens are moved if necessary when
CSLEO_ENQUEUE is called. For this reason, the token managers in the linked systems have to communicate with each other by using an RFC. There are two
database tables for setting up the communication channels between the systems:
CSL_CCP
(CCP = Communication Channel Physical) to set up additional RFC ports for the CSL, besides the ones that are entered in the system
CSL_CCL
: (CCL = Communication Channel Logic) to set up routing through other systems
As far as the CSL is concerned, a physical communication partner is a direct communication partner that can be reached by a point-to-point connection. A logical
communication partner, on the other hand, can also be reached by third-party systems.
Determining the RFC Port
For a Remote Function Call (RFC or tRFC) from a sender token manager S = {SY
S
, NU
S
} to a recipient token manager R = {SY
R
, NU
R
}, the CSL proceeds as
follows:
01. We assume that a direct RFC connection S R is possible.
02. The CSL first checks whether an RFC port for the logical system SY
R
has been entered in the
CSL_CCP database table. If so, the CSL uses this port.
If no RFC port for system SY
R
was entered in the
CSL_CCP table, the CSL uses the RFC port that was entered in the TBLSYSDEST database table.
If there is no entry for SY
R
, it is assumed that the name of the RFC port is the same as the name of the logical system (
BAPCLNT001, for example).
The entries in the
CSL_CCP table therefore override the general RFC settings for any communication between the token manager and other systems. This table contains the
following fields:
Field Name Meaning Example
CIRSY Logical system of the token manager where the
communication starts (Communication Indicator
System)
RAMCLNT004
CIRNU Number of the token manager from
CIRSY
01
CPPSY Physical communication partner of the token
manager that is specified by
CIRSY and CIRNU (Communication Partner
Physical)
ROMCLNT001
CPPNU Number of the token manager from
CPPSY
01
PO RFC inbox (target port) of the token manager that is
specified by
CPPSY and CPPNU This port must be entered in the
RFCDES table in the outbound system. This table
can be processed in transaction SM59 only (see:
Maintaining Remote Destinations).
ROM_PORT

Routing
Since an RFC connection between two systems is not always needed, we cannot assume that an RFC connection is set up between all linked systems. You can
define a routing that is connected by an RFC to the other two systems by using a third-party system.
The routing is not described centrally. Instead, you specify for each token manager which is the nearest physical communication partner for reaching the logical
communication partner. A row in the
CSL_CCL database table contains such a reference:
Field Name Meaning Example
CIRSY Logical system of the token manager where the
communication starts (Communication Indicator
System)
FROCLNT000
CIRNU Number of the token manager from
CIRSY
01
CPPSY Physical communication partner of the token
manager that is specified by
CIRSY and CIRNU. This is a token manager that
the CSL can use to reach the logical
communication partner
NXTCLNT002
CPPNU Number of the token manager from
CPPSY
01
CPLSY Logical communication partner the token manager
that has to be reached at the end
FARCLNT001
CPLNU Number of the token manager from
CPPSY
01
LEM Specifies the number of systems that can be used
to reach the logical communication partner, minus
1. This is a typical routing parameter for selecting
the shortest possible route.
2
The routing that is defined by a row in the
CSL_CCL table is one-way.
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 16 of 20
Example
There is no RFC connection between systems ABC and XYZ. As shown below, you can use the entries in the
CSL_CCL table to define a routing using systems DEF and GHI.
To simplify the graphic, we have abbreviated the field names and omitted the numbers of the token managers.
If the token manager in the
ABCCLNT000 system wants to communicate with the token manager in the XYZCLNT000 system, the CSL looks in the table for the corresponding entry with the
correct outbound system (CIRSY field) and the correct logical target system (CPLSY field). The CSL uses the nearest physical communication partner (entry in the
CPPSY field) to track the route to the target system. In this case, the LEM field would have the value 3 in the ABC system, 2 in the DEF system, and 1 in the XYZ
system.
The CSL must be activated in all the linked systems for the routing to work.




1.3.4 SERM Model of the Customizing Data
The Customizing data model is stored in the system as an SERM model (transaction SD11, data model
CSL_0001). Additional data models for the CSL have CSL_ as a prefix.
The meaning of the graphical SERM presentation is described under
Graphic: Presentation Method (SAP-SERM).
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 17 of 20





1.4 CSL Monitor
Use
You can use the CSL monitor to do the following:
Monitor the status of the tokens in the token manager of the local logical system and in remote logical systems
Determine the location of tokens that have been moved
Release any administrative locks that a subprocess could not release (if there was a system crash, for example)
Prerequisites
To execute the CSL monitor, you need the same authorization as for executing transaction
SM12 (object: S_ENQUE, ID: S_ENQ_ACT). To query remote token managers, the RFC connection has to be set up between these two systems (see also: RFC
Ports and Routing).
Activities
Start the monitor by calling transaction SMCL or by using the
CSL_MON report.
Maintain the
selection criteria on the initial screen of the monitor.
Check the
results list of the monitor.
PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 18 of 20




1.4.1 Selection Criteria
Use
On the initial screen of transaction SMCL, you can limit your query to one token manager and limit the results list to a certain number of tokens. You can also
display an overview of the actions that are performed in the CSL monitor (release by an administrator, for example) instead of an overview of the tokens in the
token manager.
Prerequisites
To execute the CSL monitor, you need the same authorization as for executing transaction
SM12 (object: S_ENQUE, ID: S_ENQ_ACT).
Scope of Functions
Destination
Selection Text Meaning
Remote token manager system You use these fields to determine which token manager you want to query with
the monitor. The default setting is the token manager of the logical system
where you started the monitor. You can, however, choose to query a remote
token manager.
Remote token manager number
The selection of the destination applies to the List Tokens function and the List Application Logs function. To set the function, choose the
corresponding selection.
Token Selection Criteria
Selection Text Meaning
Token Home System These fields identify one or more tokens:
Token Home System
specifies the logical system, and instance ID specifies the lock
arguments from the token key.
The
object type is the lock object type that the standard lock object from the
key was mapped onto.
Object type
Instance ID
Token Status Limits selection by using the token properties
Token Locked by User
Date Limits the selection to the last date and time that the token was accessed (in
the
results list, this is specified under LAST-TIME-ACCESS).
Time
Application Log Selection Criteria
Selection Text Meaning
Date Limits the selection to the time when the action was performed
Time
Token-ID Limits selection to one token whose reference is requested by
CSLEO_ADDREF
ALog written by user Limits selection to one user
List Settings
Selection Text Meaning
Number of displayed entries Limits selection to the first N entries found This field applies to the List Tokens
function and the List Application Logs function.
Activities
Select a destination.
An
RFC connection must be set up for the specified destination. You may have to log on to a remote system.
Choose List Tokens or List Application Logs.
Maintain the selection criteria that belong to the function and call up the
results list by using F8.




PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 19 of 20
1.4.2 Results List
Use
The results list displays the token (List Token function) or logged actions (List Application Log function). You can release locked tokens or determine into which
logical system a previous token was moved.
Release the token only if you are sure that it is still locked due to an error.
Prerequisites
The monitor lists the state of each token that belongs to the token manager that you selected under Destination. A token can be
FREE, H FREE, REFD or MOVD (see: Converting the Token Concept).
The monitor gets the necessary information from the
CSL_MTLK token table. To optimize memory space, the CSL generates only one database entry and only if absolutely necessary. After a token has been
generated, it is visible in the home token manager in the following cases:
If the token has been moved (state =
MOVD)
If a reference has been requested for the token (state =
REFD)
In both cases, the entry is not written to the database until
COMMIT WORK (during the update, usually).
Therefore, if the token was generated and requested locally only for a
cross-system lock in an LUW, no database entry is written yet. This is not necessary in this case since the lock is guaranteed with the standard lock (state = H
FREE). This lock is visible in transaction SM12, even though it does not appear in the CSL monitor yet. If the CSL has written a database entry for the token, this
entry is updated every time the status changes, and any changes are displayed in the monitor from then onwards.
Scope of Functions
Releasing a Token
You can release tokens in the monitor only if they have the
REFD status. To release a token, select the entry and choose Release.
To release tokens that have been locked by using a standard lock (status = H
FREE), use transaction SM12.
Tracking a Token
If a token is displayed in the monitor as having the
MOVD status, you can select the first row (hotspot click) to call the monitor in the logical system where the token was moved to. Choose F3 to return to the selection
screen of the last monitor. To return to the last displayed results list, choose Refresh.
Detailed Display
You choose Details to display detailed information about each token in the monitor. However, you usually use the detailed display only for tokens that have the
REFD status to identify the user of the lock. The Lock Information field contains additional information if the parameters PEOCOUS, PEOCOLS, or PMONINFO are
filled when the CSL modules are called:
Contact:<value of PEOCOUS>/<value of PEOCOLS>.info:<value of PMONINFO>.
These fields are not optional for remote calls of the CSL since administrators cannot always access the calling system, which means that they cannot use a user
name to identify the person responsible.




PUBLIC
2013 SAP AG or an SAP affiliate company. All rights reserved.
Page 20 of 20