Skip to Content
Personal Insights
Author's profile photo Bärbel Winkler

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. 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.

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 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.

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?

 

Assigned tags

      25 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Christian Lechner
      Christian Lechner

      Hi Bärbel,

      I have seen the same at customers. After running the S/4HANA readiness checks the results have been quite "interesting" i.e. functionality from IS-Health and IS-Media was reused. The bottom line for me and an important message to customers:  when converting to SAP S/4HANA even if you do not use industry-specific solutions like IS-H or IS-M in your business processes there might be some technical "debt" hidden in your custom code that you must consider and that will cause some efforts before you do the conversion.

      Best regards

      Christian

      Author's profile photo Andreas Huppert
      Andreas Huppert

      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

      I would consider such basic data elements as a bad practice. Data elements should carry semantic meaning.

      I suggest to create own data elements for each use case, even if many of them share the same technical data type. That is a bit more work in the beginning, but you gain:

      • individual description or even documentation in the data element, making its semantics clearer
      • the ability to change the data type of this data element in wherever it is used. A data element "char02" can never be changed to something else.

       

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Hi Andreas,

      not really sure if it's bad practice to use such basic data elements for typing internally used fields as is done in the examples I saw in our Z-code which don't really need much if any semantic meaning. If such a field needs another type within a program, the definition could just be switched to another available basic data element.

      My main point was SAP's "somewhat" haphazard naming of these data-elements (and corresponding) domains, that they are all over the place package-wise and with many "gaps" in between:

      (just a few of the 408 data-elements starting with "CHAR*").

      Author's profile photo Andreas Huppert
      Andreas Huppert

      Ok, but even without much semantic, the point still remains that you want to be able to change it without side effects.

       

      Author's profile photo Jeff Carty
      Jeff Carty

      We have a similar result in our ATC findings. Over 300 occurrences of IS-H usage. I also can confirm that all of the above objects do not exist in our 1809 test system (we are going 1909).

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Thanks for checking in your system and providing feedback, Jeff! Makes for an even stronger case inhouse to prevent making this issue worse and to add appropriate checks to our check variant used during transport release sooner rather than later.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      I'm currently trying to fix a development created in an ERP system (which is a standalone application), so that it can run on a BW system. I encounter exactly the same kind of issues - function modules and data elements that do not exist in BW are being used.

      I've encountered similar where I've created a whole suite of applications... and then the client asks for just one of them for one particular instance. It's very hard to disentangle! You either get all, or nothing.

      It's a bit of a paradox - on the one hand, don't recreate what already exists, but on the other hand, program without dependencies!

       

       

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      When I just started with ABAP, the mantra was "re-use", so we scoured SE11 for standard types that would match what we needed. I've even seen "do not create Z elements in dictionary" in some guidelines. Why? No one could explain other than "it takes up space". As if we were still dealing with the machines having memory in kilobytes. 🙂

      Of course, reusing is not bad but must be applied judiciously.

      Author's profile photo Florian Henninger
      Florian Henninger

      Hi Bärbel,

      I also can confirm that I see a lot results like that. Additional to the data-elements I want to make you aware, that also the reuse of exception-classes should be in your focus. This is something I also run in when upgrading from different S/4-releases. HAd the last shift from 1709 to 1809 and also run into the problem, that some of the data-elements and exception-classes did not exist anymore.

       

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Thanks for your feedback, Florian! If issues with the exception classes exist, I hope/guess that they'll be caught by the readiness checks - or is that hope in vain?

      Cheers

      Bärbel

      Author's profile photo Florian Henninger
      Florian Henninger

      Would suggest that it was caught by the check, but did not recognized it in a way. So I ran into the problem when the upgrade was running ?

       

      Author's profile photo Martin Fischer
      Martin Fischer

      Hi Bärbel,

      thanks for the blog post and making us more aware about that!

      It just shows again, that the package concept features which are offered by the ABAP stack are rarely used and this causes a lot of problems. I agree with Andreas Huppert that one should create own domains if possible. The same applies for me for error messages. If it's a custom application you should create your own messages. If it's an enhancement of SAP coding, only use the message class of the package the SAP coding belongs to.

      I know this feature is not often used, but the package concepts even offers the possibility of definining objects which can be seen and used from other packages and there are checks for that. So in a new custom code project I recommend to define a clear package concept and use this features!

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Underrated comment. 🙂

      Author's profile photo Martin Fischer
      Martin Fischer

      as the features and concepts I mentioned 😉

      Author's profile photo Joachim Rees
      Joachim Rees

      Yeah those package concepts seem to be really powerful. But as you mention, few people seem to use them.

      I once tried to get started with it, and collected some Infos:

      https://blogs.sap.com/2017/01/11/whats-to-know-about-abap-package-concepts-se21-today/

      but then I lost track again, I'm afraid...

      Author's profile photo Uwe Fetzer
      Uwe Fetzer

      Hi Bärbel,

      you are not alone. The following result is from a run I made yesterday (3.5 h runtime by the way). Most of the marked findings are dataelements or function calls which are not available anymore in S/4 (IS-M, IS-BEV,...)

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Should we start a club?!? ?

      Author's profile photo Uwe Fetzer
      Uwe Fetzer

      yes, the "S/4 Unreadiness Club".

      (and therfore every new finding SUCs ? )

       

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Thank you for sharing! Our system is not even there yet but it's been one of my "upgrade selling points" that we need to upgrade our ECC so that we can start the whole HANA readiness rather sooner than later.

      It would also allow us to improve discipline when creating new code. Just like we enabled Unicode checks on all programs even before the system conversion, it makes total sense to make any new code HANA-compliant.

       

      Author's profile photo Joachim Rees
      Joachim Rees

      Hi Bärbel,

      yes, I can add something (I had put it on Mastodon but not shared here yet) :

       

      Did you know? When going from #SAP #S4HANA 1709 to 1809 you will lose some dictionary types, e.g.:

      TAB_RANGE_C10
      or
      BAPIPARNR_TAB

       

      SAP-Components that (seem to) have been simplified (=> deleted) with #S4HANA 1809:

      IS-M: SAP Media (confirmed via #SimplificationList)
      IS-H: SAP Healthcare (haven’t seen a clue on this one)

      2 more* data-elements affected:
      BEZEI15
      AENTIME

      (*of course, there are many more, but those mentioned caused me some problems! ? )

       

      PS:

      Very smart if you find out via checks up front, that’s how it should be – we found out when doing the upgrade ?  (no big deal, we do an upgrade every year and there often is some kind of surprise)

      best
      Joachim

       

      Author's profile photo Bapu Halangali
      Bapu Halangali

      Hi Barbel,

      Nice to read this blog. As the upgrade from 1709 to 1909. We came across below ATC check. in S/4 HANA message class N4 is not available "Alternate message ID, message content needs to be created" and some issue with IS-M data element. Can you suggest what should we do?  Do we need to create custom messages and data element accordingly?

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Bapu Halangali

      Hi Bapu,

      if you get this message for some custom code you might indeed need to replace any usage from the N4-Message Class with one of your own. The N4-Message Class seems to be part of "IS-H" which no longer exists. The same might apply for the IS-M data element but I cannot check without more details, like e.g. the data element's name.

      Author's profile photo Bapu Halangali
      Bapu Halangali

      Hi Barbel thank for your reply,

      Detail are below

      MSAG JH
      DTEL JJBEZKKBET
      DTEL JMC_LFMNGL
      DTEL JMC_LFMNGL

       

      Author's profile photo Bärbel Winkler
      Bärbel Winkler
      Blog Post Author

      Bapu Halangali

      Hi Bapu,

      please check this note for more information about impacted objects in IS-M:

      https://launchpad.support.sap.com/#/notes/2469385

      Generally speaking, a good place to start looking for solutions is the Simplification Item Catalog where a search for "IS-M" finds several hits:

      https://launchpad.support.sap.com/#/sic/overviewWithfilter

      Hope this helps!

      Author's profile photo Bapu Halangali
      Bapu Halangali

      Hi Barbel ,

      Thank you for your valuable input.