SAP S/4HANA Readiness Check

SAP S/4HANA Readiness Check

Moving from SAP Business Suite to SAP S/4HANA brings modern ERP to SAP customer landscapes. Making this transition means converting to a new data model, since SAP S/4HANA is a completely new product — it also means adapting your existing custom code, which most likely has dependencies on data elements that have been changed or removed in the new model. This article shows you how to identify and resolve incompatibilities between your custom code and the new SAP S/4HANA data model using ABAP Test Cockpit to ensure a smooth transition to SAP S/4HANA.

With SAP S/4HANA, SAP delivers an intelligent suite of enterprise applications that brings innovations such as the Internet of Things, machine learning, and real-time analytics to customers’ business operations, both on premise and in the cloud. As moving to SAP S/4HANA increasingly becomes more a question of “when” rather than “if,” most SAP customers are looking at how to make this move from an SAP Business Suite implementation centered around SAP ERP, the latest version being enhancement package 8 running on the SAP NetWeaver 7.5 technology stack.

Since SAP S/4HANA is a completely new product version with a new data model built on core data services, customers making this transition need to perform a system conversion from SAP Business Suite to SAP S/4HANA and migrate to the SAP HANA database if it is not already in use. In addition, they must adapt any custom code created for SAP Business Suite that is incompatible with SAP S/4HANA. Adapting custom code is never a trivial undertaking for any organization, and to support its customers in this task, SAP delivers analysis tools as a part of SAP NetWeaver that enable you to fully manage this process, including extended syntax checks and the Code Inspector tool.

In the past, these tools were delivered individually as part of the standard SAP NetWeaver shipment. As of SAP NetWeaver 7.5x, these tools are combined in ABAP Test Cockpit, which enables you to get an overview of the project scope, analyze the adaptation requirements, and perform the adaptions directly in the code with the help of the Eclipse-based ABAP development tools, all from a single tool.

This article shows developers and development project managers how to adapt custom code for SAP S/4HANA using ABAP Test Cockpit. While a previous SAPinsider article covered in detail the process of migrating from SAP Business Suite to SAP S/4HANA, this article focuses on the portions of the process that involve adapting custom code for SAP S/4HANA, which takes place after the system migration (see the sidebar “The SAP S/4HANA Migration Process at a Glance” for a brief overview of the overall migration process). You will learn how to create a preliminary overview of potential issues with your custom code that you can use to prepare for your adaptation project, and how to then use ABAP Test Cockpit to identify and resolve incompatibilities between your custom code and the new SAP S/4HANA data model, including a look at how to address three commonly identified issues.

The SAP S/4HANA Migration Process at a Glance

The process of moving to SAP S/4HANA can be separated into two major phases: Preparation and Realization.

Preparation

During this first phase, the customer continues operating the traditional SAP Business Suite while undertaking important steps to prepare for the system conversion. First, you need to get rid of obsolete custom code that has piled up over the years (in many cases, you don’t want to move these assets to the “new house”). Next, you need to adapt ABAP coding that is not ready for SAP HANA. In general, ABAP is fully database-independent and portable, but there are cases in which you need to adjust the code (for example, ABAP uses implicit sort order while SAP HANA uses explicit sort order in accordance with the SQL standard). Experience shows that this step should be carried out carefully before the system migration.

Realization

During this second phase, the system conversion to SAP S/4HANA has been completed using SAP’s lifecycle management tools. The new SAP S/4HANA data model, which is built on core data services, is already in place, and your custom code most likely has dependencies on objects that have been changed or removed in the new model. As a result, you must adapt your custom code in the SAP S/4HANA system.

Creating an Overview with Transaction SYCM

Once the technical migration is complete, it is a good idea to get an overview of the impact SAP S/4HANA will have on your custom code before you begin the adaptation project, so that you can plan for the adaption effort that will be required. Transaction SYCM, which is included with SAP NetWeaver 7.5x, can provide this overview. The SYCM overview screen shows how your custom code objects relate to the items in the Simplification Database, which contains documentation on the SAP data objects that have been changed or removed for SAP S/4HANA. You can view the full contents of the Simplification Database in the SYCM overview screen (see Figure 1) or you can refine the results using a selection screen.

Figure 1 — The SYCM overview screen displays the contents of the Simplification Database

Items in the Simplification Database are grouped into different categories, such as “Functionality not available” or “Syntactically incompatible change of existing functionality.” In the latter category (see Figure 2), you will find the most well-known data element change in the SAP S/4HANA data model: The length of the material number field has been extended from 18 characters in SAP Business Suite to 40 characters in SAP S/4HANA. Each simplification item is documented in a corresponding SAP Note, which explains the change and its impact — for example, the item for the material number field change links to SAP Note 2215424, which includes all the general information for the extension of the material number field from 18 to 40 characters (see Figure 3).

Figure 2 — Items in the SYCM overview are grouped according to category

Figure 3 — Each item in the SYCM overview links to a corresponding SAP Note that explains the change

You can learn more about which objects will be affected by a change by drilling down into the details of a simplification item from the SYCM overview screen. For example, when you drill down into the item for the material number field change (see Figure 4), you find 305 SAP objects, such as other domains and data elements, that will be affected by this change. You can then drill further down into each of the affected objects — for instance, one object affected by the material number field change is the data element LMBI_MATNR, which now also points to the 40-character domain MATNR (see Figure 5).

Figure 4 — Drilling down into an item in the SYCM overview displays a list of objects that will be affected by the changes in that item

Figure 5 — Further details are available on how each object will be affected by the changes in that item

You can restrict the result set displayed in the SYCM overview in many ways. For example, if you are interested in transactions related to materials management, you can use the SYCM selection screen to search for all transactions starting with the letter “M” (see Figure 6), which results in the list shown in Figure 7, with the relevant simplification items again grouped by category. You can further refine your search by specifying the SAP Note number, the software component, the release, and support package level, for example.

Figure 6 — Refine the SYCM result set — for example, specify that it display transactions starting with the letter “M” — using the SYCM selection screen

Figure 7 — The SYCM result set showing only transactions starting with the letter “M”

While SYCM provides an initial impact analysis that is useful for planning purposes, it does not tell you what to do next. This is where ABAP Test Cockpit comes into play.

Adapting Custom Code with ABAP Test Cockpit

ABAP Test Cockpit is standard-delivered with SAP NetWeaver Application Server for ABAP and significantly simplifies the code testing required during development by integrating various individual checks and tests, such as Code Inspector checks, into a single tool. In an SAP S/4HANA adaptation project, you can use this tool to first create an overall worklist for the project by running broad-based checks on your code, and then, with the results of these checks as a guide, you can use the tool to check and adapt individual programs.

Let’s look at how ABAP Test Cockpit can be used to create the overall worklist by walking through how to:

Check the code
Analyze the results
Adapt the code

1. Check the Code

Start ABAP Test Cockpit with transaction ATC. The main screen presents a structured list of various options, such as basic setup and administration settings. To schedule a run to check for code you will need to change for SAP S/4HANA, click on Schedule Run and specify a series name for the run — for example, S4H164_98B (see Figure 8).

Figure 8 — Schedule a series run to check the code in ABAP Test Cockpit

Next, configure the run series, including assigning the Code Inspector check variant S4HANA_READINESS, which provides a set of checks that uses the Simplification Database to identify typical errors in custom code when moving to SAP S/4HANA (see Figure 9). You can restrict the objects to be checked during the run series in various ways — for example, you can specify that the run check all objects that belong to a specific ABAP package.

Figure 9 — Configure the series and assign the S4HANA_READINESS check variant for the run

After configuring the run series, select the series from the list of saved configurations (Figure 10) and schedule the series (Figure 11). If it is a long-running job, you can schedule the series to run in the background.

Figure 10 — Select the series to run

Figure 11 — Schedule the run series

2. Analyze the Results

After the run series has completed — in dialog or when the corresponding job has finished in the background — the next task is to analyze the results. On the ABAP Test Cockpit start screen (Figure 12), select Manage Results, which takes you to a selection screen for browsing the run series results.

Figure 12 — The ABAP Test Cockpit start screen

Enter the name of the previously defined run series — S4H164_98B in the example (see Figure 13) — and choose the run series from the resulting display (Figure 14).

Figure 13 — Search for the run series result set

Figure 14 — Select the run series result set

The result set of the run series is displayed in an overview screen (see Figure 15) that contains the concrete findings and corresponding statistics. The left pane shows the different error categories, such as field length extensions. The right pane provides a summary of the identified errors grouped by priority. The bottom pane displays details such as the specific error message, the affected SAP object, the object owner, and the package assignment. From here, you can drill down into the source code by clicking on the program name, which opens the ABAP Editor in ABAP Workbench (see Figure 16), where you can quickly analyze the code.

Figure 15 — View the run series results

Figure 16 — Drill down into the source code

To investigate the root cause of an identified error in more detail, double-click on the check, which displays the details shown in Figure 17. In this example, a transaction was called — transaction MB11 — that no longer exists in SAP S/4HANA.

Figure 17 — Investigate the root cause of an identified error

3. Adapt the Code

Now that you have an overall worklist for the adaptation project to use as a guide, you are ready to make the necessary corrections identified in the worklist by checking and adapting the code in the individual programs.

While you can drill down into the code via ABAP Test Cockpit and make the necessary changes using the ABAP Editor in ABAP Workbench, the Eclipse-based ABAP development tools offer many new features that simplify the adaptation process and are not available in ABAP Workbench. We’ll look at how to take advantage of these capabilities next.

Using ABAP Test Cockpit with the Eclipse-Based Development Tools

ABAP Test Cockpit and the Eclipse-based ABAP development tools can be easily used together — they are tightly integrated and work from the same repository. Let’s see how you can combine the tools to analyze and adjust code by looking at a few typical examples:

Calling obsolete or removed transactions
Changes in field length
Invalid assumptions about sort order

Calling Obsolete or Removed Transactions

In traditional ABAP coding, transactions are often called on the fly to link different activity areas, such as materials management and logistics. Figure 18 shows an example selection screen program in the Eclipse IDE for the ABAP development tools. This example program calls two transactions: MB11 and MATGRP03. MB11 has been marked as obsolete in SAP S/4HANA, which results in an error message that also points to the corresponding SAP Note. Since MB11 no longer exists, when transaction MATGRP03 is called in this program, the system dumps.

Figure 18 — The obsolete transaction referenced in the program results in an error message that points to the corresponding SAP Note

To analyze the issue, you can start an ABAP Test Cockpit run on the program from within the Eclipse-based ABAP development tools. Right-click on the program name in the Project Explorer pane of the Eclipse IDE, select Run As > ABAP Test Cockpit With, and then enter the check variant S4HANA_READINESS (see Figure 19). ABAP Test Cockpit will show the findings in the ATC Problems view in the lower pane of the Eclipse IDE (see Figure 20) with the corresponding SAP Note displayed on the right, which contains details on how to fix the error. To fix the issue in the example, switch back to the source code editor and replace the obsolete transaction MB11 with a new one called MIGO.

Figure 19 — Run the S4HANA_READINESS check variant to analyze the issue causing the program to dump

Figure 20 — The ATC Problems view summarizes the findings from the check and displays details on how to fix the error

Changes in Field Length

The extension of the material code to 40 characters in SAP S/4HANA can cause problems if the custom code has made assumptions about the length of the material code — this can happen when variables are declared in a dependent fashion or when fields are concatenated into a result field that is not large enough.

Figure 21 shows an example list of materials that looks incomplete — data is missing from the Created On and Created by columns. To investigate the root cause in more detail, start the ABAP Test Cockpit run as before and examine the findings in the ATC Problems view (see Figure 22). If you analyze the error, you can see that a length conflict has occurred. The source field <l_mara> is 40 characters while the target field l_material is 18 characters. You can also view the characteristics of each field, including the length information, in a pop-up by clicking on the field in the source code editor and pressing the field info key (F2).

Figure 21 — An incomplete list of materials due to a field length conflict

Figure 22 — Analyze the findings in the ATC Problems view to identify where the length conflict occurs and how to fix it

To fix the issue in this case, simply change the declaration to MATNR, which is 40 characters, and rerun the check by right-clicking on the error in the ATC Problems view and selecting Recheck. The error message disappears (see Figure 23) and the list displays as expected (see Figure 24).

Figure 23 — Once the error is fixed, the error message disappears

Figure 24 — By changing the declaration to a 40-character field, the list of materials displays as expected

Invalid Assumptions About Sort Order

Invalid assumptions about sort order in custom code is another common cause of issues after an SAP S/4HANA migration. For example, let’s say an empty table is shown that should display sales orders (see Figure 25). If you analyze the ABAP coding with ABAP Test Cockpit, you can see that there is a SELECT statement that uses the addition FOR ALL ENTRIES to read records with specified sales order keys into an internal table (see Figure 26). The logic that follows that statement uses a READ TABLE with BINARY SEARCH, assuming the data is sorted implicitly, as is common in traditional ABAP programs. In standard SQL, which SAP HANA follows, you cannot rely on an implicit sort order, since SQL is set-oriented and does not imply a sort order.

Figure 25 — An empty table due to invalid assumptions in the code about sort order

Figure 26 — Analyze the findings in the ATC Problems view to identify where the invalid assumption occurs and how to fix it

To fix this issue in the example, you can replace the procedural access with the SQL statement shown in Figure 27. The result list is then properly displayed when you rerun the check (see Figure 28).

Figure 27 — To fix the issue, replace the procedural access with a SQL statement

Figure 28 — By replacing the SQL statement, the sales order list is properly displayed

Summary

SAP S/4HANA is SAP’s solution for the intelligent enterprise — it offers a range of innovative technologies that customers can use to simplify, integrate, and modernize their business operations. To help its customers make the move from traditional SAP Business Suite implementations to SAP S/4HANA, which requires adapting custom code to the new SAP S/4HANA data model, SAP provides tools that fully support the process.

All data type and data model changes included in SAP S/4HANA are collected in the Simplification Database, which provides access to relevant SAP Notes that document the technical changes in detail and provide guidance for developers. With this information as a guide, along with the tight integration between ABAP Test Cockpit and the Eclipse-based ABAP development tools, you can identify and resolve incompatibilities between your custom code and the new SAP S/4HANA data model to ensure a smooth transition to a modern ERP system.

Ref: Wispubs.com