Retrofit: How to perform retrofit from an End-User perspective
…or: How the hell do I do it?
by: Hannes Kerber, SAP Active Global Support, ALM RIG EMEA
Today it is end-user time!
Many questions and discussions came up during the last years on the topic on how to really perform retrofit activities successfully. That means for all the ways which are out there, checking error messages, typical pitfalls and so on and so on.
With this blog post I would like to cover a simple “Story Board” on what actually needs to be done. That means how do I proceed step by step during a retrofit activity.
So, how to start. In the retrofit there can occur different cases in terms of how to perform the retrofit for particular transports and objects based on the conflict calculation which has been performed automatically by the tool.
The following steps have to be performed in any case and are the basic foundation
- Locate your transport
- Check Column “Critical Retrofit”
- Check Column “Sequence Dependency”
- Select a target request
- Make a decision on how to perform the retrofit (based on the checks)
- Perform the retrofit
(click on pictures to enlarge)
Step 1: Locate your transport
Step 2: Check Column “Critical Retrofit”
Step 3: Check Column Sequence Dependency”
AND
Step 4: Select a target request
Step 5: Make a decision on how to perform the retrofit (based on the checks)
Step 6: Perform the retrofit
So, everything is prepared now and the retrofit can be executed. There are now different possibilities:
a. Automatic Import
This is the easy part. Just press the button Auto-Import, confirm the popup that you are sure about the execution and you are done.
b. Retrofit with the SCWB (Correction Workbench
c. Retrofit with BC-Sets
Error Resolution and Log Access
All the logs can be directly accessed from the tool and necessary actions can take place. To access the logs for a particular transport you can proceed as outlined below:
There is one last question to answer: What does the conflict detection in retrofit mean, how is it perform and what do the colors mean? How does this affect my retrofit?
We have learned what to do and how to interpret the colors. But how do these scenarios occur? Please find an explanation below:
The important take away of the last picture is but below the picture in blue:
The generated Transport of Copies can be only a partial copy – it is not “ALL or NOTHING”, but a partial approach to automate as much as possible
Hope this helps in the daily operations and/or for training.
Cheers,
Hannes
___________________________________________
In the next blog post I will cover the more strategic aspects of retrofit. This means:
- Who is responsible for the execution of the retrofit?
- What does this mean for my tool setup?
- What is the right time to perform retrofit? Are there different strategies?
- Do specific guidelines exist?
- What are generic rules I can apply to my synchronization process?
- What impact does retrofit have on my release landscape?
- Is testing impacted?
- Is cutover to BAU/Maintenance/Production Support affected?
- How can I setup a governance and reporting process around retrofit?
Hi Hannes,
Thank you for sharing.
I am looking forward to reading your answer of question 3 -
"What is the right time to perform retrofit? Are there different strategies?"
because the customers where I implemented ChaRM with Retrofit always asked me to change the standard condition for action "Start Retrofit" to allow it only after "Imported into Production" and not after "Authorized for Production". Before using Retrofit in ChaRM, this was the moment when they used to run retrofit: after changes are really implemented. I would like to hear more about the SAP strategy for that, why it was decided to set it up like that.
Best regards,
Raquel
Hi Raquel:
This is a late reply, but it may help other colleagues. The answer can be found in
http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/08/18/strategic-aspects-of-retrofit
Thanks Hannes, again.
Juan
Hi Hannes.
Many thanks for your blog. Very useful.
One question: What do you do with the retrofitted transport in the case you have:
Maintenance:
DV1->QA1->PRD
Implementation:
DV2->QA2->DV1->QA1->PRD
The retrofitted transport will go into QA2 eventually, from DV2, but how do you stop that transport from going beyond there, I mean, to your Production system "again" if STMS has been setup still to deliver your implementation project from DV2>QA2>DV1>QA1>PR1?
Let me explain what I mean with "again". The moved object(s) correspond to an urgent change to PRD via DV1>QA1>PRD, which are then retrofitted into DV2>QA2. Let's supposed it is a green retrofit with no impact on the current project, but still a transport is created in DV2 as part of the retrofit.
Is that retrofitted transport supposed to go again to PRD or is it supposed to stop in QA2. If the latter, then how do you stop it? One wat may be to use DV2>QA2>VIR, but since VIR <> PRD, then CSOL may not work as for CSOL to work, the production systems must be the same between the logical components being used.
Thanks and hopefully you or some other colleague may have the time to clarify.
For me the transport is supposed to die in QA2, but some colleagues have the opinion it should go to PRD together with the implementation project when cutover happens. For me that it too risky as you could have many live projects and you will be transporting more of the same to PRD, probably out of sync.
Thanks,
Juan
Hello, Juan.
The same question does not give me sleep.
Have you found some best practise for retrofit scenario?
BR,
Artem
Hi Artem:
Some organizations decide to terminate the retrofit part in QA2, not bothering on promoting transports further than that. We dare to mention that this approach may be used by small organizations with no frequent implementation projects.
Bigger organizations that do major implementations every year, take any retrofitted/received transport, making it part of an active implementation project that will eventually go all the way to DV1>QA1> PRD. We believe that with this approach it is guaranteed the integrity of the system everywhere almost at anytime. Also, if the company is using CSOL and DGP, it is mandatory that transports reach Production so that locked entries that may exist in /TMWFLOW/LOCKMON, are removed. That only happens after a transport reached Production.
In my case, we are not big, but we decided to behave like one.
Regards,
Juan
Thank you for your reply, Juan.
So do you mean that for implementation project we should have landscape like DEV2>QUA2>DEV1>QUA1>PRD or there is some other opportunity to cutover from implementation to maintenance without losing change tracking and consistency?
BR,
Artem
Hi Artem:
Working with SAP for years there are usually 3 different ways minimum of doing something there.
One way we use and we know is the one briefly explained. The cutover part related to the transports has worked for us this way: After QA2, we add all the project transports to the import buffers of DEV1, QA1, and PRD at the very same time. We apply them first to DEV1, where conflicts are resolved with complementary transports originated in DEV1. Our implementation project going live, will have the project's transports and immediately after the fixes created in DEV1. Those fixed will be eventually retrofitted to DEV2...
Another way is the relocation of transports. All implementation project transports are relocated to DEV1 where you build to huge transports: a workbench and a customizing one. Your project going live will consist of those 2 transports plus any complementary fixes you may need to create also in DEV1. With this relocation, you need to define which of your DEVs is the owner of the customer objects. You may need to dig more about it.
In those two scenarios, followed properly, you should not loose tracking and/or consistency.
Regards,
Juan
If we just add all TRs from implementation project (DEV2, QUA2) to import buffer of maintenance (DEV1) we can have downgrade.
For example, we make some change to object A in DEV1 and retrofit it in DEV2. Now we will have A /version 1/ in both DEV systems.
Then we change object A in DEV1 again (version 2). And before developer retrofit A /version 2/ to DEV2 some other developer will cutover (put in import buffer of DEV1) A /version 1/ from implementation project to maintenance.
So if the second developer will import A /version 1/ in DEV1 - an older /version 1/ will replace the actual /version 2/. And there will not be any DGP import conflicts - because only "cutover" transport requests are put in import buffer of DEV1 system.
How do you struggle with such situations?
BR,
Artem
If you enable Downgrade Protection, that will cover your back. There is an excellent wiki recently written by Dolores Correa about it. She also references Central System Object Locking there, as well.
https://wiki.scn.sap.com/wiki/display/SM/How+to+work+with+Change+Request+Management+Downgrade+Protection+DGP
It is not the perfect world, but you may get the best of it.
Regards,
Juan
We are using DGP but I can't test how does it cope with cutover 🙂
As I know DPG can catch import conflicts (predecessor and imminent) between transport requests that are in import buffer of a target sysytem.
When you change and object during maintenance in DEV1 system - it will be located in import buffer of QUA1 and later in PRD. But you will not have this request in import buffer of DEV1.
Import buffer of DEV1 will contain only transports from implementation landscape (DEV2>QUA2).
Am I wrong?
BR,
Artem
You are correct. Without getting into specific details, import buffer of DEV1 should only have transports from the implementation project (DEV2).
Regards,
Juan
Hello,
This is a very useful blog.
I have set up Retrofit as well, but I am having an issue...
Would you be able to help on the topic? Retrofit: not possible to start (Retrofit Entry Loced by user - /TMWFLOW/RETRO_EXT102)