Converting the Token Concept (SAP Library - Cross System Lock (BC-CST-EQ))

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.

Note

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:

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).

Note

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 token manager for each logical system:

This graphic is explained in the accompanying text

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.

Note

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.