Test System Refresh – Focused Build Standalone Extensions Part 4
In this blog series, I would like to describe a few standalone enhancements in more detail, which can be very helpful in unique situations and can be used independently from the requirements to deploy process from Focused Build.
In this fourth part, I want to introduce you to a standalone enhancement which is named Test System Refresh and is particularly useful for you when you have implemented or plan to implement Change Request Management with SAP Solution Manager.
The Challenge
To get meaningful test results in your test systems there a strong demand to refresh the test systems on a regular basis or at least before huge releases are tested. In many cases, these refreshes have to be applied multiple times to the test system, and every time the test system is reset to a baseline that doesn’t include the new developments and changes that had been applied to the test system before and not yet imported to the reference system (usually production).
Refreshing a system is, therefore, a ubiquitous basis task but often needs several days to complete with all the different post activities. One of these typically complicated and time-consuming tasks is to control all import logs and reapply all the required transports to the test system that are needed to continue with the next test phase.
Test System Refresh
This new Standalone Extension can be used to automate the calculation and import of missing transports into a refreshed test system.
Therefore, a new Task is added to the task list for each change cycle.
For a Test System Refresh you will then follow these steps:
- first, call the ‘Refresh’ task in the task list to calculate the delta between the current system and reference system
- do the actual system copy with your standard tools outside of SAP Solution Manager
- start the ‘Refresh’ task again, now to apply all missing transports to the test system
The delta is calculated based on the transport tracking information that is stored in the SAP Solution Manager. All the imported transport requests are compared between the two systems and transports not imported to the reference system of the refresh are added to the delta list automatically.
When re-applying the transports, they are automatically added to the queue of the refreshed system and then imported.
This function will reduce the post-refresh actives therefore and make the system available faster. Your tester will start testing sooner. Your basis team hast less effort for a system refresh and can do them more often to get better test environments and therefore better test results.
If you are looking for more information about Focused Build and other Focused Solution’s look at these Resources.
Other Articles of this Series:
- Cross Landscape Distribution – Focused Build Standalone Extensions Part 1
- Repack – Focused Build Standalone Extensions Part 2
- Simple IT Request – Focused Build Standalone Extensions Part 3
- Test System Refresh – Focused Build Standalone Extensions Part 4
- Release Batch Import – Focused Build Standalone Extensions Part 5
- Cut-Over Checks & Activities – Focused Build Standalone Extensions Part 6 (coming soon)
Hi, thanks for the blog.
Despite the question why this little feature was hidden in a turnkey solution for agile development with costs instead of being part of the standard, I would like to point to a weakness of this solution.
Because the refresh of the QA system from production is a good opportunity to get rid of dead developments.
In an ideal world we are all Michelangelos who “see” the figure in the marble block, whack off the superfluous marble and put the finished statue into production to have it admired for the rest of time.
Sadly we are in the real world and our departments, despite all official planning, work by trial&error; I have seen several developments which were dismissed after business department tested it in the QA system and told us, sorry, this is not what we want or need. Away with it. (I hope you will not believe that our departments will loose time reverting the withdrawn changes and, well-behaving, will transport both, change and deletion, to production – Homeric laughter :-] :-] :-])
For this clean-up opportunity we have implemented a very simple rule for system copies P->Q. Just before the copy we force all developments to go to production OR to go back into development (and eventually withdraw the obsolete change document).
No change documents shall stay in status ToBeTested during a refresh from the production system!
After the system copy P->Q we back up the import queue of the old QA system and simply replace it with the import queue of the source production system. Now database and import queue are in sync. Then we mass-import all transport requests which were in the status ToBeImported(again). Result: We have a refreshed, new QA system with all delta imports in place.
This works very good with the standard ChaRM usage of Transport of Copies (ToC) for the functional testing. A ToC into the consolidation system (QA system) will not insert an import selection into the import queue of the delivery system (productive system). Only the import of the “real” transport request will do this. This means that all import selection of the import queue of the production system are a consequence of the import into the old QA system which happened when a change reached the status TestedOK, while changes not yet TestedOK and their ToCs will be no more part of the new QA system. Changes which have to be withdrawn will disappear from the new QA system as desired, while changes still in development will go to the new QA system with the next status change ToBeTested.
To have the same Alzheimer functionality in the stand alone feature “Refresh Test System” which got lost in the focused solution we probably (I have only the guide) will have to implement the BAdI /SALM/RTS_FILTER_DELTA_BADI to introduce a filtering by change document status.
Setting everything back to Development or forward to Production is a valid approach to making sure that the copy contains all the required data or gets it afterward. This is, in fact, my standard recommendation for most customers.
But this solution does not scale very well when you have to manage a few hundred or more change tickets. You either need to adjust the status schema or you will have to manually set each ticket back to "to be tested" afterward. There is no way to automatically select tickets that have been there before. This automation is provided by this enhancement on the transport level although not on change level.
Interesting, that is a nice idea. You mean to add a new status “Waiting for System Copy” (feel free to hint some better label ? ) which will have the same order number as the status E0002 “In Development” in the ChaRM Status Attribute customizing and which the responsible developer / change manager can set alternatively to “In Development” as I mentioned in our solution, so that after the system copy we can use the service report to set all change documents back into “ToBeTested” in one shot by selecting this dedicated status with the action "Set next status".
Nice idea.
Btw. the scaling is ok for us; the revert back from ToBeTested action is also a good occasion for some house keeping, I mean the withdrawal of improvement changes we tried to realize but never found time (staff cost savings, staff cost savings!) to finish…
I miss also a simple function for this in the SAP Standard, any other Tool have this, for example:
https://www.galileo-group.de/en/products/conigma-qcopy.html
I used before any other Tools from Basis Technology, Realtech and Conigma....but now the company i work for it like to use only ChaRM. The result, many consultants, implement so many SAP Notes and ...
Actually we have 7.2 SP8, but when i take a look back, all features you already have, 10 years back with the third party tools and they are running well.
Hi,
Thanks for the blog. How can we use this functionality in use cycle.
Best Reagrds,
Vinod
Hi Stefan,
This works perfectly with non cCTS setup.We have now moved to cCTS based system, can this tool works with cCTS cycles?
Thanks & BR,
Vinod Bhat
Hello Vinod,
likly not. All standalone Enhancement support only normale CTS. In some cases CTS+ might work. But cCTS likly not , it is definitly not developed and tested on cCTS Landscapes and there is no official Support.
kind regards
Stefan