Skip to Content

The cross-system object lock functionality ensures that when an object is changed in a managed system, a lock entry is created for this object in the central SAP Solution Manager system. Depending on the selected conflict analysis scenario, this lock entry prevents changes being made to this object by any other change (transport request). This applies to all managed systems and clients for which the cross-system lock has been activated.

Once the cross-system object lock has been activated, the system can detect conflicts between objects in transport requests that have the same production system or the same production client as their transport target.

The meaning of the cross system object lock function is to protect your production system from “passing developments”.

Inside a Change Request Management maintenance project all changes (Normal, Preliminary, Urgent and Defect) will consolidate with the project. As the import method is IMPORT_PROJECT_ALL “passing developments” inside a project can never happen.

An exception to this is that Preliminary Changes & Urgent Changes can pass each other within a project. Therefore the use of CSOL is necessary to protect the PROD system from downgrades.

Also if more than one project is available for the same system landscape, CSOL can protect the PROD system from downgrades.

Automatic Categorization of Objects to retrofit (Auto Import, Retrofit and Manual) is based on the Cross System Object Lock entries in Solution Manager
If the Enhanced Retrofit function does not detect a Cross System Object Lock entry for an object of a transport requests that should be retrofitted, the object will be flagged as Auto Import object.

/wp-content/uploads/2014/12/error_604368.jpg

A change to object A is performed in the DEV system. This change is recorded in the CSOL table of Solution Manager. Now it happens that in the PRD system a fix is needed. The fix will be performed in the MAINT system and has to change object A as well. As the CSOL entry blocks the second change (fix) of object A the only solution to go on is to delete the CSOL entry as the fix is necessary to solve the issue in PRD.

If now the transport request in MAINT is released and the retrofit categorization is calculated the retrofit will not detect an entry for object A and therefore calculate a green case.

If now retrofit is performed the version of object A in the DEV system is overwritten!

How can we avoid this behavior?

You can customize how CSOL shall behave.

/wp-content/uploads/2014/12/csol_604499.jpg

/wp-content/uploads/2014/12/csol2_604500.jpg

You will find default mode and expert customizing.

We will need to use the “expert” customizing as the default mode does not protect you 100% from the issue described above.

csol cust.jpg

The “Project Relation” customizing is key for the enhanced retrofit scenario. In default it’s set to “cross” which means conflicts from different projects as well as conflicts within the same project will stop the process.

What we want to avoid is exactly that conflicts from different projects will end in a termination of the process. Therefore the project relation has to be set to “Specific”. This means that only conflicts within the same project will result in a termination and for different project will only appear as warning.

The other settings do not influence the enhanced retrofit behavior, so Change type relation and object type can be set however you need. But it’s necessary that the project relation is only set to “specific” in the case you have the enhanced retrofit scenario active in your landscape.

One exception comes if you can for sure exclude Maintenance projects in the DEV landscape. In this case urgent changes cannot be created (this is only allowed when using maintenance projects) which means the default mode comes back into the play again.

Also possible is the warning only setting which results in that all conflicts will ever be detected as warning only and the process is never terminated.

In this case it’s necessary to also activate the downgrade protection (DGP). This will ensure that if you get a warning in CSOL you can still not get passing developments as it checks again for release and every import.

So with these allowed settings you will never need to delete an entry from the CSOL list because of Urgent Changes needing to be implemented to PRD as fast as possible. Also in any other conflict situation you will never need to delete entries from the CSOL list to go on with your process.

Like this you will never get a wrong “green” retrofit categorization which will end up in an over write in DEV.

Conclusion:

When using enhanced retrofit in Solution manager the use of cross system object lock is mandatory for the correct behavior of the tool.
You cannot use the enhanced retrofit without having CSOL setup and activated for the retrofit relevant projects.
With some of the available conflict analysis customizing settings in cross system object lock  the danger of downgrading your Implementation work appears.

When using the enhanced retrofit, you should only use project relation “specific” . Any “cross-project” setting is not allowed, because a terminating cross system object conflict would require the deletion of the corresponding lock entry. But that lock entry is required for the correct  analysis of the enhanced retrofit.

Summary:

When using the enhanced retrofit scenario make sure your CSOL customizing is set to “specific” from the project relation point of view.

Also “warning only” is a valid setup if on top DGP is activated. The default mode can also be valid for the enhanced retrofit scenario when it’s ensured that no Urgent changes can ever be created in the implementation landscape (DEV).

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Juan-Carlos Garcia-Garavito

    Thanks Frank, indeed.

    We use cross combined with warning only, hence it does not matter whether the developer is working in the same or in different projects, he/she receives only a warning, but can continue his/her development, having to deal with the DGP checks later on.

    We believe that approach may be cleaner than only using the option specific without warning only.    For the latter, what would happen in the case one goes to change the same object in different projects, not being aware of a potential DGP conflict because the flag is not set to cross? We believe that has a level of risk.

    You mention the option we followed, although as a final resource.  Some advantages:

    1.  Cross, involves all projects, so DGP coverage is expanded.

    2.  Warning only, allows to still continue developing over the same object, instead of being halted ipso facto.    For this case, DGP check can be performed later on to be ignored, if necessary, or proceed in the correct transport move to avoid issues.

    Probably the specific without warning only works for you best, as it works for us the cross with warning only.  Is there anything we should be aware of that we may have missed your good article?

    Regards,

    Juan

    (0) 
    1. Frank Jungmann Post author

      Hello Juan,

      thanks for your feedback.

      In my blog i was trying to show all possible allowed setup scenarios.

      You are correct with your analysis if you assume conflicts are only detected for specific when setting specific and not cross. You also assume that has a level of risk.

      I can guaratee you it’s not, as the CSOL customizing allows to set the conflict detection to specific this only means “cancel -hard stop” for specific conflicts. In case of cross conflicts happening when specific is set anyway a warning will be displayed.

      Long story short: it doen’t matter which CSOL setup you choose, any conflict will ALWAYS be displayed. With the customizing you can just influenece if it will be displayed as hard stop or a s warning.

      Best regards,

      Frank

      (0) 

Leave a Reply