Keep your custom code in sync on all systems

The biggest challenge of custom code in a distributed system landscape is keeping the code up to date in all e.g. connected productive systems spread around the world. If you are following one of the basic principles of the development guidelines you will have only one single development system for a solution like SAP ERP.

This single code base will be enriched of time with enhancements, bug fixes and new features. In the deployment phase you are able to use tools like SAP ChaRM to transport the content of the new custom code release to all depending quality systems for testing of for the final shipment to all productive systems. If the number of linked systems is higher than three, it might become a challenge to check all transports of correctness. Furthermore if local or regional development systems or project development system are used in the landscape the risk of an potential impact of a changed custom code object will increase.

The code sync between a 5 system landscape with project and pre-production system can be managed with tools like SAP Enhanced Retrofit. With a delta code logic changes from a project system will be merged back to the origin maintenance development system.

But all this control will not give you 100% security, because you control the process and not the content. So the best way would be a 2-way cross system code compare with an easy to use UI. If you spent already some time with SAP Custom Code Management and the related tools there is one tool called SAP Clonefinder. The goal of this tool was to detect clones of SAP code in customer namespace. The detection algorithm behind is fast and efficient. Customers asked us if it wouldn’t be possible to reuse the clone detection for a simple code comparison.

So let’s start with the tool available in all systems in software layer ST-PI. The needed authorization role is SAP_CCA_ALL.

Start the tool with transaction code /SDF/CD_CCA or the human friendly transaction code CCAPPS.

And select the activity “Custom Code remote Compare”

In the next screen you see the overall UI frontend.

In the upper part of the screen you have the customer object selection. This is either a generic filter by name wildcards or you can load piecelists with objects or transport lists. Under customer namespace the tool will try to detect all customer namespace automatically. Use the F4 help to remove unwished elements or add undetected namespaces.

In the field package you have the possibility to limit the code object selection to defined packages either with the multi select-options or any kind of wildcards. In case you have several core development packages like Z_CORE_1, Z_CORE-2,…. use the wildcard Z_CORE*. All custom code objects of these customer development packages will be analyzed.

The third selection option is the type of code object. Only pure ABAP code objects are supported. DDIC will not be analyzed because DDIC will need a  different comparison logic and a mismatch of a changed DDIC will always lead to a generation error in the transport. So it will be remarked earlier in a different process.

The object types supported are Classes, Function Modules, Programs, Includes, Webdynpros and some special types. With object names in combination with wildcards or the select-options and special naming patterns can be selected. If you start the analysis without any change of the selection parameters all custom code objects from the source system will be analyzed. Such huge analysis need some time and the amount of objects is not easy to be selected with the given options. So piecelists and transports can be an additional selection option. The difference of these 2 types is the piecelist is a static lists of code objects. New or deleted objects on the ABAP repository will not update the piecelist. The elements of the piecelist will have the source code version of the latest available. means the current and newest code will be used. Using elements of a transport the result list will display 2 result lines per object. One for the latest available code version and one for the version of the transport. Sounds complex but is easy to understand if you work with the result list.

Please remark all entered options will be combined with an AND operator like usual in SAP.

Now we have selected the amount of custom code objects to be compared with one or many target systems. Target systems will be linked via Remote Function Calls. 

Use the multi selection-option for the field RFC Destination to select as many target system as needed.

We recommend here to start the tool from a development system and select here the RFC destinations for the corresponding quality and productive systems.

And this was all up to now. Just execute the analysis with F8 and wait until the result is available. For experts you can save the result in a persistency, run the report in background, save a selection variant for later reuse or use own preconfigured output layouts.

As soon as the system comes back with an ALV result list, you will have the following result.

The selection was made for all objects in a customer development package.

The result list shows a perfect example. All my three custom code objects are 100% identical compared with the systems behind the RFC destinations.

Because we are not interested to see the identical objects just put a filter on the column Reference and focus on the unequal objects. If you save your filter under a layout this can be directly reused in the starting screen under output. next time identical objects will not be listed anymore.

The next example demonstrate what happens if the object is not yet available in the target system.

The selection was made using a piecelist.

Object not available in a target system will be indicated with “Object not found”.

The next screen is a special result. Details how to create it will be explained later on.

In this case a transport was used. As learned in a previous chapter now the version of coding in the transport will be analyzed and additionally the newest version as part of a piecelist. Lets’ focus here on the first object LSETBF10. We can see that the coding is very different in the both target systems. In Y57 you will have also the information about the valid active transport version. If you click in the corresponding line on the icon FUNC a split screen editor will display the differences.

On the left side the code version from the source system either the current code or the code version from the version history. On the right side the code from the target system. In this case an indicator the target system received a kind a cross transport or a modification.

If you click on the name of the object, the ABAP workbench will open the code editor.

If you click on the number column VERSIONS in every row a very cool feature will open. The tool will scan all historical versions of the code objects and will try to find out which historical version fits to the target system version.

In the given example the version in the target system fits to the current latest version of the development system. Also here using the compare feature you can also see what was the difference to an older version.

Exporting the list to an Excel spreadsheet, you can use the pivot capabilities to create nice tables or bar charts.

But at the end you will have an fast and easy tool to analyze code differences in cross system landscapes.

But where is the the 2-way comparison? If you start the same tool form a target system against the central development system you will be able to find out which objects have a difference. It is also possible to compare different target systems to check local developments or modifications.

If you have further questions please don’t hesitate to contact me.