Innovations such as cloud computing, consumer-like user experiences, the Internet of Things, and social networks are no longer emerging trends — they are a business reality. SAP S/4HANA is a suite of products, available both on premise and in the cloud, that brings these innovative technologies to every corner of your business, from its core financial and logistics capabilities to its built-in support for procurement, human resources, and customer relationship management.
The latest version of the on-premise SAP S/4HANA — SAP S/4HANA 1610, delivered in October 2016 — brings even more innovation to customers, including an enhanced user experience based on SAP Fiori 2.0 and supply chain capabilities that support new technologies such as machine learning and predictive algorithms. Released on ABAP 7.51, SAP S/4HANA 1610 presents a unique opportunity for businesses running traditional SAP Business Suite implementations to transition to a next-generation software suite designed for competing in the digital age, as both SAP Business Suite and SAP S/4HANA use the same underlying SAP technology.1
So how do you go about getting there? And what do you do about the vast array of custom code underlying your SAP Business Suite systems? While there is no direct upgrade path from SAP Business Suite to SAP S/4HANA — SAP S/4HANA is a completely new offering from a license and deployment perspective — SAP does offer migration and conversion tools to help customers navigate the process successfully (see the sidebar “Moving at Your Own Pace” for more on migration flexibility). This article looks at innovations delivered with SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP 7.51 that enable a smooth transition from a traditional SAP Business Suite system — such as SAP ERP 6.0, enhancement package 8, running on SAP NetWeaver 7.5 — to SAP S/4HANA 1610, with a particular focus on migrating your custom code.
Custom Code and the New SAP S/4HANA Data Model
Traditionally, custom code has been used to close the gap between SAP standard applications and individual customer needs for optimizing business operations. A typical customer installation of SAP ERP is surrounded by a large custom code base written in ABAP that has accumulated over decades to support business requirements.
For instance, many customers have written custom reports referring to SAP tables and structures, domains, and data elements. Many have also customized existing SAP applications using traditional enhancement techniques, such as Business Add-Ins (BAdIs), or extension points in the user interface, such as Web Dynpro field and table extensions. Customers have also modified the code wherever predefined extension points were missing, meaning they obtained a modification key from SAP Service Marketplace to “unlock” and edit the source object — modifications that need to be adapted and reinserted anytime a support package or enhancement package is applied.
When migrating to the on-premise version of SAP S/4HANA, customers need to analyze this custom code base to see which customized applications and extensions are required in SAP S/4HANA, and then adapt that code to the new SAP S/4HANA data model. As shown in Figure 1, SAP S/4HANA comes with a dramatically simplified data model, which means that custom code that worked in SAP Business Suite may no longer work in SAP S/4HANA without modification due to changes in the underlying SAP code that is referenced by that custom code. For example, SAP S/4HANA eliminates the need for aggregates — SAP S/4HANA runs on top of the SAP HANA data platform, which aggregates all totals and subtotals on the fly using its in-memory and column-based architecture. In addition to eliminating aggregates, many underlying dictionary objects (including tables, domains, and data elements) have been simplified in SAP S/4HANA — artifacts upon which custom code typically depends.
Without adaptation to the new SAP S/4HANA data model, migrated custom code is likely to fail. It will most likely be syntactically incorrect, or will dump during runtime. Some of the custom code might remain valid if certain aspects of the data model have not changed, but in general you need to adapt the code when transitioning to SAP S/4HANA. Fortunately, ABAP 7.51 comes with tools and methodologies to enable this transition.
Converting Custom Code for SAP S/4HANA
From a process perspective, converting your custom ABAP code for the on-premise version of SAP S/4HANA is similar to the process of performing a traditional upgrade (see Figure 2).
As you can see, the overall process is divided into a Prepare phase and a Realize phase. In the Prepare phase, the custom code is analyzed on the source SAP Business Suite system. The adaptation of the code happens in the Realize phase on the converted SAP S/4HANA system, since the new SAP S/4HANA code and simplified data model are required to adapt the custom code. Note that a precondition for converting to SAP S/4HANA is that your source SAP Business Suite system must support Unicode, and at a minimum must be running on SAP NetWeaver 7.0x and include SAP ERP 6.0. SAP S/4HANA 1610 requires, and includes, ABAP 7.51 as its foundation.
To support the Prepare and Realize phases of the conversion, a separate analysis system is recommended to host the analysis tools and related functionality — such as the Simplification List, the Simplification Database, and the Custom Code Migration Worklist — used during the conversion. From this system, analysis tools can monitor your existing landscape, and the centralized setup makes it easy to keep the analysis system up to date. SAP NetWeaver AS ABAP 7.51 is an ideal fit for the analysis system — in addition to providing the latest functionality, it is essentially only an SAP NetWeaver AS ABAP stack, so setup is simple and straightforward.
The Simplification List, the Simplification Database, and the Custom Code Migration Worklist play key roles during the conversion process, as you will see later in the article. The Simplification List is a detailed technical document (in PDF format) that explains how the conversion will affect specific transactions and application functionality and provides recommendations for the necessary adaptations. The Simplification Database (see Figure 3), which is accessed by the analysis tools, contains the SAP objects documented in the Simplification List that have been changed or removed for SAP S/4HANA, along with SAP Notes describing the changes.2 The Custom Code Migration Worklist lists all custom objects that refer to items in the Simplification Database and must be adapted for SAP S/4HANA.
Let’s take a closer look at the key tasks involved in the Prepare and Realize phases of a custom code conversion for SAP S/4HANA.
The Prepare Phase
As with a regular upgrade, you use the Maintenance Planner, a cloud-based service of SAP Solution Manager, to plan and initiate the overall system conversion process. The Maintenance Planner analyzes the source system and ensures that all correct components are in place for the conversion, guiding you step by step through the conversion process. Here, we focus on the code and compatibility portion of the process, which can be subdivided into three steps: eliminate obsolete code, check for SAP HANA and SAP S/4HANA compatibility, and prepare your adaptation worklist.
Eliminate Obsolete Code
To minimize the conversion effort and ensure a smooth transition, first evaluate your existing custom code base to determine what is really needed in the SAP S/4HANA context. In many customer installations, custom code has grown significantly over the years, and some of it is no longer necessary. Think of relocating to a new house — typically you don’t want to move everything. Some items are necessary, but it’s best to leave behind whatever is no longer needed. The same is true for custom code. SAP Solution Manager provides access to tools and services, such as the ABAP kernel-based Usage Procedure Logging tool, to help you identify custom code that is potentially dead and can be removed.
Once you’ve eliminated any obsolete code, the next step is to perform checks on the remaining custom code for SAP HANA and SAP S/4HANA compliance, and then use the results of these checks as a worklist for adapting your custom code.
Check for SAP HANA and SAP S/4HANA Compatibility
The Code Inspector tool (transaction SCI), which is included with SAP NetWeaver AS ABAP, provides check variants for evaluating custom code for SAP HANA and SAP S/4HANA compatibility, and is ideal for performing the analysis work of the conversion process. To manage this work, and to take advantage of the latest checks included with ABAP 7.51, the Code Inspector should run in the separate SAP NetWeaver AS ABAP 7.51 analysis system mentioned earlier, from which it can run its checks on monitored systems, including lower-level systems (releases 7.0x and above), by transferring input from monitored systems via an extraction capability over a remote function call (RFC) channel.3
The FUNCTIONAL_DB check variant of the Code Inspector (see Figure 4) identifies typical errors when moving to SAP HANA, such as use of the ADBC interface, which might contain database-specific SQL statement code, and database operations on physical pool or cluster tables.4 Another commonly identified error when migrating from another database platform is invalid assumptions about the sort order of result sets. Although most custom code is based on Open SQL, which provides full database independence, some legacy ABAP programming techniques assume a certain default sort order of the result set and therefore omit the ORDER BY clause, which is required in SAP HANA, where the result set is not ordered by default as defined by the SQL standard. The Code Inspector identifies these errors, which are easily remedied by making the necessary changes (such as adding the ORDER BY clause) in the appropriate editing tool. These changes should be made immediately, during the Prepare phase, to reduce complexity.
The Code Inspector also provides an S4HANA_READINESS check variant that uses the Simplification Database to evaluate the code for changes that will be needed for SAP S/4HANA, such as data model changes. One significant data model change is the extension of the material master code from 18 to 40 characters in SAP S/4HANA. Since customers often use their own material code numbers, this can cause type and length conflicts in a conversion, such as concatenation of fields if the target field is not long enough. Another significant data model change is that many physical tables referenced by write and read operations have been removed in SAP S/4HANA. For read operations, SAP S/4HANA delivers a compatibility view that computes the desired output on the fly, such as aggregations, but write operations will need to be adapted — SAP S/4HANA provides function modules for this purpose, but you must call them explicitly in your custom code.
The Code Inspector provides an assortment of SAP S/4HANA checks (see Figure 5) with the S4HANA_READINESS check variant to identify these types of SAP S/4HANA issues, such as field extension checks and database operations checks. While there is always the possibility of false positives due to the nature of custom code that cannot be understood by a tool, the checks provide valuable information for analyzing your particular situation, and identifying where you need to make changes in the Realize phase.
Prepare for the Adaptations
Once you complete your checks in the Code Inspector and remedy any errors identified by the SAP HANA checks, you are ready to prepare for the necessary SAP S/4HANA adaptations. While you must manually create your worklist of changes identified by the SAP HANA checks, which tends to be fairly simple and straightforward, the results of the SAP S/4HANA checks, which are likely to be more extensive, are compiled into the Custom Code Migration Worklist that serves as your SAP S/4HANA adaptation guide in the Realize phase. Some required SAP S/4HANA changes are currently beyond the scope of the Code Inspector checks, however. To bridge this gap, and to ensure that nothing is overlooked, SAP provides transaction SYCM.
Included with SAP NetWeaver 7.5,5 SYCM is a small transaction that runs in the centralized analysis system, with extraction capabilities providing the necessary input from monitored systems. SYCM provides an overview of how your custom code objects relate to the simplification items in the Simplification Database (see Figure 6). For example, if you call a BAPI in your SAP Business Suite custom code, but this BAPI no longer exists in SAP S/4HANA or its interface was changed in a way that is incompatible with SAP S/4HANA, a corresponding entry will appear in the SYCM overview screen. From there, you can navigate to the corresponding code and development objects or display the SAP Note that documents the listed simplification item.
SYCM serves as an initial overview and entry point for further analysis of the impact and effort required to adjust your custom code objects for SAP S/4HANA. While SYCM is useful in the Prepare phase for estimating and planning for the adaptation effort that will be required in the Realize phase, it should not replace the Custom Code Migration Worklist in the Realize phase — the Custom Code Migration Worklist should serve as your main guide, with SYCM filling in any gaps in a complementary role.
The Realize Phase
Once you are prepared to adapt your custom code for SAP S/4HANA, you are ready to execute the physical conversion. Use the Software Update Manager system maintenance tool to execute the physical conversion steps, such as migrating the database to SAP HANA, updating all the relevant software components (such as the ABAP kernel and Basis components), and converting the data. With the physical conversion complete, it’s time for the functional adaptation of the code, which takes place in the newly converted system.
First, you adapt your modifications to SAP standard-delivered objects that will also be present in SAP S/4HANA using transactions SPDD and SPAU, as you would when upgrading or applying a support package or enhancement package to SAP Business Suite. Note that with ABAP 7.51, the SPAU transaction has been enhanced to support mass operations in cases where you want to reset your modifications and return to the SAP standard.
Next, it’s time to work through the custom objects identified by the Code Inspector as needing adjustment for SAP S/4HANA, due to their dependence on the simplification items included in the Simplification Database, which are listed in the Custom Code Migration Worklist (see Figure 7). These custom objects can be adjusted by simply going into the editor tool for each affected custom object and fixing the syntactical and semantic errors, such as adapting write operations that reference physical tables that no longer exist. Remember to use transaction SYCM for an initial overview of any custom objects that correspond to items in the Simplification Database, since the Code Inspector checks do not cover all SAP S/4HANA-related issues.6
When the worklist is complete, the system is ready from a purely functional perspective. You will still need to optimize system performance by tuning critical queries and SQL statements using the SQL Monitor (transaction SQLM), which tracks execution times for SQL statements and the originating program, function modules, or ABAP classes. The SQL Monitor offers drilldown capabilities (see Figure 8) and leads you to the corresponding tool to fix any identified performance issues.
SAP S/4HANA enables customers to integrate into their organization the technologies that define modern business, and SAP S/4HANA 1610 is an opportunity for those running SAP Business Suite to make the move with the support of migration functionality delivered with SAP NetWeaver AS ABAP 7.51 — including conversion tools for managing your custom code. Validated with realistic custom code from large SAP Business Suite customers, these tools help you ensure a smooth and reliable transformation of your organization into a next-generation digital business running on SAP S/4HANA.
Learn more about migrating your custom ABAP code at http://bit.ly/CustomCodeMigration751.
1 Note that the on-premise SAP S/4HANA requires only the ABAP platform, meaning that the digital core is based on technology innovations delivered with the ABAP platform. Java-based on-premise services such as Adobe Document Services, Enterprise Services Repository, and SAP Process Integration can be reused from existing SAP NetWeaver integration hubs. [back]
2 The most recent content provided for SAP S/4HANA is described in SAP Note 2241080. [back]
3 SAP Note 2270689 describes the extraction process. [back]
4 SAP Note 1912445 describes the FUNCTIONAL_DB check variant in detail. [back]
5 Since the publication of this article, transaction SYCM has been replaced by the ABAP Test Cockpit. Learn more at https://blogs.sap.com/2017/02/15/sap-s4hana-system-conversion-custom-code-adaptation-process. [back]
6 In the future, SAP plans to embed all SYCM findings into the Code Inspector. [back]