Settings in Customizing

Use

You can control the following for the CSL in the Customizing settings:

  1. Activation of the CSL

  2. Mapping onto lock object types

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

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