Interesting stuff you find when running S/4HANA Readiness Checks

Even though our move to S/4HANA is still quite some time away, I decided to run readiness checks with the latest simplification database for release 1909 on our large Z-code base.

Luckily enough, we already have a remote ATC-system which is on NW 7.52 and therefore ready for the S/4HANA readiness checks so to speak. After having OSS note 2812556 – Check variant for SAP S/4HANA 1909 custom code checks applied in the central ATC system, I set up a run series to look at all of our Z-code and used the standard S4HANA_READINESS_CHECK_1909 for it. Due to the numbers of objects to check in two development systems, the runs took a while to complete, but with less than 1 1/2 and 2 1/2 hours runtime respectively it wasn’t too bad either. Not too surprisingly, the resulting lists of findings were quite large and instead of poking around in SAP in them, I grabbed the whole lot and downloaded it into Excel in order to more easily “play” with the results.

Looking at the findings

With some tweaking of the Excel-files and creating some pivot-tables based on the individual entries, I was able to generate a useful listing by Simplification OSS-Note showing all the programs affected by it.

Next – and somewhat tedious – step was to create one page per note – if it hadn’t already been created by colleagues – in an internal Confluence space on which to provide a link to the OSS-Note and some information from it, especially comments on what needs to be looked for in Z-code in need of adaptation. I also added the list of affected programs to each page (yes, not a fun task but one which will prove helpful in the future when looking for concrete examples in our own code).

What the heck?1?

Looking through the long list of OSS Notes I wasn’t surprised to see items for “2215424 Material Number Field Length Extension” or mentions of “2220005 S/4HANA: Data Model Changes in Pricing and Condition Technique” as these are related to processes we obviously had in use. But, there were also some rather weird titles included in the list which looked completely out of place for our company.

Why should we have programs impacted by “2689873 SAP S/4HANA: SAP Patient Management (IS-H) Restriction Note“? This really piqued my curiosity especially because the note contained this interesting piece of information: “Also please note, that as of SAP S/4HANA 1809 all development objects belonging to the above mentioned healthcare products have been deleted from the software stack.”. So I went through the not even short list of 80 to 100 programs to find out what was going on. Here is a collection of the things I found:

Some programs were calling function modules which at least had “ISH” in their names, giving away where they belong to:

        CALL FUNCTION 'ISH_BAPIRET2_DISPLAY'

          TABLES

            ss_bapiret2 = lt_mess[].

        call function 'ISH_POPUP_TO_CONFIRM_SIMPLE'

          EXPORTING

            I_TITLE    = text-ach

            I_TEXTLINE = v_textline

            I_QUESTION = v_text80_2

            I_DEFAULT  = 'N'

          IMPORTING

            E_ANSWER   = v_answer.

But, most of the impacted IS-H objects used in the programs have rather nondescript names and I’m really not surprised that developers have made use of them over the years. Often, the only “tell-tale” sign that an object belongs to “IS-H” is in the description field. Here are some examples:

Function Module:

  CALL FUNCTION 'FORMAT_DATE_4_OUTPUT'

    EXPORTING

      datin  = p_wadat

      format = 'DD.MM.YYYY'

    IMPORTING

      datex  = var_date_out.

Memory ID:

      P_FILE      LIKE RLGRAP-FILENAME

                                   MEMORY ID FIL

Messages (not sure about you, but I also tend to reuse standard messages instead of creating yet another version for something generic as “Customer & was changed” for which I then have to provide translations and possibly long explanations):

    MESSAGE i179(n8). "There is no data for your selection

    MESSAGE s064(nf) WITH sy-subrc 'LT01' "Error & while calling transaction &

    INTO lt_listact_alv-message.

    MESSAGE e115(n2) WITH wa_kna1-kunnr "Customer & was changed

                          space INTO wa_data_alv-msgtxt.

But, the icing of the cake must be the innocuously named data element “CHAR02”:

    constants C_CREATE type CHAR02 value '01' ##NO_TEXT.

      c_bt   TYPE char02            VALUE 'BT', 

Given, that there are several other comparably named data elements just with different names depending on length, it’s really no wonder that this one gets used rather a lot! Looking for an alternative for CHAR02 I quickly found CHAR_02 which can be used instead – and judging from its package name ABA_TOOLS this one will hopefully stick around for long(er) and not get axed!

What I don’t quite understand is why SAP doesn’t just provide a complete set of data elements and corresponding domains in one of the basic packages (perhaps ABA_TOOLS?) named i.e. CHAR_001, CHAR_002 …. CHAR_128 (or whatever), plus the same with e.g. “_CS” at the end to show that it’s for case-sensitive content. This would avoid “accidental” usage like happened here for CHAR02.

Next steps

What I’m going to do with these and other yet to be identified “interesting” findings is to put them in a list in our development guidelines, let our developer teams know about them and ask them to at least no longer use the impacted objects for any new developments. Whenever possible and feasible they should also be eliminated from existing code should it need to be changed for whatever reason. I’m also going to define a custom check variant including only checks which can actually be acted upon easily before the conversion to S/4HANA happens – and are not as ubiquitous as for example the MATNR-length issue for which – if need be – automated code-updates should be available by the time we actually make the switch.

What I also plan to do is to include this check into a regular routine – perhaps a daily check-run for currently open transport requests and the objects these contain. The check variant will include the relevant check but restricted to the exact OSS-Note(s) to avoid too many unwanted/false hits. Ideally, I’ll also find a way to send the findings to the developer currently working on the object in order to alert him/her about these not S/4HANA compatible constructs in the code. Perhaps, I’ll also include them in the regular check used during transport release but the findings might get overlooked often because they are only priority 3 (and I’m not yet sure it would be worth changing that to priority 2 or 1 in order to prevent transport release). But, I’m fairly certain that we should at least prevent creating more programs with these types of preventable issues.