As described in the previous blog The Attack of the Clones: Episode 1 here I am to tell something more about the ways to manage the cloned objects during the upgrade projects.
Discover the cloned objects
Until two years ago, there were no standard tools to identify cloned programs, so, during the upgrade, the “upgrade man” discovered about their existence only in case of errors reported by Code Inspector.
In 2009, starting from an idea of Sergio Ferrari, my fellow and SAP Mentor Ivan Femia developed the ABAP program Clone Hunter that tried to match each custom ABAP object with a standard one comparing the report name; then it was enhanced with the comparison of used includes, data dictionary objects and the SLOC, the number of line of ABAP code.
After several postings in SDN about the upgrade, we began to share Sergio’s ideas directly with the Bjoern Panter @SAP which then included the SLOC in the “Similarity clone finder “, the @SAP CloneFinder.
The “Similarity clone finder” is new standard tool delivered by @SAP in the latest Solution Manager plug-in (e.g. ST-PI 2008_1); check out the report /SDF/CD_CUSTOM_CODE_CONNECT.
Let me summarize briefly some features of the @SAP CloneFinder
- Determines the similarity degree finding also copy&pasted source code
- Evaluation against SLOC size, business areas and integration
- Versioning of custom code
- Inheritage chains
- Direct split screen editor feature to merge clone differences
The release of this new tool by SAP allows you to have a glance of the clones since the assessment phase, that is, when analyzing a system to evaluate the impacts on the applications and the effort required to implement the release upgrades.
More info about the clone finder could be found in the SAP marketplace under Upgradetools.
The challenge of the cloned programs adjustment
Refreshing many clones could be a nightmare, because you have to look at each time to the differences between the new standard, the old standard and the cloned program.
Unfortunately the “Clones adjustment for Dummies” guide doesn’t exist, so in the next slide I tried to summarize some of the most important steps of the adjustment of the cloned program.
The effort needed to adjust the cloned programs is unknown; each program is different from the others and for this reason the time needed to analyze and adjust a single cloned program it might be really different.
It’s a very hard work, in short… it’s a real fight!
However, since the tests play an important role in an upgrade project, then the accuracy of the adjustment made to the cloned objects it depends on the results.
Lesson Learned – Clones: How to avoid them?
The best way to avoid the creation of clones (with a lot of work at every upgrade ) could be that, the adjustment of the clones during the upgrade should be carried out by the creator of the clones ;-).
Unfortunately dreams do not come true so we should consider some important options in order to avoid the creation of a cloned program that are
- The Enhancement Points
- Standard modifications whenever the Enhancement Points cannot be used
- In case of development estimation based on clone, add also the effort needed to perform the adjustment during the next upgrade
In my experience I noticed that, during the upgrade, the time taken for the refresh of a clone, usually, is greater than the time required to change the new standard program, so in my opinion, it’s better to change the standard one.
What about your feelings?
I would like to thank Sergio Ferrari for giving me the inspiration to write this blog series.