Retrofit: How am I and what is supported?
…or: How much can the retrofit automate my dual landscape synchronization process?
by: Hannes Kerber, SAP Active Global Support, ALM RIG EMEA
There is One Question I receive quite regurlarly, surely put in different ways, but in the end leading to more or less the same answer:
– Can the retrofit automate my whole process?
– What are the limitations?
– Where is the list of supported objects?
Therefore I would like to cover the following topics in this post:
– supportability on different levels
– automation on different levels
– what do the numbers say – how much money can I save?
– is there more automation?
Additionally there exists the perception that there are general major limitations in the retrofit tool which are not clearly communicated or cannot be found anywhere, but simply by a trial-and-error method.
In general I can say: There is no general limitation for the retrofit tool in SAP Solution Manager in terms of supportability and there is no list of supported and not supported object types – neither for customizing, nor for workbench!
But let’s take one step back: I ask the important question in the title of this post. How does the tool in fact support me? For this it is important to understand that this is happening on different levels:
Retrofit – Supportability on different Levels
Worklist Level – Ensure that all relevant changes are synchronized (full visibility and traceability)
- The tool automatically provides a worklist
- Additional information is available (such as Change ID, Sequence Dependency, Conflict Status, transport details)
Conflict Detection Level – Provides information on conflict status
- The tool automatically detects if the same content has been changed on the 2 involved development systems
- Detect Conflicts for Workbench and Customizing Objects (Key/Table Entry Level)
- Visibility on UI: Aggregated Transport Level View, Single Object View
Actual Synchronization – Automate the Retrofit with the tool
- Automatic synchronization via ToC
- Tool Support in conflict case where applicable, Manual Retrofit and Status tracking
So, what does this mean in terms of supportability? First of all, it depends on the level we are looking at, secondly it depends on the conflict status of an object.
In general we can say: All transportable ABAP and Customizing Objects are supported for retrofit, this includes also fully automated retrofit execution in case there is no conflict. In case of a conflict a tool support is still valid and fully supported, e.g. from the worklist level, you actually see that there is a conflict and you can track the changes. And for some of the object types, repository and customizing, there might be tool support for execution through SCWB and BC-Sets. The supportability depends on the object type here (SCWB in general supports objects which are supported via the Note Assistant as well, BC-Sets compatibility can also manually be checked via the system in TA-Code SOBJ, but needs to be performed for every customizing object and a standard ERP installation roughly has 65000 different ones…). The retrofit performs this compatibility check automatically of course and indicates it for each object in a transports (so a little more automation here as well).
We have to be careful with some execeptions in this general statement. In the area of BW for example exist some specifc object types, where conflict detection and automated postprocessing of retrofit are impacted (please get in touch with SAP on more details), but these can be handled as well. It does not mean BW is not supported, in fact it works like any other scenario, but some special attention and extension configuration needs to happen.
Retrofit: Automation on Different Levels
So the next thing which becomes interesting is the question of automation. In fact this is the most interesting part of the discussion because here it is really about saving time and money in the end and as much as possible should be automated. But I think also here we should take a look at the topic of automation on different levels. So what is it that I get automatically:
Again we will find 3 levels:
- Tracking and Analysis ensures that I know what and how to synchronize and retrofit between my systems
- Executions ensures that the actual content transfer and replication works automatically
- Post Processing makes sure I have consistent information and content throughout the entire landscape
This is further supported if we take a look at complete retrofit process from a technical point of view which also outlines these 3 main steps (which run automatically):
Retrofit: Numbers and Figures:
So, in the end, whenever we talk about automation, supportability etc. we like to relate all this to numbers. Meaning saved effort, man days, saved money etc. The experience from customers shows that we can reach an automation rate in the retrofit of up to 90%. What can we calculate out of this? It is often very hard to relate numbers to that. But just imagine you save 30 minutes on average per transport, which is easily needed to look for all the changes made, copy them to the target system, making sure to not overwrite something there, test that the changes activate…and there are some more tasks. With this you can make an easy calculation.
Additionally you of course are much less prone to manual errors and ensure a much higher level of consistency and compliance as well as documentation than with a complete manual double maintenance process.
Are there ways for further automating the process?
Actually there are – in customer projects it is being evaluated the possibility to execute all retrofit activities automatically in a background job, w/o any user interaction. Of course providing logging as usual, setting status, sending notification emails…