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. This was inspired by my own curiousity of what surprises we have "sleeping" in our system and the neat summary slide from e.g. olga.dolinskaja's presentation at this year's TechEd in Barcelona (session CAA364) which among other things suggests to make new code S/4HANA ready:
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.
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).
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:
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:
Memory ID:
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):
But, the icing of the cake must be the innocuously named data element "CHAR02":
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.
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.
Have any of you encountered similar cases with finding out-of-place simplification notes and interesting impacted objects? If you did, how did you deal with them? If you already have a S/4HANA 1809 (or even 1909) system at your disposal, would you mind checking if the above mentioned objects really no longer exist and let us know in the comments?
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?!?
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 FILMessages (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.
Your experience and asking for verification
Have any of you encountered similar cases with finding out-of-place simplification notes and interesting impacted objects? If you did, how did you deal with them? If you already have a S/4HANA 1809 (or even 1909) system at your disposal, would you mind checking if the above mentioned objects really no longer exist and let us know in the comments?
- SAP Managed Tags:
26 Comments
