Professional Documents
Culture Documents
RETROFIT CONCEPT
RETROFIT
Support Changes
v1.1
Maintenance V1.1 V1.1
DEV 1 QUAL 1 PROD 1
Landscape
After Successfully
v1.1 Tested
RETROFIT
v1.1
v1.0/v1.1 v1.1
If a change is done in DEV1, this change must also be done in DEV2 to maintain the synchronization this is the reason for retrofit, to bring the
changes made in DEV1 to DEV2
How Retrofit works
Automatic Categorization of Objects (Auto Import, Semi-automatic, and Manual)
Types of Imports
Auto Import (Support of 100% of transportable objects!)
• Applies for all Objects of a Transport Request which have no conflict. They have not been changed in the retrofit system so there is
no CSOL lock entry for them in the Solman system.
• Retrofit is performed through a transport of copies (TOC) which is automatically created and released, and contains only the objects
without conflicts .The retrofit tool imports this TOC into the retrofit system and copies the objects into the indicated retrofit
transport request). This TOC is created after the release of the transport requests in DV1 system.
• Both tools offer the possibility to do adjustments, which are necessary in case of a conflict to not simply overwrite a change in the Implementation Project
(Release Development).
Manual retrofit
• Objects with conflicts which have no support tool.
What is CSOL?
Conflict Detection is performed via Cross System Object Lock CSOL at object level
• 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.
A system will appear in /TMWFLOW/CMSCONF if the system is used in a project with ChaRM activated .
2. Configuration
2.1. Settings in the managed system
You will require either a trusted system connection from managed to solman system, or you
In the managed system you need to create a SOL_CONNECT entry in /nSM30
have to create an RFC connection with a special user of the type 'S' (Service). Assign the service
> bcos_cust:
user at least the SAPSOLMANTMWCOL role. See KBA 2004134 - CSOL - RFC from managed
system to Solution Manager system
In the example the RFC Connection is pointing to the Solman system SMM:001 where
the lock entries are saved, and also where ChaRM is configured.
2.2. Settings in the SAP Solution Manager system: Lock conflict analysis scenarios
When you are activating CSOL globally, you can see these options:
The following aspects will be considered when determining the message type for CSOL conflict popup:
• Project Relation (Same project/Different project): Projects to which transport requests are assigned
• Cross: Transport requests belong to the same project or to different projects (Project(s) are
ignored)
• Specific: Transport requests belong to the same project
• Different: Transport requests belong to different projects
• Change Type Relation (Change Transaction Type, also for QGM changes)
• Urgent Only: Both transport requests belong to different urgent changes
• Partial Overlapping: At least one of the two transport requests belongs to an urgent change
• Overlapping: Always (System ignores the type of change to which the transport requests
belong)
• Transport object type (All objects, including repository (workbench) and Customizing objects)
• Cross-Client: Object type is cross-client workbench object
• Client-Specific: All object types are taking into account
3. Operation
As soon as a developer modifies an objects in the development system and saves it into a transport request created/managed by ChaRM, some lock entries will be created on the central
SAP Solution Manager system, by using the configured RFC in BCOS_CUST, containing the objects information in that request for all production systems which it will be delivered to.
The Change Manager can monitor all CSOL lock entries in the central SAP Solution Manager system by executing /N/TMWFLOW/LOCKMON and choosing appropriate search criteria:
In the output result Repository locks and Customizing locks are displayed in separate tabs, where all relevant information (request, object, project, task list, developer) is displayed.
• Here the key fields are the production system/client, which means CSOL can only be used when the project contains at least one production system (even if it is a virtual system). If
your project does not have a production system you can not used CSOL.
• If the changed object is a workbench object, then only if the transport request is released another user can try to modify the same object for another time and save into a different
transport request.
• However if the changed object is a customizing object then another user can try to modify the same object for another time and save into a different transport request even when
the first transport request is not released. But notice that when the first transport request is released what it is released if the active version of the customizing object at the release
time.
• When somebody tries to modify the same object for another time, the system will issue a popup to remind the user that this object is already locked in another transport request. If
the popup is a warning message, then the second change can still be saved and some new lock entries will be created; if the popup is an error message, then the second change
cannot be performed.
• In CSOL popup you can find the developer’s user account who was locking that object, together with the transport requests number which were used, and the ChaRM project ID
where those transport requests were created.
3.1. Deletion of CSOL Lock entries
When the first transport request is successfully imported to all production systems and the first transport request no longer exists in the import buffer of the production systems, the
change is finalized and the object lock will be deleted automatically in CSOL. Then another developer can edit those objects without any restriction.
If the import is failed and you have corrected it manually, in CSOL we will treat it the same as successfully imported request.
Besides that, user also can delete the locks manually in transaction /N/TMWFLOW/LOCKMON. This normally is needed when there are emergent changes which are blocked by existing
CSOL locks. Authorization object SM_CM_CSOL will be checked for this deletion action.
4. Limitations
In SAP Solution Manager 7.1 the CSOL functionality does not support non-ABAP changes
5. Troubleshooting
5.1 CSOL popup is not shown in the managed development system
Execute report TMW_CONTROL_PROJECT_LOCK in transaction SE38 on your development system and select option Read Client Data "X":
You will see if the CSOL is activated or not for the system : client where you are running the report, if it is activated you will see entry CSL X, and also the used RFC connection to the
SAP Solution Manager where the lock entry is stored.
In the case that the CSOL is not activated you can run the same report with option Activate Project Lock or activate the CSOL in the SAP Solution manager system in transaction
/tmwflow/cmsconf.
If the CSOL popup still is not coming when editing/saving an object that already has a lock entry check that CSOL is globally activated.
No CSOL popup will appear between two transport requests that belong to the same import group, see KBA 1995630 - No CSOL popup when working with one change document
Ensure that you created the transport requests from a change document for projects having logical component with a production system : client filled, enter a virtual system :
client if still you don´t have the production system. If there is not a system : client indicated CSOL will not work.
5.2 SAP Solution Manager is down
If SAP Solution Manager is temporarily unavailable but you still want to change objects in the development system, execute report TMW_CONTROL_PROJECT_LOCK report in the
managed system. Select option "Deactivate Project Lock" to deactivate the cross-system object lock temporarily and change the objects. When SAP Solution Manager is available again,
you can activate the cross-system object lock by executing the same report and selecting "Activate Project Lock" and run the TMW_TRKORR_LOCK_UPDATE report for the transport
request in which you saved objects during the inactive period.
This report will be required for example if the SAP Solution Manager system was down and you deactivate the CSOL temporarily. Therefore, this report can also be used to upload
those lock information when CSOL has been reactivated.
If you select the "Dialog mode" then you will see the same CSOL popup as when a user is doing the saving of the object to the transport request.
5.4. Bypass error messages for emergent changes
It might happen that your lock conflict will give the developer an error message when performing some emergent changes. In such cases, if you cannot move those previous transport
requests which contain the locks to the production systems immediately, you may want to find a way to "ignore" those errors and "forcibly" save the change. In general there are four
ways which can be used for this purpose and you can choose any one of them to suit your own needs:
•Temporarily deactivate CSOL globally
•Temporarily deactivate CSOL locally
•Temporarily change the CSOL conflict scenario to a setting which will only show warning message in your lock case
•Manually delete those lock entries from previous requests in the lock monitor
7. CSOL tables
/TMWFLOW/TLOCKP: Lock entries for workbench requests
/TMWFLOW/TLOCKPC: Lock entries for customizing requests
/TMWFLOW/SERVICE: Globally activation info for SOLMAN system
/TMWFLOW/REPCLNT: Locally activation info for managed systems on SOLMAN side
TMW_ADM: Table on managed system showing if system : client is having CSOL activated (CID_ACTIVE X) and the RFC destination to the SAP Solution Manager where the lock
entry will be saved.
THANK YOU..