7.2: How to work with Change Request Management Enhanced Retrofit

*NEW* Since SAP Solution Manager 7.2 SP08 the Automatic retrofit for non-ABAP Objects is supported. See section 5.Retrofit for non-ABAP objects for details.

Purpose

With the following steps, you will be able to create a test landscape to practice the Enhanced Retrofit functionality in SAP Solution Manager 7.2.

Also, I will try to give tips and tricks for the configuration of this scenario in SAP Solution Manager 7.2 and how to analyze possible issues using this functionality. Screenshots are taken from a SAP Solution Manager 7.2 SP07 system.

Note: For the new Standalone Retrofit functionality in SAP Solution Manager 7.2 please check KBA 2488168 - Standalone Retrofit - SAP Solution Manager 7.2

*MANDATORY NOTE* 2741354 - Retrofit: wrong categorization of customizing objects

*MANDATORY NOTE* 2538538 - ChaRM&QGM: Wrong system role is assigned during transport track generation

Overview

Software changes are done in one system and will be transported to the system landscape which is linked to this system by transport routes of the Transport Management System. But sometimes it is necessary to implement these changes in another system landscape but without using the import function of the transport requests.

Imagine this scenario with a Maintenance landscape and also an Implementation landscape. Here, PRD would be the system that is already go live.

Now you want to implement a new functionality for your system. You will use a second development system DV2 to work in this new implementation. By working in DV2, you will not disturb the maintenance of the PRD done in DV1 system.

Usually DV2 and QA2 are created initially as system copy from PRD system.

If a change is done in DV1, this change must also be done in DV2 to maintain the synchronization--this is the reason for retrofit, to bring the changes made in DV1 to DV2.

Changes of a Maintenance cycle also should be duplicated in an Implementation cycle that provides the same Production system of the Maintenance landscape.

The main new features and advantages of the Enhanced Retrofit Functionality can be summarized:

1. Automatic Categorization of Objects (Auto Import, Semi-automatic, and Manual)

During the release of the transport request that contains the changes done in DV1, the enhanced retrofit functionality will check all objects contained in the transport request and categorize them one by one. According to this categorization, different retrofit data wil be generated for each object:

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

- Semi-Automatic Retrofit with Correction Workbench (Note Assistant) or BC-Sets

• Applies for all Objects of a Transport Request which have a conflict and which are supported by one of the tools (Repository Objects with Correction Workbench, customizing via BC-Sets). This was available with the "old" version of the retrofit (supportability of 70-80% of objects).

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

2. Conflict Detection is performed via Cross System Object Lock CSOL at object level

- Possibility to perform retrofit on object level

3. Detection of technical sequence dependencies

- Detection of same objects to be retrofitted in which order

- Advanced Control of Retrofit Sequence

4. Additional Features

- Enhanced Logging of Messages

- Comparison of compatible objects before retrofitting

- Various Customizing Possibilities

- Implementation of Customer Specific Requirements via Standard SAP BADIs

Configuration

The configurations given here are valid for Solution Manager 7.2 SP07.

The configuration is done in two parts:

Solman_setup → Change Control Management → Change Request Management → Set Up Downgrade Protection and Retrofit → Configure Retrofit
Perform these activities:
1.1. Define Retrofit Parameters (View /TMWFLOW/RCONFIG): Read documentation of the activity for detailed description of each parameter

Important parameters are:

- - NO_CSOL: The system does not perform cross-system object checks and does not create entries in the cross-system lock for automatically created import objects in the target system. This can avoid errors when saving those objects to a target transport request in case the cross-system object lock is active.
  - WARN_TOC: Imports of transports of copies are handled as successful even if there are warnings. When active, the import is marked as successful even if there is a return code 4.
  - SCEN_CROSS: Enables cross-release retrofit. Systems need to be specified under Define System-Specific Retrofit Settings.

*NEW* Since SAP Solution Manager 7.2 SP08 the Automatic retrofit for non-ABAP Objects is supported.

For this functionality you need to enter in view above these retrofit parameters with X Paramater Active according to the non-ABAP Object you require:

- - SCEN_FILE Enables the support for non-ABAP Objects in Retrofit. If active, the object type FILE will be set to manual processing.
  - SCEN_HTA If active, SAP Hana Transports for ABAP (Object types HOTA / HOTO / HOTP) will be set to manual processing.

1.2. Status Customizing for Retrofit Objects Optional (View /TMWFLOW/EDT_CST): In this configuration activity, you can allow or forbid certain manual changes to the objects in the retrofit object list of a transport request. You can activate a warning or an error message for any possible status change in the object list.

1.3. Define Values for Retrofit Scenarios Optional (View /TMWFLOW/RSCEN)

In this configuration activity, you define which objects are selected for the manual processing in a retrofit.

You can do this for the following scenarios:

- - Retrofit scenario for manual processing (SCEN_MAN) You can use this as a list defining the objects that you want to exclude from automatic retrofit.
  - Retrofit scenario for Business Warehouse objects (SCEN_BW)

1.4. BAdI: For the Creation of Retrofit Data Optional (BAdI /TMWFLOW/RETRO_EXTENDE_DEFAULT): You can use this Business Add-In /TMWFLOW/RETRO_RELEASE_IMPL to implement customer-specific changes that are performed before the retrofit.

1.5. BAdI: During the Retrofit Optional (BAdI /TMWFLOW/RETRO_DURING_IMPL

1.6. BAdI: After the Retrofit (BAdI /TMWFLOW/RETRO_EXTENSION_ENH)

2. Solman_setup → Managed System Setup→ Configure Extended Function → Configure Retrofit

2.1. Activate Domain Links

For the retrofit scenarios, you need to activate a domain link between the domain controller of the maintenance landscape and the domain controller of the implementation landscape.

You have to connect the domain this system belongs to with a domain link.

2.2. Define System-Specific Retrofit Settings (View /TMWFLOW/RCFGSYS): Required if you have activated the Cross-Release Retrofit parameter under Define Retrofit Parameters).

2.3. BAdI: Activate BAdI in Managed System: required only for Standalone Retrofit

2.4. Prepare Implementation Landscape for Retrofit: required only for Standalone Retrofit

2.5. Prepare Maintenance Landscape for Retrofit: required only for Standalone Retrofit

Despite these are the configuration points in solman_setup I miss some configurations so allow me to define step by step how to configure retrofit scenario for this test landscape:

Maintenance landscape: EYE:100->EYE:200->EYE:300

Implementation landscape: EYE:101->EYE:102-> EYE:100

EYE:101 is called the retrofit system.

Step 1. Create the additional clients

EYE is a Solman system, client 001 is the client where ChaRM is configured.

I want to use these landscapes in TMS:

Maintenance landscape: EYE:100->EYE:200->EYE:300

Implementation landscape: EYE:101->EYE:102-> EYE:100

So, create these fice additional clients in EYE, like local client copy from client 000 with SAP_ALL profile, for clients 100, 200, 300, 101 and 102.

Ensure you set the correct roles for these clients in SCC4, more details in this link.

Note: when using the Semi-Automatic Retrofit with BC-Sets there must not be any client with client role P Live in the retrofit system.

Step 2. Create the test landscape in TMS

Please see how to create this test landscape in this link.

Key points

Transports are supported in the standard transport layer of each client. When you configure the transport routes, note that only consolidation routes that are assign to the standard transport layer of the relevant exporting client are taken into consideration.

For each exporting client, exactly one target client and one target group are permitted.

We recommend that you assign exactly one development system to a production system, and that these two systems are connected by exactly one unique transport track.

If a development system and a production system are connected by more than one transport track, this may lead to inconsistencies within the transport distribution.

In the SAP Solution Manager system, in client 000, call /nSTMS (the TMS configuration should be done in the domain controller system of your real TMS managed landscape). In our example, SMD is the only system and so it is the domain controller.

Configure transport routes and transport strategy

In EYE client 000 call /nstms and get these transport routes created:

Note: EYE client 001 does not need to take part of your TMS landscape.

Follow the indications in this link to create these transport routes.

No transport route between source Dev system in the maintenance landscape and Target Dev system in implementation landscape (retrofit system) is needed.

Stept 3. Create a domain link

It is very important to establish a domain link between these two TMS landscapes!

You need a domain link between the maintenance TMS landscape and the TMS implementation landscape (if not you will have problems later while importing the TOC created in EYE:100 to client EYE:101). Even if you are using Harmonizing infrastructure for Enhanced Retrofit scenario, the domain link between both transport domains are required.

Ensure Trusted services are activated in both domain controller systems.

Domain links between these two TMS landscape with the SAP Solution Manager landscape is no required.

Step 4. Create the RFC destinations for these clients in LMDB

In LMDB in Technical Systems tab enter the systems and create the RFC destinations for them in Destinations section.

In our case for EYE:100, 200 and 300 and EYE:101, 102.

Follow the information in this link.

You will need these connections for each client:

Step 5. Check the ibase components

Ensure that the ibase components are created in /nib53 for the systems:clients involved in the maintenance and the implementation landscapes.

Step 6. Create the logical component group for these two landscapes

In the wiki page How to create a solution for Change Request Management in SAP Solution Manager 7.2 you will see the steps to create a solution, branches and logical component group LCG for this test landscape in /nSLAN:

Maintenance landscape: EYE:100->EYE:200->EYE:300

LCG can be regarded as a projection of managed system infrastructure into SAP Solution Manager system, so it must represent the real landscape and the system roles should be consistent to system roles at TMS level. That is, for development system, the Type of Role should be Source Systems; for test systems, the Type of Role should be Target Systems; for production system, the Type of Role should also be Production Systems.

Ensure that there are consolidation routes defined from the source system to the first target system and delivery routes created between target systems and from the last target system to production system.

For the implementation landscape: EYE:101->EYE:102-> EYE:100 you will need to create a Development branch to locate EYE:101 and EYE:102, see details in this link.

As both landscapes mantenance and implementation landscapes are for the same SAP Product please put all systems from maintance and from implementation landscapes under the same logical component group name.

Note: EYE:100 is in this LCG under Maintenance- Development system. This is ok, I mean a system:client inside one LCG can only appears one time.

As in the TMS you have a Delivery route from EYE:102 to EYE:100 later when creating the implementation cycle the EYE:100 will appears in the production system position.

In a real scenario you will have for example:

Maintenance landscape: DV1->QA1->VA1->PRD

Implementation landscape: DV2->QA2 -> ….

Finally the changes done in the implementation landscape, TRs created in DV2, need to arrive in PRD; you can decide in which way to get these TRs imported into PRD. Depending on this decision you can create different implementation landscapes like:

DV2->QA2->VIR or

DV2->QA2->DV1 or

DV2->QA2->DV1->QA1->VA1->PRD

Step 7. Create a cycle for the maintenance landscape

You need to create a cycle for the maintenance landscape EYE:100->EYE:200→EYE:300.

In the Solution Manager system in the WebClient UI, /nsm_Crm, create a new change cycle, follow the indications of this link.

You need to get this final picture:

Key point is that you need to enter during the task list creation the Retrofit system EYE:101 under Retrofit Systems area:

You could retrofit to several Post-processing systems.

Note this particular line from EYE:100 to EYE:101 ( remember that you don´t need to create any transport route from maintentance development system to implementation development system=retrofit system):

In the task list you need to see your retrofit system under Systems Without Transport Connection- Post-Processing systems:

Unlock the Group also for Systems Without Transport Connection.

Note: Since SP05 if you have a cycle where you want to make changes to the Retrofit system/systems you will get the "old" released transport requests in this cycle also shown in the Start retrofit popup, with RED ball as no retrofit data exists.

Ensure you have applied SAP Note 2688134 - Retrofit: Irrelevant transports shown in overview to get the correct transport requests entries.

If you don´t want to see those entries with Process Retrofit as Retrofit status use the report indicated in SAP Note 2689341 - Retrofit: Mass reject transports to reject them.

Step 8. Create a cycle for the implementation landscape

You need to create a cycle for the implementation landscape EYE:101 ->EYE:102 ->EYE:100.

In the Solution Manager system in the WebClient UI, /nsm_Crm, create a new change cycle, follow the indications of this link.

You need to get this final picture.

Select Development branch.

See that EYE:100 is located under Production Systems area, even being located under Development System column in the LCG.

You need to have in the implementation cycle a system:client under Production Systems to get CSOL scenario working, CSOL requires that the is a production system.

Step 9. CSOL activation for the Retrofit system

We need to activate CSOL for the implementation development system DV2=retrofit system and also globally.

The point is that you need to get a lock entry for every object is changed in the retrofit system, in the development system DV2 of the implementation landscape (EYE:102).

Then if the same object is modified in the DV1 system (EYE:100), the lock entry is detected and autoimport retrofit option will not be available for this object.

Globally activate the cross-system object lock by following the indications in this link.

Locally activate the cross-system object lock for the retrofit system by following the indications in this link.

Note: for the Retrofit scenario "On (Legacy CSOL)" setting is enough.

Then perform the configuration in the retrofit system for CSOL according to this link.

Please execute report TMW_CONTROL_PROJECT_LOCK on your retrofit system and select option Read Client Data "X" to ensure that CSOL is activated correcty.

Step 10. RFCs connections required for Retrofit

Initially you don´t need to create these RFC manually, the first time a retrofit is triggered using SCWB or BC Sets from the Start Retrofit popup these RFC destinations will be created automatically.

CWBADM_<SID>_<client> : from the retrofit system to the development system in the maintenance landscape, in our example from EYE:101 to EYE:100. Used by the SAP Correction Workbench, SCWB is doing a remote delta comparison from the retrofit system to the development maintenance system. Therefore a trusted RFC-Connection from Retrofit System to Development System needs to be established. User running this retrofit action in the Solman system needs to exist in the maintenance development system with trusted authorizations

RETRO_<SID>_<client> : from maintenance project development system to retrofit system, from EYE:100 to EYE:101. Used by the BC-Set tool, BC-Set tool is locally created on the development maintenance system, during the retrofit process it is transferred to the retrofit system and activated there. To support this process it is necessary to establish a trusted RFC Connection from Development System to Retrofit System. User running this retrofit action in the Solman system needs to exist in the retrofit system with trusted authorizations.

Check if the retrofit RFCs are created automatically when you perform the first retrofit activity with SCWB and BC-Set.

User executing this first retrofit activity needs to have enough authorization, authorization object S_RFC_ADM, to create RFC destinations on the managed system(s).

Ensure that you activate TMS Trusted Services in both domain controller systems and that in /nSMT1 there is a trusted relationship between the two systems.

Therefore you need to make sure that the user performing retrofit has TRUSTED authorizations to :

Log on to Retrofit system ( EYE:101 in this example landscape ) from SolMan system using SM_<SID of Retrofit system>CLNT<client>_TRUSTED ( SM_EYECLNT101_TRUSTED in this example).
Log on to source development system ( EYE:100 in this example ) from Retrofit system ( EYE:101 ) using TRUSTED RFC CWBADM_<SID of Source development system>_<client> ( CWBADM_EYE_100 in this example )

Retrofit Workflow

Once the configuration is done this is how the scenario works:

At the time of the release of the transport request, created from a ChaRM document for the maintenance cycle where a retrofit system was specified or from the task list of this maintenance cycle, all objects included in the transport request, like DV1K9*, are checked and the retrofit data is created for the objects depending if there are entries or not for the same objects in the CSOL tables like /TMWFLOW/LOCK*.

If there are not entries for the objects in /TMWFLOW/LOCK* tables then a transport of copies TOC is automatically created and released in DV1 system with target DV2 system and will contain these objects without conflicts.

If the objects included in the TR created in DV1 have been changed already in the retrofit system DV2 then there will be entries for the objects in /TMWFLOW/LOCK* tables.

If this is the case and depending of the object type the retrofit data created in the DV1 system will be a BC-set for customizing objects. For workbench changes we will need to use SCWB tool.

In some particular cases no retrofit data could be created.

When you have objects in the transport request with different categories the retrofit data will be created accordingly for each object.

Note: The transport request release needs to be triggered from ChaRM for getting these objects check performed.

Note: In general the recommendation is to process the retrofit as soon as the transport request is released and retrofit data is created.

Check in section Retrofit tables 7.2 how to see at table level the data created when the retrofit data is generated.

Later when you start the retrofit you need to select for each TR to be retrofitted a TR created in the retrofit system DV2.

Retrofit process will make that the changes included in TR DV1K9* arrive to the retrofit system DV2. These changes will be recorded into a DV2K9* transport request.

You can start the retrofit process from:

• An urgent change when the status is "Authorized for Production" from the action list

• A normal change when the status is "Successfully Tested " from the action list

See KBA 1906129 - Action "Start Retrofit" of Charm does not show up in Web UI if the Start Retrofit action is not available at document level in the indicated statuses.

• The task list that contains a Post-Processing retrofit system

We are going to see examples for the use of auto import, semi-automatic and manual retrofit. Please make sure that the user processing the retrofit has TRUSTED RFC authorizations to Retrofit system (e.g EYE:101).

1. Auto Import

If no conflict (lock entry) exists then auto import can be used for customizing and workbench transport requests.

The objects included in the TR released in DV1 have not been changed in the retrofit system DV2 so there is no lock entry for them in the Solman system.

At the time of the release of the transport request all objects included in DV1K9 * are checked. If there are objects without lock entries in /TMWFLOW/LOCK* tables then a TOC is automatically created and released and will contain only the objects without conflicts.

Retrofit auto import tool will import this transport of copies into the retrofit system, changes will arrive to the retrofit system and objects will be recorded in the retrofit request.

After a successful import of the TOC objects into the retrofit TR he status of the request is set to Retrofitted automatically.

Steps:

Create an urgent change UC for example for the maintenance cycle, and create TR1 for this UC in EYE:100 Development system of the maintenance cycle.
You could also create a TR directly from the task list of this cycle.

Note Due to the test scenario selected, different clients of the same system EYE, we are going to test with customizing transport requests.

Note: For workbench change you could create a function group in se80 or a program in se38.

Make a change in sm30 T005A, V_T005K ...
For example create entry:
050 Change 1 in MC for TR1
and save it into TR1 EYEK901544

Release TR1 task
Release the TR1 from the task list or from the change document "Pass Urgent change to Test"

Is there a lock entry in Solman system in /TMWFLOW/LOCK* table for this WB function group or for the view V_T005K? No! you can check for the lock entries also in the Administration Cockipt- CSOL tab

Then a TOC will be created and exported at the time the TR is exported from ChaRM. You can check this in table /TMWFLOW/RTROBJT. As the objects included in the TR1 has OBJ_CATEGORIE 2 then the retrofit data will be created using TOC:

In table /TMWFLOW/RFITCT you will see the retrofit data for this TR1;

See also table /TMWFLOW/TOCASNT where you can see the created TOC number per this TR1:

This TOC was created and released automatically with the objects of TR1 the target system of the TOC is the retrofit system EYE:101 in our example:

In case of errors creating the retrofit data you will see them in the Release TR logs:

Now I create a TR2, retrofit TR, in EYE:101 to retrofit TR1 to TR2, in this case importing the content of the TOC to this TR2. You can do this quickly from the task list of implementation cycle: TR2 EYEK901547

Start retrofit from the task list for maintenance cycle:

As all objects in this TR1 had obj_category 2, you can see a Green bullet under Critical Retrofit column.

I need to assign to TR1 the retrofit TR2 where I want to save the content of the TOC. To do this, select the row and click on Auto-import button.

Select Retrofit for all categories or Auto-Import as Retrofit Category is GREEN.

You can see the logs under Additional Functions-> Display logs

See also table /TMWFLOW/RFITC: here you can see original TR, TR where you retrofitted the objects and if the retrofit is done or not and when:

Table /TMWFLOW/TOCASNT shows that the import of the TOC was correct, value F:

TR2 is getting the content of the TOC when the TOC got imported into EYE:101:

According to the parameter NO_CSOL value in SM30 →/TMWFLOW/RCONFIG you can decide if the object retrofitted in the retrofit system should create a CSOL entry or not.

If parameter NO_CSOL is inactive then a lock entry will be created, as now the object is really changed in EYE:101. Decide the best option for your scenario.

In my testing scenario I was using NO_CSOL with X Parameter Active, so I was not creating lock enties for the entries in T005A 050.

2. Semi-Automatic Retrofit with BC Sets or Correction Workbench (Note Assistant) - Standard retrofit

If a conflict (lock entry) exists then BC Set/SCWB tools need to be used.

The objects included in the TR created in DV1 have been changed in the retrofit system DV2, so there is a lock entry for them in the Solman system.

At the time of the release, the Solman system detects this lock and a BC Set will be created in DV1 system for customizing objects, for workbench changes we will need to use SCWB tool.

2.1. Customizing changes – BC Set tool

Prerequisite: Ensure that user creating the BC Set in the development maintenance system and in the retrofit system has the Deletion functionality for BC Set activated.

Logon to all the development systems -> Transaction SCPR20 -> Utilities -> User Settings -> Maint. Transaction -> Deletion Functionality -> Select “Switch On”

This setting is user specific so all the developer accounts need to activate it individually, otherwise if you delete some customizing changes they won’t be supported by BC Sets. As a result you would not be able to Retrofit them.

At the time of the release of the transport request all objects included in DV1K9 * are checked. If there are objects with lock entries in the Administration Cockpit,, Cross-System Object Lock and Downgrade Protection tab, table /TMWFLOW/LOCK*, then a BC-Set is automatically created in DV1 system.

Retrofit Transfer with BC Set will import the changes included in the BC Set into the retrofit system, changes will arrive to the retrofit system and objects will be recorded in the retrofit request.

Steps:

Make a change in EYE:101 to sm30 T005A for example to the previous entry 050 but changing the entry value from "Change 1 in MC for TR1" to "Change 1 in MC for TR1 /// changed now in EYE:101"

You can save the change to the already existing TR2 transport request:

Or you can create a new entry 051 and save the entry to a new TR created from the implementation cycle task list or document, up to you.

What you need to ensure is that once the entry is saved to the TR the CSOL entries are created.

Now create an urgent change UC for example for the maintenance cycle, and create TR3 for this UC in EYE:100 Development system of the maintenance cycle. You could also create a TR directly from the task list of this cycle. TR3: EYEK901551

Make a change in EYE:100 for entry in sm30 T005A 050, the original value was Change 1 in MC for TR1, I add this text Change 1 in MC for TR1\\\\\\change 2 in EYE:100, save it to TR3 EYEK901551, TR1 remember was already released for the auto-import testing.

Release the task in se09, and then release the TR from the UC document.

A BC-Sets is generated during the release of the transport request. So check always the task list release transport request log:

See in EYE:100 in /nscpr20 that BC-Set is created.

At this time you can see how in table /TMWFLOW/RTROBJT and /TMWFLOW/RFITCT OBJ_CATEGORIE is now 1- YELLOW:

Start Retrofit from the maintenance cycle task list shows this entry as YELLOW:

Select a retrofit transport request where to retrofit the new changes, select the TR2 created before in the implementation cycle, TR2 EYEK901547, as you are changing the same view entry:

Note: not all object are supported by BC Sets, please see Case 3. Manual retrofit will have to be used for this situation.

Later during the retrofit process with BC Set tool, the corresponding BC Set ZCHARM* will be activated and the changes will arrive into the retrofit system and objects will be recorded in the selected retrofit request in EYE101. After a successful import, the status of the request is set to Retrofitted automatically.

In the Start Retrofit select "Transfer with BC Set" or "Retrofit for All Categories"

The following pop ups will appear:

2.2. Workbench changes – SCWB tool

For workbench changes, since SCWB is adopted to carry out the automatic copy process, Retrofit could only support those objects which are supported by SCWB.

For every workbench (repository) request, Retrofit will check transport request object list and report non-supported objects (transport-critical objects) via the error messages in column “Critical Retrofit”.

As my test landscape is using the same system and different clients I cannot test this functionality, as the workbench changes are client independent.

I leave here the screenshots taken for my previous wiki page for Retrofit in 7.1 just for information. Screenshots are from Solman 7.1 system.

We have created function group ZDOLORES1 in Case 1 and we retrofitted it to SS7:100 using autoimport option, changes were saved in TR SS7K900451.

We are going to release this TR from the I* task list.

Note: when releasing the TR you can get an error saying that the package of this TR does not exists in SS7:100, create it and assign to transport layer ZSS7, at least I was not able to see the place where to change the package for this TR...

Then make a modification to this function group in the SS7:100 system and save the changes in TR1:

This will create a lock entry in /TMWFLOW/LOCK* too.

Now we will go to SMM:100 to make also changes to this function group. We save the change to TR2, release the task and later release the TR2 from the M*:

As the lock exists we will get the Yellow triangle in the Start Retro entry:

I release the TR in SMM:100 containing this change.

Call now start retrofit from the M* task list:

See that the lock is detected and Critical Retrofit is having a YELLOW triangle.

Go to see the objects:

Compare Source and Target System

In the FG in SS7:100 I cannot see the CHANGES!! Text because the TR1 is not released.

I retrofit TR2 to TR1, where the changes were done initially in the retrofit system:

Select “Retrofit for all Categories”. The following pop up will appear:

The mechanism of SCWB merge editor is to calculate the “delta” changes from the source transport request, and try to manipulate them in the target system’s same object. This requires the target system’s object to have the same version as the original version in the source system before the change is performed. Only in this way we can ensure all those “delta” can be handled correctly. Otherwise you might get a message saying not all changes can be copied.

Check the logs.

Changes arrived to SS7:100:

3. Manual Retrofit

If a conflict (lock entry) exists and the object is not supported by SCWB/BC Set, then we need to use Manual retrofit.

Objects with conflicts which have no support tool:

The objects included in the TR released in DV1 have been changed in the retrofit system DV2 so there is a lock entry for them in the Solman system.

In this case you cannot use retrofit tool to get your changes in the retrofit system. You need to do it manually RED. OBJECT_CATEGORIE= 4, TR_ERROR=4.

Check in /nSOBJ if a customizing object support BC sets, select the Object and then BC-Set compatibility.

4. Retrofit for mixed types of objects

When you have objects in the transport request with different categories please always Select “Retrofit for all Categories”

The objects that allows autoimport will be retrofitted via TOC and the objects already changed in the retrofit system will be retrofitted using tools like BC Set and SCWB.

5. Retrofit for non-ABAP objects

*NEW* Since SAP Solution Manager 7.2 SP08 the Automatic retrofit for non-ABAP Objects is supported.

For this functionality you need to enter in view above these retrofit parameters with X Paramater Active according to the non-ABAP Object you require:

- SCEN_FILE Enables the support for non-ABAP Objects in Retrofit. If active, the object type FILE will be set to manual processing.
- SCEN_HTA If active, SAP Hana Transports for ABAP (Object types HOTA / HOTO / HOTP) will be set to manual processing.

From a change document, normal change or urgent change you create a transport request.

Then you assign a non-ABAP object to a transport request. The R3TR FILE must be attached to the Workbench Request you created via the Transport Organizer.

Once the normal or urgent change moves from status In development to To be tested, if the transport request of this change document contains an object of type FILE you will get a popup asking if you want to change the retrofit from Manually to Automatic Import and click on Continue.

A transport of copies TOC will be created and exported. In the Start Retrofit you will see this TR as GREEN.

Categorization data will be changed to Automatic Import in table /TMWFLOW/RTRSCEN Retrofit objects for scenarios.

Note: Ensure that the user running the action in the Change document has S_RFC* trusted authorizations in the system where the transport request containing the change is created, usually the SolMan system.

Also, Retrofit allows non-ABAP objects because such object changes are stored in FILES and the FILE is attached to the transport request. Because of this, automatic retrofit is possible as no CSOL is possible for non-ABAP objects, even with this new feature in Retrofit.

Start Retrofit – Other functions

Solman 7.2 SP07:

Display Logs: This will display the retrofit logs.
Object List of Transport Request: This will display the list of the objects included in the transport request and the retrofit options.
Consistency check: System will check whether your selected request obeys release sequence to perform the Retrofit, and also whether there is a target request entered for it.
Display /Edit BC Set
Call TMS Alert Viewer
Reject Retrofit: In case you feel the change is not needed for the target system, there is another button “Change Retrofit Status” which can set the status to “Retrofit Rejected”.
Retrofit Manual
Create Retrofit Data Again: report RETRO_SERVICE_CREATE_RFIT_DATA: This will create the retrofit data again for the selected transport request. Note that the newest version of the relevant objects from the database will be used, this version could not be the same that the version of the objects when the original transport request was released.

Since SP12 we provide the Additional Function - Implement SAP Note to directly implement the SAP Notes in the retrofit system with only two manual steps.

Note: probably at this point you already noticed that for the objects with Green category the objects get imported into the production system one time from the maintenance cycle with the transport request created in DV1, and if the objects are retrofitted to DV2 and none change then in the project track, in DV2, this DV2 transport request is finally imported into the production system, I mean after the cutover the same objects versions are import a second time but the key point is that they are now imported as a part of the queue with transport requests from DV2 project changes.

There is not an issue to get the same objects imported “twice” into production system.

The same applies to the SAP Notes implemented first in DV1, retrofitted to DV2 and then imported as part of the DEV2 transports queue into the production system with the cutover.

The Focused Build extension Retrofit Automation provides an scenario that will allow you to create Transport of Copies as Retrofit Target, for transports without conflicts, the retrofitted objects are recorded into a ToC which is released and imported into the test system automatically.

Limitations

The retrofit for NON-ABAP (e.g. Java, Business Objects, HANA Content) is not supported until SP08.

Since SAP Solution Manager 7.2 SP08 the Automatic retrofit for non-ABAP Objects is supported.

For Business Warehouse objects: In spro activity "Define Values for Retrofit Scenarios" you can decide which BW objects need to be retrofitted always manually.

Authorization objects

Super user authorization object /TMWFLOW/A

Super user is allowed to:

Perform all categories at once
Ignore sequence violations
Place Transport in Import Buffer Again
Create Retrofit Data Again

Authorization object SM_CM_RFIT: Authorizations for SAP Change Request Management Retrofit

Retrofit tables 7.2

As soon as the retrofit data is generated when the source request is released, retrofit data will be entered in these tables:

/TMWFLOW/RFITCT is the Retrofit header table, it contains the information about source system, source request, target system and target request. Also it has the “TR _ERROR” which determines how it will be Retrofitted.

As a summary we can say that an object of a transport request can have these different categories:

- - TR_ERROR= 2: It can be an auto import object (Retrofit Category 2, color green): The object has not been touched in the Retrofit system and has no conflict in the Retrofit system
  - TR_ERROR= 1: It can be a retrofit object (Retrofit Category 1, color yellow): The object has been touched in the Retrofit system or has a conflict in the Retrofit system, but there is a tool supporting the Retrofit (SCWB or BC-Set)
  - TR_ERROR= 4: It can be a manual object (Retrofit Category 4, color red): Object does not fit into the above categories and has to be Retrofitted manually
  - Other TR_ERROR values indicates that the transport request contains objects with different categories, Enhanced Retrofit is able to determine the correct retrofit way automatically by executing “Retrofit for all Categories”.

In this table you will see also if the retrofit is done or not in RETROFIT_DONE .

/TMWFLOW/RTROBJT is the table to store the object level information from the source transport request. See OBJ_CATEGORIE value.

/TMWFLOW/TOCASNT is the table to store automatic ToC created for the source transport request in the case that objects get category 2, auto import.
/TMWFLOW/RTRSCEN Retrofit objects for scenarios

Other important tables:

/TMWFLOW/TRORD_N: Central Table ChaRM Transports
/TMWFLOW/LOCKPRN: CSOL table for Workbench requests
/TMWFLOW/LOCKPCN: CSOL table for Customizing requests
/TMWFLOW/PROJMAN: CTS-Project Relations
AIC_RELEASE_CYCL: Relation between Cycle, Tasklist and CRM-Document, Branch

Page tree

Purpose

Overview

Configuration

Step 1. Create the additional clients

Step 2. Create the test landscape in TMS

Key points

Configure transport routes and transport strategy

Stept 3. Create a domain link

Step 4. Create the RFC destinations for these clients in LMDB

Step 5. Check the ibase components

Step 6. Create the logical component group for these two landscapes

Step 7. Create a cycle for the maintenance landscape

Step 8. Create a cycle for the implementation landscape

Step 9. CSOL activation for the Retrofit system

Step 10. RFCs connections required for Retrofit

Retrofit Workflow

1. Auto Import

2. Semi-Automatic Retrofit with BC Sets or Correction Workbench (Note Assistant) - Standard retrofit

2.1. Customizing changes – BC Set tool

2.2. Workbench changes – SCWB tool

3. Manual Retrofit

4. Retrofit for mixed types of objects

5. Retrofit for non-ABAP objects

Start Retrofit – Other functions

Limitations

Authorization objects

Retrofit tables 7.2

Related Content

Related Documentation

Related Notes