Skip to Content

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.

Renaming Matrix.PNG

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.

Batch Replace.PNG

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.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Hardy

    When I had to migrate thousands of objects from one SAP system to another, SAPLINK seemed the obvious answer BUT the naming convention on the target system was radically different.

    Luckily the naming rules were clear on the target system, so I made a few little changes to SAPLINK, such that it automatically renamed the objects just prior to creating them on the target system.

    That worked like a charm.

    Cheersy Cheers

    Paul

    (0) 
    1. Uwe Kunath Post author

      Dear Dr. Röckelein, every current version of SAPLink supports Function Groups, hence function groups that are created in a partner namespace.

      However, when renaming these function groups to the target namespace, the developer needs to be extremely cautious about the target name as it might not fit to SAP’s naming convention for function groups.

      This is what I mean with creating an empty function group in the target namespace first: It simply ensures that you use a valid function group name in the target namespace that can be registered in the renaming matrix.

      Regards, Uwe

      (0) 
        1. Uwe Kunath Post author

          Yes, it looks like you are right. So I’m wrong with the assumption that every current SAPLink version supports function groups, at least not for customer namespaces. This means that function groups are subject to a manual conversion.

          (0) 
        2. Uwe Kunath Post author

          It looks like this check has been introduced as a security measure. When I wrote this blog post I was able to install function groups in customer namespace with SAPLink.

          But as I already mentioned, it is (was) quite easy, to screw up a whole function group with no possibility to ever delete it again. Happened to me once.

          So if SAPLink doesn’t support function groups in customer namespace, it would be the best option to manually copy the function modules one by one to the target namespace and use Advanced Find & Replace based on the manually created extract of the function module contents. This also applies to the includes of the function group.

          (0) 

Leave a Reply