Cross system object lock (CSOL) is a functionality offered by SAP to support multiple parallel projects execution in the same system or across different systems. There are some typical scenarios when companies prefer to have a single development system or multiple development systems to accomplish the parallel projects.

A.      A company wants to rollout its global processes across different locations. For this, they have created a common template and then via multiple parallel projects, the organization wants to rollout the common scenarios with some adjustments to fit into local requirements. In this case, the organization may go for using the same development system to accomplish the parallel projects as per requirement.

B.      The company has already rolled out its scenarios to a specific geography or location and has a productive landscape. The organization is rolling out its processes in different project release. Or the company has already existing SAP landscape and now they want to extend the functionalities to the newly acquired branches. In these situations it is not advisable  to use the same development system for a new project which is used to support productive landscape. The company may opt for having a different development system to complete the project activities without disturbing the current productive landscape.

In any case, if the production environment is same, it is needed to ensure that the same object is not getting modified by different teams as it may cause inconsistency in productive environment. So, it is required to have a strong collaboration across teams to ensure that the object being developed by someone is not getting changed by some other person. In other words, the object should be locked by the person who wants to change it untill the change is productive. But in practice it is not always possible to understand that some other group is already working on an object that I want to modify especially if there are more than one development systems. CSOL functionality of SAP Solution Manager ensures creating lock for the objects which works inside same and across different development systems.

This object lock functionality is delivered as part of Change Request Management scenario of SAP Solution Manager. To be able to use this functionality, it is needed to create all the transports through SAP Solution Manager. The functionalitydoes not  work for any transport created locally in any of the development systems. It is not required to use the service desk and change request ticketing cycle of creating normal or urgent correction. However, the least requirement is to use the task list of SAP Solution Manager for creation of any transport request. You may look at the link: First steps to work with Change Request Management scenario in SAP Solution Manager 7.0 for the configuration required to get the task list.


Note:  In this blog I will discuss based on urgent and normal correction. If your landscape has restricted use of Solution Manager- just for central transport management activities, details related with normal correction will be applicable to you.

 Object Lock Scenarios

SAP Solution manager works on following principle:

Whenever a change is made for any customizing or repository object, an object lock is created in SAP Solution Manager. The lock is removed only after the object is imported to production system. When any other user tries to modify the same object, system displays object lock message. Depending upon the type of scenario used for object lock, system displays either warning or error message.

There are 12 scenarios provided by SAP to be able to cover all types of lock requirement by the customers:

Csolscenariopart1 67453 8182085

Csolscenario3 67455 1837762


Error Message
Warning Message

CSOL Setup

To configure this functionality, there are some settings required to be done in both SAP Solution Manager and the satellite system.

A.      Satellite System Configuration:

To be able to communicate with the satellite system, Solution Manager uses the RFC connection. You may have trusted or a non-trusted RFC communication for the communication. If you go for trusted RFC connection, it is needed for all the developers in the satellite system to have same user ID existing in SAP Solution Manager system with RFC connection role. If this is not the case, youo may go for having a special user of type ‘S’ with role SAPSOLMANTMWCOL created in SAP Solution Manager and assigned to the RFC connection from satellite system to SAP Solution Manager .

You also need to maintain following entry in table BCOS_CUST table in transaction SM30:

1.       In Appli field enter SOL_CONNECT

2.       In dest.Field enter the RFC connection name (creaed above)

A.      Solution Manager Configuration:

1.       Activate client level object lock:

You need to activate CSOL at each client level for each system as follows:

  1. Use transaction /n/TMWFLOW/CMSCONF (or IMG node: SOLMAN_CM_PRJ_LIFECY)
  2. Select the tab System change option
  3. Select required satellite system for which object lock needs to be activated.
  4. Click node to drill down and check status available under   column Cross system object lock
  5. If it is inactive, double click on it and select Yes in the popup asking change system option
  6. Repeat the same for all required development systems.

2. Activate Global Object lock:

  1. Use transaction /n/TMWFLOW/CONFIG_LOCK (or IMG node: SOLMAN_CM_PRJ_LIFECY)
  2. Under cross system object lock parameter- select cross system object lock active option with Conflict analysis scenario based on the requirement (details of options are covered in section object lock scenario)


1.       As  CSOL works just for transports created through SAP Solution Manager, you need to activate ChaRM basic setup. You may use the trusted RFC or back RFC for RFC connection required for activity A which are already available because of ChaRM setup.

2.       You may use report SAPLTMW_PROJECT_LOCK to activate/ deactivate the object lock locally in the system (step 1 of activity B above).

3.   The lock is formed at Key level for customizing objects and at LIMU level for workbench objects.

Working Example

Suppose user A starts working on an existing program ZXVEDU11. As soon he collects the program change in the transport created though SAP Solution Manager, a lock entry gets created in SAP Solution Manager.

Now if user B changes the same program and tries to collect the change in the transport created through SAP Solution Manager, a lock entry is displayed containing the system, transport and owner information in which the object is locked.

Objectlockpopup 67458 5439528

This is the trigger point for user B to discuss with user A for the changes. If the lock is just a warning, the same can be bypassed by click on the continue button on the object lock popup. However, if it is an error lock, system will not allow proceeding further until the existing lock has been removed from the object. So, object B needs to consult the administrator for removal of the lock.

Administrator can use transaction /n/TMWFLOW/LOCKMON in SAP Solution Manager and enter the relevant parameter in the initial screen to see the object lock. Lock can be removed by selecting the object and then the lock removal button.

Once done, user B can proceed further with the changes.

Further Readings

If you are working with parallel projects in multiple system landscape architecture, you need to perform retrofit activity to be able to move updates from one landscape to other . CSOL helps in understanding the object conflicts while development and as well while performing retrofit to avoid the potential overwriting of the objects in target system. details of retrofit process can be found in blog: Change Request Management scenario: Retrofit Functionality

New NetWeaver Information at

Very Helpfull



User Rating: Be the first one !