Change Request Management scenario: Retrofit Functionality
Change Request Management scenario: Retrofit functionality
With the following steps you will be able to create a test landscape to practice with the Retrofit functionality in Solution Manager 7.0 EhP1 without creating interferences with real TMS landscapes.
Also I will try to give tips and tricks for the common mistakes in the configuration of this scenario.
If you are working in a Soluiton Manager 7.1 see SCN wiki page How to work with Change Request Management Enhanced Retrofit.
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 into 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:
It is essential that changes done in the maintenance landscape will also be applied to the development-implementation landscape. But the changes must not be imported directly with the transport requests because of inconsistencies between the objects of the two different landscapes. Instead of importing the transport request intelligent tools called ‘correction workbench’ and ‘BC Sets’ will be used.
The correction workbench will import an object into the target system, if it does not exist there or whenever it can find the exact position for the new parts of the object. For these cases it will lead to a green traffic light. If such a position cannot be identified, the new parts of the objects will not be imported, and a yellow traffic light will be set. For all objects which are not supported by the correction workbench, a red traffic light will be set.
The configurations given are valid for Solution Manager 7.0 EhP1 (SPS18) and above.
I will be working with the test scenario described in my previous SDN blog “First steps to work with Change Request Management scenario”
I will add to the previous landscape, Maintenance Landscape, also a Implementation Landscape in this way:
SMM:100->SMM:200->SMM:300 (Maintenance Landscape)
SMM:888->SMM:200->SMM:300 (Implementation Landscape)
For that I create a new client in my solman system:
I will run “Read System Data Remote” to refresh the system data in SMSY, after I will create the corresponding RFC connections for this client:
And also I will create two new logical components, one for the existing Maintenance landscape with a new system with role Retrofit:
And another logical component for the new Implementation landscape:
Create a maintenance project in transaction SOLAR_PROJECT_ADMIN.
Go to System Landscape tab -> Systems and assign these logical components. If not all of your systems appear in the project, push button ‘System Role Assignment’ and insert the new system role “Retrofit” there. Now you should see all systems of your logical components.
Explanation of role types:
D – Development System
O – Ongoing System
P – Production / target System
R – Retrofit System / Post processing System
For a general example:
1st LC: DEV impl (type D) -> QAS impl (type O) -> PRD impl (type P)
2nd LC: DEV maint (type D) -> QAS maint (type O) -> PRD maint (type P); DEV impl (type R)
Make sure that there transport routes are defined in the transaction STMS which link your developments system with the quality assurance systems (consolidation route) and your quality assurance systems with the production systems (delivery routes).
Create the IMG projects for both development systems:
Go to ‘Change Requests’ and mark ‘Activate Change Requests Management’. Save your project. Now press ‘Generate Task List’. When the task list is generated, you will be prompted to enter the task list. Do so and stay in this task list.
In the task list notice that you need to have two project tracks one per each source system and a Post-Processing System: Retrofit system
In the General Task there is a task called “Assignments of Postprocessing Systems to Development Systems”, if you execute it:
You can change the assignments at any time by starting this task again. Really you only need execute this if more than one post processing system exists.
Now unlock both your transport tracks by highlighting the line ‘Project Track <project name> Source System <system-client>’ and using the right mouse click.
Now is time to work as usual with your project and corrections, see SDN Blog “Change Request Management scenario: Working examples”
We are going to create some normal and urgent correction corrections:
1. Normal correction for a workbench change request:
SDMJ 8000001143->Created Workbench request SMMK900724->program ZTEST60
In the development system, create e new report and save it in a package which can be exported (no local object). Use the transport request for workbench you have just created.
2. Normal correction for a customizing change request:
SDMJ 8000001145->Created Customizing request SMMK900727
For customizing choose a customizing table and change an entry in this table. Save the changes in the transport request for customizing you have just created.
For example “Maintain Academic Titles”:
Proceed with your normal corrections as described up to the point that the transport orders are imported into quality system SMM:200, normal corrections in “Consolidated” status.
At this point you will see that the available actions are:
This step is the main connector to the retrofit process.
This step is only available if the overall process has reached the status Consolidated for a SDMJ.
3. Urgent correction for a workbench change request:
SDHJ 8000001147->Created Customizing request SMMK900730 ->program ZTEST61
4. Urgent correction for a customizing change request:
SDHJ 8000001149->Created Customizing request SMMK900732
Proceed with your urgent corrections as described up to the point that the transport orders are imported into quality system SMM:200 and urgent corrections in “Authorized for Import” status.
At this point you will see that the available actions are:
This step is the main connector to the retrofit process.
This step is only available if the overall process has reached the status “Authorized for Import” for SDHF.
If I select “Start Retrofit”:
The system will now calculate a number of possible retrofit systems, maintained in the retrofit customizing.
The result of this step is NONE, ONE or MORE systems.
– In case of NONE found systems the process will stop with an appropriate message.
– In case of ONE or MORE systems the system will prompt you with a list.
Please select one or more systems. This depends on your retrofit strategy.
Working from the task list M*
Now search the post-processing systems in your task list. Unlock the corresponding utmost task group via the right mouse-click.
In the following dialog you will see the transport request (which must be already released) of the System DEV maintenance which you created before. Choose this and enter. Now the changes of report which you created in DEV maintenance will be transported into DEV implementation and save to the transport request which you created in DEV implementation. You should see a green traffic light.
Internal retrofit preparations will fill the db table /tmwflow/rfitc:
Execution of Retrofit-Process
You will see a dialog which shows you the transport requests of system DEV maintenance. Assign a transport request from the retrofit system (DEV implementation) which will contain the changes of the post processing step.
Note: In order to be able to assign a transport request from the retrofit system, SMM:888 in our example, I created two SDMJ and two SDHF for development system SMM:888 for the same project and created the corresponding transport requests:
– Normal correction for a workbench change request:
SDMJ 8000001165->Created Workbench request SMMK900750
– Normal correction for a customizing change request:
SDMJ 8000001163->Created Customizing request SMMK900748
– Urgent correction for a workbench change request:
SDHJ 8000001169->Created Workbench request SMMK900754
– Urgent correction for a customizing change request:
SDHJ 8000001167->Created Customizing request SMMK900752
You could create corrections also for any other project that has the retrofit system like development system.
For a workbench change I get the two workbench transport request available:
For a customizing change I get the two customizing transport request available:
I continue working with Customizing request SMMK900727:
Mark the transport request of system DEV maintenance (where you’ve made the changes) and press Retrofit button:
For customizing request you should see following screens:
After activating the BC Set you get an activation log :
Close the screen with Exit shows the following dialog:
Decide if the retrofit is finished successful.
Note: You must allow repository changes for clients in which you would like to create BC Set for customizing changes. This is a purely prerequisite for BC Set.
This Z-BC Set is created in SMM:100 and also in SMM:888.
So, for a customizing request, we are using BC set functionality to transport the changes. That means, if the object in this request is not supported by BC set, then we will not be able to transport it. To check whether a object is supported by BC set or not call transaction /nSOBJ or see table OBJH for the object type.
Press DISPLAY to go to the next screen:
Select object you want to examine and double click on the selected object
Choose Button BC Set Compatibility:
On the selected TAB you can see all Activation Information for BC Set
As customizing changes are retrofitted via BC Set functionality, if BC Set functionality is no available for this object then Retrofit cannot transport it.
There is also a button call “list of transport critical Objects”, press this button and you’ll get all objects of all transports which are not able to retrofit it.
Another example for a role, object type ACGR:
So this object is not supported by BC Set functionality. If you try to retrofit such a transport request that contains this object you will get an error.
And in this case you have to manually transport those changes, there is no other solution.
On the other hand if the object is supported and still you get activation error, check if you have performed some deletion in this request but the deletion functionality has not been activated for BC set, activate the Deletion Functionality:
Start Transaction /nSCPR20 -> Open Menu Utilities-> Choose Menu Item “User Settings”
Choose Tab “Maint. Transaction” (see below):
Note: If you forgot to activate deletion functionality, then the retrofit will fail. In this case please activate deletion functionality and delete the old BC-set (and re-create it manually by following Charm name convention) to process again.
Or manually transport those changes without using Retrofit.
If Retrofit is approved by “Yes” the retrofit Status is updated on the central Database Table and the Retrofit-List will be refreshed after additional checks and the Transport Request which has been successfully retrofitted has the Retrofit-Status “Retrofitted”.
For workbench requests the Correction Workbench -> /nSCWB tool is used.
Note: In SCWB, one prerequisite is the object to be modified in the target system must have the same version as in the original system before the change. Otherwise it will not be able to locate the places for insertion/deletion/modification. That means for workbench request you could retrofit only once, because you can only copy the changes one time.
See a similar screen as followed:
Note: The Critical Retrofit indicates which transport requests contain objects which cannot be imported directly by the tools used because of:
(1) Object not found due to object check
Note: The concept of using Retrofit to transport workbench requests is to copy the changes in source system by comparing to its original version, and insert the same changes to the same object in target system. But there is a prerequisite to make sure the change can be copied correctly, that is at the time when you perform the Retrofit action, the object version in system MUST be identical to the original object version in system before you do the changes. Otherwise there maybe inconsistencies in the final objects in retrofit system.
(2) Object not supported for BC Set activation
(3) Object Type not supported in Correction Workbench
To prevent the processing of transport requests, e.g. because the change is no longer required, choose Change Retrofit Status. The status of the selected transport request in the overview changes to No Retrofit.
To flag transport requests which have not been processed by the retrofit process tools, as completed, choose Manually Retrofitted. The status of the selected transport request in the overview changes to Manually Retrofitted. If there are no other transport requests for processing, before this request, in the overview, transport requests with this statusare removed from the overview, to keep the list understandable.
Choose List Retrofit-Critical Objects to list all transport-critical transport objects, objects which cannot be retrofitted by the tools Retrofit uses (SCWB and BC Set Activation), so that you can process them manually. You can export the objects to the front-end PC in various formats, for further processing (e.g. manual retrofit of transport objects).
Choose Cancel to close the list and go back to the transport request overview for the selected retrofit system.
When you set the retrofit to completed successfully, the transport requests no longer appear in the transport request overview for the retrofit.
If you specify the retrofit as not having been completed successfully, the transport requests remains in the transport request overview for the retrofit, and continue to show the retrofit status Process Retrofit.
To leave the retrofit transport request window, choose End.
The task list overview appears.
Involved RFC Destinations
First time retrofit run creates these two RFC destinations, in our scenario:
In a real scenario:
1) RFC-Destination from Solution Manager to DEV-System of Maintenance landscape
2) RFC-Destination from Solution Manager to DEV-System of Implementation landscape
3) RFC-Destination from DEV-System of Maintenance to DEV-System of Implementation
4) RFC-Destination from DEV-System of Implementation to DEV-System of Maintenance
Process of Retrofit for Workbench (SCWB):
- Read RFC-DESTINATION (1) of DEV-Maint
- Call Function Module TMW_DO_RETROFIT_WB on Retrofit System (DEV-Impl)
- Create RFC-Destination (4) with Information of RFC-Destination of DEV-Maint. CWBADM_<SID>_<CLNT>
- ‘SCWB_APPLY_REFERENCE_CORR_NEW’ gets the information from DEV-Maint and stores it in the transport request of DEV-Impl.
Process of Retrofit for Workbench (BC-SET):
- Read RFC-DESTINATION (2) of DEV-Impl.
- Call Function Module TMW_DO_RETROFIT_CUS on Maintenance System
- Create RFC-Destination (3) with Information of RFC-Destination of DEV-Impl. RETRO_<SID>_<CLNT>
- Copies BC-Set from DEV-Maint. to Retrofit System (DEV-Impl.) and activates the BC-Set on the retrofit system.
For more information about RFC-Destination in Retrofit please have a look at the following note:
1175098 – Change Request Management retrofit configuration
Important things to take into account
– Authorization S_RFC_ADM is needed for all users because it allows the remote connection to the managed systems, also to users in READ and TMW RFC connections in client 000 of the managed systems.
– In general, the retrofit function is importing a transport request in a client, and therefore the import authorization is required also in the retrofit client. However, you distribute and, in particular, you import the transport requests in the Transport Management System (TMS).
For technical reasons, the remote-communication of the TMS always occurs using the 000 client of the target system.
Therefore, the TMS requires that the people responsible for the import (operators or administrators with import authorization) have a user in client 000 of the target systems.
Please find more details about this behaviour in the following note:
913232 – Users and authorizations are missing in client 000
– RFC Connection RETRO_<SID>_<CLNT> is only needed for BC Sets.
– RFC connection CWBADM_<SID>_<CLNT> is only needed for Workbench objects.
– Check the domain links in your landscape. Be sure that there exists an inter domain link between the two domains in which the development systems are configured in.
– If at this point you can not retrofit customizing requests, please check this note 1363546 “ARFC options for destination”, the root case might be the ARFC settings of TRUSTED RFC connections from SOLMAN system to managed systems that are incorrect, re-generate those RFC in SMSY and try again.
Notes implemented in our system in EhP1 before testing this funcionality:
1150335 Delivery information for retrofit
1371694 Retrofit: Wrong sort order in retrofit list
1317068 Retrofit extensions for managed systems
1363936 Focus on selected entry of retrofit list disappears
1353374 Object not found in module /TMWFLOW/TR_OBJECT_CHECK
1356984 Cross System Object Lock: Timeout in checking lock conflicts
1281812 Retrofit processed for records with status retrofitted
1242899 Cross-system object locking: Cutover scenario
1246877 Performance problems displaying retrofit list
1250430 Retrofit usability
1175098 Change Request Management retrofit configuration
996865 Tx SCPR20: Error SCPR 116 occurs during BC set activation
1044741 BC set deletions
1153253 Customizing distribution – deletions by BC set activation
Notes to be implemented in satellite systems
1040612 Retrofit function for satellite systems
1066123 Retrofit functions for satellite systems Customizing
1157393 Retrofit func. for systems w/ Basis Release 7.0 as of SP11
It can be found in:
Copy Changes -> Objects supported in list below
There will be important enhancement for Retrofit functionality for Solman 7.0 EhP2, I will try to update this blog as soon as this information is available.
Appendix A: Explanation of Retrofit-Functionalities (ALV-List and Buttons)
Working with filter buttons:
Filter value is “Retrofit Status”
“Retrofitted” or “Manually Retrofitted” green line
“Process Retrofit” yellow line
“Retrofit Rejected” red line
These Buttons are toggle buttons
Fade out -> hides the described values
Show -> displays the values again
Change the Retrofit Status
Select an entry and press button <Change Retrofit Status>. The colour of the entry changes to red and the Retrofit Status is set to Retrofit Rejected.
Select the entry once more and press button <Change Retrofit Status> again the Status is switched back to Process Retrofit. Only entries with status “Process Retrofit” are processible.
Change to Manually Retrofitted
If you have processed the objects of this transport request manually in the retrofit system you can set the status in the retrofit list manually by using this function.
Select an entry and press button <Manually Retrofitted>. The colour of the entry changes to green and the Retrofit Status is set to Manually Retrofitted.
Select the entry once more and press button < Manually Retrofitted > again the Status is switched back to Process Retrofit. Only entries with status “Process Retrofit” are processable.
Before you want to start the Retrofit process (post processing) you have the possibility to check weather the transport request is consistent or not. You can process the check by selecting an entry and use “Check Consistency” or click on the icon in column “Retrofit critical”
The following checks will be performed when using this function:
Note Check -> Objects determined from a note in transport request. This request contains objects from the import of a note. This can cause retrofit problems in the target system.
The target system can have a different release, with its own note.
The target system does not recognize the changes from the note, and ignores it because the attribute of the transport request get lost.
You should not import this transport request into the target system, to avoid these problems. Separate requests for notes and user changes (Workbench und Customizing).
No transport is selected for retrofit Request
Changes cannot be retrofitted without a target request. The request cannot be processed.
Assign a request to the selected entry, and repeat the procedure
Check the transport order -> The selection of this transport request does not obey the release sequence. This can cause inconsistencies and overwrite data because of overtakers (premature requests) or downgrades (subsequently importing old requests). Check and correct the selection, to avoid inconsistencies due to incorrect release sequence. This procedure is logged in a file
Possible order conflicts can appear:
There are transport requests found which have been processed by the selected transport request.
There are transport requests found which have not been processed by the selected transport request.
Combinations of the above cases.
Object Check -> Checks if the objects of the transport request can be handled with the tools the retrofit process is used (Correction Workbench and BC Set). This check can be ignored when you use the auto import functionality. The prerequisite is that the object is not changed in the target system (retrofit system)
The following cases prevent an automatic retrofit process:
Object not found due to object check
Object not supported for BC Set activation
Object Type not supported in Correction Workbench
Example: Check the consistency of transport order I2IK900560
Result: The outcome of this check will be displayed in a log below the retrofit list
Object-List for Transport Request
To get a detailed list of the Objects in a selected Transport Request mark an entry of the Retrofit-List and use Function “Object-List for Transport Request” or double-click on the entry you want to display.
Description of the Object-List:
Auto-Import: Corresponds to the Category “2” of the object entry and is green colored. Objects of this category will be transported automatically. That means the Object is not changed in the retrofit system and can be imported directly.
Retrofit: Corresponds to the Category “1” of the object entry and is yellow colored. The Objects of this category are changed in maintenance system and retrofit system and has to be processed by retrofit tools (Correction Workbench or BC Set Activation).
Manual: Corresponds to the Category “4” of the object entry and is red colored. Objects of this category are not supported by the retrofit process and have to handle by the customer.
Manual setting of Implementation Status
All entries in the Object List with category “4” (manual) can be set by customer on this display. Trying to change other entries as category “manual” is not allowed here because these entries will be set automatically by the auto import or retrofit process. The customer can make the following possible entries:
Implemented (Value “I”): The Object is processed manually in the retrofit system.
Not implemented (Value “N”): The Object is not processed in the retrofit system because it is not needed in the retrofit system or any other reasons from the customer.
Not processed (Value <SPACE>): This is the default Value. If one of the Objects of the Transport Request is not processed the retrofit process cannot complete this transport request, because all objects should has been processed.
Appendix B: Explanation of Object-List functionalities (Buttons)
Confirm & Save
A popup appears which indicates that data is not saved if you leave the display.
Cancel: Go back to the display.
No: Leave screen without saving data.
Yes: Save data and leave screen.
Saves the data to Database table and processes following Message:
Compare Source & Target System
Result of a compare of a customizing object
Result of a compare of a workbench object
A popup appears which indicates that data will be lost if you leave the display.
Cancel: Go back to the display.
No: Go back to the display.
Yes: No data will be saved and leave screen.
Before EhP1 this project definition was working: