Namespace Refactoring in ABAP

Refactoring to other namespaces

In the past few years, I was involved in several projects which required moving an existing ABAP application to a new namespace. There might be several reasons for that, but in most of the cases an application that has been formerly written in Z*-Namespace needed to be moved to an SAP partner or customer namespace which starts with “/”.

As of 7.02, SAP provides no automatic solution to do a namespace refactoring, however, with the right tools and some experience you will be able to convert at least the most important development objects in a semi-automatic way.

Development objects in scope

This blog post deals with the conversion of

• DDIC-Objects: domains, data elements, structures, tables, table types, views and F4-Helps
• Report sources: reports, function groups, classes
• UI components: Dynpros and Webdynpro components

Tools

For a namespace refactoring you need the following tools:

• Advanced Find and Replace
• Notepad++
• SAPLink with installed plugins

Get on overview of the object list

Before you start, figure out, which packages are involved in the application you would like to convert.

Get a complete list of all development objects that need to be converted either by selecting the objects from TADIR table (provide attribute DEVCLASS as the package name) or by choosing the option “Add Objects from a Package” in SAPLINK.

Having a complete object list will be the first step towards a renaming matrix. Copy all objects to an excel sheet. Do not forget to also manually include function modules since they do not appear in TADIR or SAPLINK’s package overview.

Building the renaming matrix

Namespace refactorings are not successful of you try to replace only the prefix of all your development objects in the object list.

If you have a complete objects list which is the outcome of the previous step, start to manually rename the objects in an Excel sheet in a separate column.

Pay attention on:

• No generic string replacement fits all needs! Instead, replace objects from the object list one by one – try to prevent renaming them by a generic replacement like ZWM -> /LEOS/. Otherwise this will srew up your or SAP’s naming conventions for development objects
• Do not forget to also rename function modules one by one – as they do not have their own object entry in SAPLink or TADIR you will need to manually include them in the renaming matrix
• Naming convention for development objects like function group includes may change: e.g. LZWMFG_TA turns to /LEOS/SAPLFG_TA
• Include interfaces of webdynpro components in the renaming matrix. Even if they are not relevant for extraction later on, you might have used them in interface controller declarations in your source code, for example
  • DATA lo_interfacecontroller TYPE REF TO ziwci_wdyn_test.
    lo_interfacecontroller =   wd_this->wd_cpifc_users( ).

• If you are not sure what the name of the generated target webdynpro component interface would be, correct these syntax errors in the post processing step

Do Not:

• Rename function group includes or sources directly if you have no strong knowledge on the naming conventions – in this case try to create an empty function group in the target namespace with all includes and function modules in order to see what the naming conventions are
• violate typical workbench object name restrictions like their length

The result should look like this.

Extract your renaming matrix to a CSV file as this would be the requirement for a batch replacement.

Extract you development objects

SAPLINK helps you to extract all development objects you want to convert. Just use the option “Add Objects from a Package” and extract each package to its own nugget file – this helps you in having a good overview of what has already been extracted and what has not yet been extracted.

Do Not:

• extract Webdynpro component interfaces since they are automatically regenerated (they have *IWCI_* in their names)
• Extract ICF nodes that have been generated for Webdynpro-Applications. Just like webdynpro component interfaces, they are going to be recreated automatically for you in the target namespace.
• extract function groups for generated maintenance views – try to regenerate them based on the objects in the target namespace

Rename the objects

Copy all the nugget files to another workspace folder.

Start Advanced Find and Replace or a similar batch replacing tool. Include *.nugg files to your file mask, upload the CSV-Renaming matrix and set the workspace folder which contains the copies of your nugget files.

Execute the replacing loop.

Take a look at the new nugget files using Notepad++ and search for prefixes in the old namespace. If you found some, restore the nugget files in the workspace folder from the extracted version, update your renaming matrix and restart the replacing loop. Execute this step as often as needed, until you find no more prefixes in the old namespace.

Import the new nugget files

SAPLINK helps you to import your new nugget files to your system. Pay attention on error messages that may arise because of length violations or naming conventions. Usually, SAPLINK restores your objects to the $TMP package or asks for a target package.

Rebuild the objects list of the local object’s package and the target packages, to see all the created development objects.

Assign the objects, that are assigned to the $TMP package, to the target package.

Finally, activate them. Start with DDIC-Objects, then function modules or classes and end with UI components such as webdynpro components or reports that contain dynpros.

Postprocessing

Postprocessing will always be needed. If you followed this approach, you will probably need to

• manually translate class based texts in the new namespace
• manually translate exception class based texts in the new namespace
• regenerate maintenance views and view clusters
• If you missed to include development objects in your renaming matrix that are usually generated when its main development object is created, syntax errors might have occured. E.g. Webdynpro components have their own generated interface. Wrong interface controller declarations in your webdynpro component’s source code may need to be adjusted if you missed to replace the interface definition with its new version

Effort

To give you a feeling of how fast or slow such a namespace refactoring could be done, I figure out what the experience of past refactorings was:

• one package and 55 development objects (in terms of 55 replacing pairs in the renaming matrix) took half a day for one developer
• 6 packages with about 1100 development objects (in terms of 1100 replacing pairs in the renaming matrix) took four days for one developer

As you can see, the effort does not really proportionally increase with the amount of the development objects. This is because the initial effort, which is needed to get an overview of all the development objects depends more the number of packages, than on the number of development objects.

Building the renaming matrix may correlate with the number of development objects but this is usually not the main issue. Usually the most of the time is needed in the batch replacing procedure which is repeated iteratively until no old namespace object is found in the converted nugget files. The SAPLINK import procedure usually also takes some time as the development objects might have names that are too long for a specific object type. In this case you would also have to update your renaming matrix, and redo the batch replacing procedure.

However, if you finalize the process, chances are high that you fetched all the objects and converted them consistently without gaps.