Say what? That’s the most common reaction when I start talking about Standalone Retrofit. Not too many SAP customers are using this already. So it sounded like just the right thing for me to dig into, adventure awaits although it might be similar to playing pitfall and having huge pits (like hardcore mode) instead of what you would normally see. That's definitely something for me then.
So here goes … There is a scenario called standalone retrofit in SAP Solution Manager 7.2 which can be used when the customer in questions doesn’t want to do a complete Change Request Management implementation or when the customer is using something else (third party tool that claims to be able to do the same thing and cannot for example… just to name one example).
Standalone retrofit in a nutshell
Standalone retrofit is a “lean” way to still be able to use retrofit functionality to synchronize maintenance (development done on a maintenance line) into the project line so that when a project coming from the project line goes live into the maintenance line (your currently productive landscape), you don’t lose the maintenance that was done.
The goal is to automate this to a certain degree so it becomes less of an effort to do that synchronization compared to doing it manually.
The retrofit mechanism will determine if an object(object per object that is part of transport request) can be automatically imported into the development system of the project line (=green status =automation possible) or if the object needs to be compared (=yellow status =comparison & decision needed using SAP tools) or if the object needs to be synchronized manually (=red status =someone has to manually take care of it). This functionality is offered in an application then to help customers synchronize changes by classifying the changes and partially automating the synchronization.
More functionality (more automation) is available even as part of Focused Build, an additional solution that exists which can be installed on top of SAP Solution Manager 7.2.
Configuring standalone retrofit
The configuration steps can be found in below SAP note but still you need to have some a decent knowledge on CHARM + Retrofit and SolMan 7.2 in general to make sense of it all. Since customers ask me to meet up and discuss it doesn't seem to be as straight forward as I might think it is.
2488168 - Standalone Retrofit - SAP Solution Manager 7.2
You can try this out on a single SolMan system using multiple clients. That won’t simulate a real environment in the same way but at least you can do the configuration and check out the functionality that way.
If you want to try this out, ensure you follow each step and activate everything mentioned in the SAP note.
Below you can find some additional pointers to get started (again, you need a certain degree of up-front knowledge or my blog post will resemble a SAP book in the end).
So you need an actual landscape configuration, something like:
DEV -> QAS -> PRD (maintenance line) where DEV and QAS belong to maintenance branch and PRD belongs to production branch
DEV’ (at minimum, project line) where DEV’ belongs to development branch
The retrofit then goes from DEV to DEV’ to keep DEV’ in sync with the maintenance line.
So if you don’t have a development branch (to work in an artful way) you might need to create an additional branch in transaction soladm and insert your SolMan system / client combination in there as well to assign the project line development system in your solution.
You’ll need to create a change cycle + task list (some CHARM at work here) that matches the landscape you want to use in terms of retrofitting. So you also need RFC destinations configured to all involved systems and clients as well (as part of managed SAP system setup).
Cross System Object Locking (CSOL) is an essential part of this configuration and has to be in place and functioning for the project development system (at minimum, can also be done for both development systems). If not, it can already be the root cause why the scenario is not functioning.
In terms of confusion, the TMS domain pops up from a technical point of view and what is needed, in the end, is that both development systems DEV and DEV’ (maintenance and project line) are either part of the same TMS domain controller or that their TMS domains are linked as a prerequisite to make the scenario work.
Understanding the mapping
The scenario requires a little bit of Change Request Management configuration to have the technical aspects in place to be able to map a CTS IMG project (a IMG project which you can create in transaction SPRO_ADMIN which allows you to assign that project to a transport request. and later on filter on that project in the STMS import queue) and a task list of CHARM (which requires a change cycle as a prerequisite and has its own IMG project generated by CHARM). So you need to have a change cycle (whatever sort – continual, phase or release) to be able to use the scenario.
The mapping between the CTS IMG project and the CHARM IMG project can be done using a report that can be found in SOLMAN_SETUP under Change Request Management – Managed SAP system configuration. A report exists for either sides (maintenance & project) to be able to register released transport requests + their CTS IMG project into a table for use in this scenario. Once the mapping is in place, you can then just create transport requests (old school way via se01, release them via se01 as well) and the retrofit picks them up automatically.
This is really what standalone retrofit is about in fact. A developer can create a transport in SE01, using his / her known “CTS IMG project” as they are used to do (without CHARM) and this automatically gets “dropped” into the Retrofit scenario upon release. The retrofit has to be started via the task list.
Accessing the task list can be done in different ways, via the Administration Cockpit (under Change Control Management via Fiori Launchpad), via SM_CRM (CRM UI) or by saving the URL to the task list application in your browser favorites to directly access it (once you have been there). From there, the retrofit application gets called underneath the “post processing” system hierarchy. So you are not using CHARM as a full blown scenario with Change Documents and all that, you are just using “Retrofit” aka “Standalone Retrofit”.
Appendix: update frenzy = configuration gone wild
After updating SAP Solution Manager 7.2 SP3 where standalone retrofit was functioning to SAP Solution Manager 7.2 SP7, the scenario stopped working.
If you are not interested in troubleshooting steps, you can skip a whole bunch of lines and screenshots and go beyond this part and scroll down to the bottom.
HOWEVER, it does contain steps that might help you to better understand the scenario, so I would advise to keep on reading instead.
One of the issues was that my parameter setting according to SAP note 2488168 was changed.
There are numerous tables in use (find out more by looking up information about retrofit and standalone retrofit).
Table /TMWFLOW/CTS_MAP contains the mapping entries:
I want to check the CTS_ID_MAPPED so I use F4 input help on this field to check what’s inside the table
Not sure what happened here but it looks like I’ll need to take out black light to see what’s inside… Since I don’t have this lying around I go for another method of checking the table content. It’s almost like there is someone behind the scene, trying to trick me out of this but that’s probably just my imagination running wild. That happens from time to time.
I’ll just call all entries for a second. Troubleshooting this F4 input help is not for this time around.
Hiding some sensitive data here but you should normally see SID under SYS_NAME and SID_xxx each time for CTS_ID_REAL and CTS_ID_MAPPED
So what do you see here in this table? You basically see the mapping for both development systems. In source development (maintenance) = client 100 here, the mapping is like this and in the target development (project) = client 300 here, the mapping is like this.
CTS_ID_REAL = the ID of the CTS IMG project and the CTS_ID_MAPPED = CTS ID generated by CHARM which is related to release cycle stated in column RELEASE_CRM_ID and task list stated in column TASKLIST_ID.
This means if I create a transport request using CTS_ID_REAL SID_P00001 and I release it, it should show up in the retrofit pop-up (via start retrofit in task list I000000155).
Adding an entry in table BCOS_CUST:
Saving it into a transport request using that CTS IMG project:
What is really important now is CSOL locking. CSOL locking has to be active on both development systems so I need to ensure I have a CSOL lock for this entry.
I can verify this via the CSOL table (it can be accessed via the Administration Cockpit).
I can see here that my transport request has been registered in CSOL and I can also see that the mapping does it’s work because cycle/scenario matches the Change Cycle that is mapped against the CTS IMG project ID.
This is definitely fine. So far so good but somehow I know this is going to go wrong though at some point so it’s only half a cheer really. It’s a small yay, almost silent.
Now, if I release the transport request via SE01, it should perform a call and register the transport into the retrofit pop-up and also generate the retrofit data. This is not happening right now. No entry is coming into my retrofit pop-up so I’ll need to figure out why. First thing I want to know is, what does the system do when I release the transport request because this should be the spot where the registration into retrofit happens.
There are multiple ways of going about this.
I always try to start with what I consider to be least time consuming and what I hope is the fastest way to resolve the issue. Not that this always works out though but you have to have some kind of logic and flow behind it right.
I already noticed that the update to SP7 caused a number of changes in our system such as a parameter that was reset to default for standalone retrofit so it became inactive after the update. Just to name one thing so I figured out it probably cannot hurt to revisit all related steps in terms of configuration.
I knew the that standalone retrofit configuration is described in a SAP note since I used that previously to set up the scenario. So I start with searching “standalone retrofit” in SAP Support Portal because I know from the past in this case already there is a SAP note describing the configuration.
The first SAP note describes the configuration and has the pointers on how to activate standalone retrofit.
The second SAP note and the third SAP note are about a BADI Implementation for Standalone Retrofit for the managed SAP system. Now that sounds interesting since that can be a piece of code that is supposed to do what is no longer working in this case.
So I check the first note on the BADI implementation. I know that I had this implementation active before going to SP7 since the scenario was working properly and I’ve seen this SAP note before.
As you can see it is about CTS_EXPORT_FEEDBACK so it sounds like this will be the spot where the transport request is registered and the retrofit data gets generated.
The BADI can be checked via transaction SE18
In SE18, enter BAdI Name CTS_EXPORT_FEEDBACK
Then click on Enhancement Implementation – Overview – we need to find the RETRO_STANDALONE implementation for this BADI
There we have RETRO_STANDALONE in a blue color (that actually means it’s inactive). Double click on RETRO_STANDALONE.
After update to SP7, it’s inactive again apparently.
I did already open up a customer message. I do that when I expect that troubleshooting is going to be too time consuming and in this case I expected to find a bug really and not a BADI that was active that became inactive after the SP update.
I won’t be the only one to encounter this I suppose so I’ll update the SAP support message and they have a new entry in their solution database for the machine learning to pick up and use to help out other customers. No this is not fantasy, it’s something SAP is capable of doing.
So now to active, I click on Implementation – Change – Activate in the upper menu.
The activation requests a transport request so I again assign my CTS IMG project that is mapped for standalone retrofit.
Now that it is active, I can go and release this specific transport request and it should show up in my retrofit pop-up.
I’m pretty much convinced it is working now because if I check the export logs of TMS after releasing the transport I already see this when I look for “RETRO” in the log
I go to my task list (via administration cockpit or more direct even via URL I saved and kept)
Under my “post processing system” = system which is assigned as retrofit system in my cycle, I click on “Start Retrofit”.
And what do I see there J my transport request is registered and retrofit determined I’ll have to manually take care of the retrofit in this case. Retrofit can automate some retrofits based on the fact that the object is supported by the tools (SCWB / BC Set). If not, it’s a manual retrofit.
So we go for our initial example again (adding an entry to table BCOS_CUST) now with an entry in table BCOS_CUST and check this also still:
This also works properly now. You see a dependency next to a yellow status (yellow means it can be retrofitted using one of the tools). The dependency is there to avoid “overtaker” situations so it means another transport request has to be retrofitted first (I didn’t capture that one in the screenshot).
Another case closed. On to the next one.
Recap
To recap, standalone retrofit can enable you to retrofit using transport requests created via SE01 and released via SE01 (or other means) which do not seem directly connect to CHARM or do not require you to create and release them in CHARM due to the mapping that exists between the CTS IMG project and the CHARM based CTS IMG project.
This allows customers who don’t have a full CHARM implementation to still reap the benefits of being able to automate their Retrofitting using SAP Solution Manager.
So here goes … There is a scenario called standalone retrofit in SAP Solution Manager 7.2 which can be used when the customer in questions doesn’t want to do a complete Change Request Management implementation or when the customer is using something else (third party tool that claims to be able to do the same thing and cannot for example… just to name one example).
Standalone retrofit in a nutshell
Standalone retrofit is a “lean” way to still be able to use retrofit functionality to synchronize maintenance (development done on a maintenance line) into the project line so that when a project coming from the project line goes live into the maintenance line (your currently productive landscape), you don’t lose the maintenance that was done.
The goal is to automate this to a certain degree so it becomes less of an effort to do that synchronization compared to doing it manually.
The retrofit mechanism will determine if an object(object per object that is part of transport request) can be automatically imported into the development system of the project line (=green status =automation possible) or if the object needs to be compared (=yellow status =comparison & decision needed using SAP tools) or if the object needs to be synchronized manually (=red status =someone has to manually take care of it). This functionality is offered in an application then to help customers synchronize changes by classifying the changes and partially automating the synchronization.
More functionality (more automation) is available even as part of Focused Build, an additional solution that exists which can be installed on top of SAP Solution Manager 7.2.
Configuring standalone retrofit
The configuration steps can be found in below SAP note but still you need to have some a decent knowledge on CHARM + Retrofit and SolMan 7.2 in general to make sense of it all. Since customers ask me to meet up and discuss it doesn't seem to be as straight forward as I might think it is.
2488168 - Standalone Retrofit - SAP Solution Manager 7.2
You can try this out on a single SolMan system using multiple clients. That won’t simulate a real environment in the same way but at least you can do the configuration and check out the functionality that way.
If you want to try this out, ensure you follow each step and activate everything mentioned in the SAP note.
Below you can find some additional pointers to get started (again, you need a certain degree of up-front knowledge or my blog post will resemble a SAP book in the end).
So you need an actual landscape configuration, something like:
DEV -> QAS -> PRD (maintenance line) where DEV and QAS belong to maintenance branch and PRD belongs to production branch
DEV’ (at minimum, project line) where DEV’ belongs to development branch
The retrofit then goes from DEV to DEV’ to keep DEV’ in sync with the maintenance line.
So if you don’t have a development branch (to work in an artful way) you might need to create an additional branch in transaction soladm and insert your SolMan system / client combination in there as well to assign the project line development system in your solution.
You’ll need to create a change cycle + task list (some CHARM at work here) that matches the landscape you want to use in terms of retrofitting. So you also need RFC destinations configured to all involved systems and clients as well (as part of managed SAP system setup).
Cross System Object Locking (CSOL) is an essential part of this configuration and has to be in place and functioning for the project development system (at minimum, can also be done for both development systems). If not, it can already be the root cause why the scenario is not functioning.
In terms of confusion, the TMS domain pops up from a technical point of view and what is needed, in the end, is that both development systems DEV and DEV’ (maintenance and project line) are either part of the same TMS domain controller or that their TMS domains are linked as a prerequisite to make the scenario work.
Understanding the mapping
The scenario requires a little bit of Change Request Management configuration to have the technical aspects in place to be able to map a CTS IMG project (a IMG project which you can create in transaction SPRO_ADMIN which allows you to assign that project to a transport request. and later on filter on that project in the STMS import queue) and a task list of CHARM (which requires a change cycle as a prerequisite and has its own IMG project generated by CHARM). So you need to have a change cycle (whatever sort – continual, phase or release) to be able to use the scenario.
The mapping between the CTS IMG project and the CHARM IMG project can be done using a report that can be found in SOLMAN_SETUP under Change Request Management – Managed SAP system configuration. A report exists for either sides (maintenance & project) to be able to register released transport requests + their CTS IMG project into a table for use in this scenario. Once the mapping is in place, you can then just create transport requests (old school way via se01, release them via se01 as well) and the retrofit picks them up automatically.
This is really what standalone retrofit is about in fact. A developer can create a transport in SE01, using his / her known “CTS IMG project” as they are used to do (without CHARM) and this automatically gets “dropped” into the Retrofit scenario upon release. The retrofit has to be started via the task list.
Accessing the task list can be done in different ways, via the Administration Cockpit (under Change Control Management via Fiori Launchpad), via SM_CRM (CRM UI) or by saving the URL to the task list application in your browser favorites to directly access it (once you have been there). From there, the retrofit application gets called underneath the “post processing” system hierarchy. So you are not using CHARM as a full blown scenario with Change Documents and all that, you are just using “Retrofit” aka “Standalone Retrofit”.
Appendix: update frenzy = configuration gone wild
After updating SAP Solution Manager 7.2 SP3 where standalone retrofit was functioning to SAP Solution Manager 7.2 SP7, the scenario stopped working.
If you are not interested in troubleshooting steps, you can skip a whole bunch of lines and screenshots and go beyond this part and scroll down to the bottom.
HOWEVER, it does contain steps that might help you to better understand the scenario, so I would advise to keep on reading instead.
One of the issues was that my parameter setting according to SAP note 2488168 was changed.
There are numerous tables in use (find out more by looking up information about retrofit and standalone retrofit).
Table /TMWFLOW/CTS_MAP contains the mapping entries:
I want to check the CTS_ID_MAPPED so I use F4 input help on this field to check what’s inside the table
Not sure what happened here but it looks like I’ll need to take out black light to see what’s inside… Since I don’t have this lying around I go for another method of checking the table content. It’s almost like there is someone behind the scene, trying to trick me out of this but that’s probably just my imagination running wild. That happens from time to time.
I’ll just call all entries for a second. Troubleshooting this F4 input help is not for this time around.
Hiding some sensitive data here but you should normally see SID under SYS_NAME and SID_xxx each time for CTS_ID_REAL and CTS_ID_MAPPED
So what do you see here in this table? You basically see the mapping for both development systems. In source development (maintenance) = client 100 here, the mapping is like this and in the target development (project) = client 300 here, the mapping is like this.
CTS_ID_REAL = the ID of the CTS IMG project and the CTS_ID_MAPPED = CTS ID generated by CHARM which is related to release cycle stated in column RELEASE_CRM_ID and task list stated in column TASKLIST_ID.
This means if I create a transport request using CTS_ID_REAL SID_P00001 and I release it, it should show up in the retrofit pop-up (via start retrofit in task list I000000155).
Adding an entry in table BCOS_CUST:
Saving it into a transport request using that CTS IMG project:
What is really important now is CSOL locking. CSOL locking has to be active on both development systems so I need to ensure I have a CSOL lock for this entry.
I can verify this via the CSOL table (it can be accessed via the Administration Cockpit).
I can see here that my transport request has been registered in CSOL and I can also see that the mapping does it’s work because cycle/scenario matches the Change Cycle that is mapped against the CTS IMG project ID.
This is definitely fine. So far so good but somehow I know this is going to go wrong though at some point so it’s only half a cheer really. It’s a small yay, almost silent.
Now, if I release the transport request via SE01, it should perform a call and register the transport into the retrofit pop-up and also generate the retrofit data. This is not happening right now. No entry is coming into my retrofit pop-up so I’ll need to figure out why. First thing I want to know is, what does the system do when I release the transport request because this should be the spot where the registration into retrofit happens.
There are multiple ways of going about this.
- Read documentation on the standalone retrofit process and try to figure out what coding is called to perform this activity. You can do this in multiple ways. Look for relevant SAP notes and which code is in there (in correction instructions for example), check out information on SCN, try to find relevant information via Google, you name it, anything goes to check what programs or functions or extensions are being used in the scenario.
- If step 1 doesn’t get you the information you want or need, you can set up a trace on your own user-id in transaction ST12 to try to find out which coding is being called in an attempt to pinpoint more precisely where it goes wrong. Look for what sounds logical and try to locate the different steps from a time perspective.
- Use debug mode and step through to check what happens in the coding itself. You can do /h in the command input field to start debug mode and then perform the step where you suspect things go wrong and then step through the code (using F5). That way you can check the value of objects defined in the code and see what the system does. It can be very time consuming so it’s most of the times, my last resort.
I always try to start with what I consider to be least time consuming and what I hope is the fastest way to resolve the issue. Not that this always works out though but you have to have some kind of logic and flow behind it right.
I already noticed that the update to SP7 caused a number of changes in our system such as a parameter that was reset to default for standalone retrofit so it became inactive after the update. Just to name one thing so I figured out it probably cannot hurt to revisit all related steps in terms of configuration.
I knew the that standalone retrofit configuration is described in a SAP note since I used that previously to set up the scenario. So I start with searching “standalone retrofit” in SAP Support Portal because I know from the past in this case already there is a SAP note describing the configuration.
The first SAP note describes the configuration and has the pointers on how to activate standalone retrofit.
The second SAP note and the third SAP note are about a BADI Implementation for Standalone Retrofit for the managed SAP system. Now that sounds interesting since that can be a piece of code that is supposed to do what is no longer working in this case.
So I check the first note on the BADI implementation. I know that I had this implementation active before going to SP7 since the scenario was working properly and I’ve seen this SAP note before.
As you can see it is about CTS_EXPORT_FEEDBACK so it sounds like this will be the spot where the transport request is registered and the retrofit data gets generated.
The BADI can be checked via transaction SE18
In SE18, enter BAdI Name CTS_EXPORT_FEEDBACK
Then click on Enhancement Implementation – Overview – we need to find the RETRO_STANDALONE implementation for this BADI
There we have RETRO_STANDALONE in a blue color (that actually means it’s inactive). Double click on RETRO_STANDALONE.
After update to SP7, it’s inactive again apparently.
I did already open up a customer message. I do that when I expect that troubleshooting is going to be too time consuming and in this case I expected to find a bug really and not a BADI that was active that became inactive after the SP update.
I won’t be the only one to encounter this I suppose so I’ll update the SAP support message and they have a new entry in their solution database for the machine learning to pick up and use to help out other customers. No this is not fantasy, it’s something SAP is capable of doing.
So now to active, I click on Implementation – Change – Activate in the upper menu.
The activation requests a transport request so I again assign my CTS IMG project that is mapped for standalone retrofit.
Now that it is active, I can go and release this specific transport request and it should show up in my retrofit pop-up.
I’m pretty much convinced it is working now because if I check the export logs of TMS after releasing the transport I already see this when I look for “RETRO” in the log
I go to my task list (via administration cockpit or more direct even via URL I saved and kept)
Under my “post processing system” = system which is assigned as retrofit system in my cycle, I click on “Start Retrofit”.
And what do I see there J my transport request is registered and retrofit determined I’ll have to manually take care of the retrofit in this case. Retrofit can automate some retrofits based on the fact that the object is supported by the tools (SCWB / BC Set). If not, it’s a manual retrofit.
So we go for our initial example again (adding an entry to table BCOS_CUST) now with an entry in table BCOS_CUST and check this also still:
This also works properly now. You see a dependency next to a yellow status (yellow means it can be retrofitted using one of the tools). The dependency is there to avoid “overtaker” situations so it means another transport request has to be retrofitted first (I didn’t capture that one in the screenshot).
Another case closed. On to the next one.
Recap
To recap, standalone retrofit can enable you to retrofit using transport requests created via SE01 and released via SE01 (or other means) which do not seem directly connect to CHARM or do not require you to create and release them in CHARM due to the mapping that exists between the CTS IMG project and the CHARM based CTS IMG project.
This allows customers who don’t have a full CHARM implementation to still reap the benefits of being able to automate their Retrofitting using SAP Solution Manager.
- SAP Managed Tags:
9 Comments
