Extended Integration Analysis in SAP Readiness Check – Impact Analysis in Detail
This is the third blog in the series. Links to the other blogs in the series are provided at the end.
In this blog we will describe how the Integration check functions, which data sources are considered, how impact types are defined, and what they mean from a practical perspective.
As we pointed out in the first blog of the series, the new Integration check now performs the following:
- Provides a list of discovered interfaces
- Automates otherwise tedious analysis and cross-checks with different data sources
- Identifies interfaces that may no longer work (or function as expected) following the conversion to SAP S/4HANA or upgrade between SAP S/4HANA product versions
Let’s explore each of these capabilities in detail.
List of Discovered Interfaces
One of the surprises of the previous implementation of interface analysis within SAP Readiness Check was an unexpectedly high number of IDoc interfaces, reaching one million and beyond. This was the case because every IDoc-partner combination was counted separately.
Project experience showed that, in many cases, an interface adaptation activity is not partner specific. That led us to the idea of a technical interface definition that we now use in SAP Readiness Check to count interfaces. We define a technical interface by its key characteristics relevant for the impact analysis and adaptation activities. The number of partners is calculated to help with an effort estimation in case certain adaptation activities have to be repeated for every partner.
For example, an inbound RFC call to a custom function module is defined by the function module name. If this function module became binary incompatible upon system conversion or upgrade, the function module signature needs be adjusted on the receiver side, in SAP S/4HANA, or on the caller side. The impact type and the remediation activity depend on the function module only. However, the number of calling partners might help you choose the systems where you make the correction. The list of calling systems is provided as additional information.
Let’s investigate what defines a technical interface.
For the impact analysis of IDoc interfaces, it is important to distinguish their direction (inbound/outbound), message type, IDoc type, extension type, and function module. The number of IDoc interfaces is calculated as the number of unique combinations of these fields.
Web services are primarily defined by the corresponding ABAP proxy, service definition, and direction. The combination of these three fields defines the number of Web service interfaces.
RFC/BAPI calls are defined by direction, function module, and calling program. Function modules are analyzed for inbound calls. For outbound calls, since function modules belong to remote systems, only calling programs are analyzed.
The number of RFC interfaces is calculated as the number of combinations of these three fields.
The SAP BW extractor name (OLTPSOURCE) is the key for counting the number of BW extractors configured in a system.
You will find the list of technical interfaces on the detailed page, under a tab that corresponds to an interface type, by choosing the Interfaces view above the table.
The All Details view provides you with access to all collected data and details at partner level.
Automated Analysis and Cross-Checks with Different Data Sources
While the simplification item catalog focuses on functional changes, the simplification database and ABAP test cockpit focus on custom code changes. There is, however, no single data source for interface-related changes. This makes interface analysis complex and highly dependent on expertise.
SAP Readiness Check now automates this and covers the following steps:
First, it generates a list of ABAP and DDIC objects associated with every “technical” interface. This includes BW extractors, IDoc types, tables, function modules, function groups, packages, and application components. It does not, however, consider extensions, such as user exits or extension points, invoked during interface processing.
Then, it cross-checks these objects with the following data sources:
- Content of SAP Note 2500202 – S4TWL – BW Extractors in SAP S/4HANA.
- Piece lists of simplification items with categories .
- List of ABAP and DDIC objects missing in the target SAP S/4HANA release. This list was produced by comparing combined TADIR entries of all ERP x releases and several latest releases of SAP S/4HANA.
- Internal blocklist (SAP Note 2249880) with forbidden transactions, programs, and function modules.
- External blocklist (SAP Note 2408693) with RFC-enabled function modules forbidden for external inbound calls.
- ABAP test cockpit findings for binary incompatible changes in custom function modules and custom IDoc extensions.
The result of these cross-checks leads to different findings grouped into several impact types.
The interface analysis presents three impact types:
One of the standard ABAP or DDIC objects that are directly associated with an interface or referenced by an associated custom ABAP object is on the simplification list. The identified objects can be categorized as follows:
- Standard objects are checked against the simplification item catalog and the data dictionary of the target SAP S/4HANA release. This includes the cases when an object is missing in the target release, exists but is neither used nor supported, or when a table is partially used in SAP S/4HANA in comparison to SAP ERP.
- Custom objects are checked against the ABAP test cockpit scan results. For the integration analysis, only functional ABAP test cockpit findings are considered.
The latter becomes available once you upload the ABAP test cockpit results to your SAP Readiness Check analysis.
Interfaces with this impact category will either dump with a syntax error due to an access request to a missing object or become instable as the referenced standard object is neither supported nor maintained in SAP S/4HANA.
Furthermore, impacted BW extractors are assigned to one of the following subcategories:
- Working: The data source is available with SAP S/4HANA. There are no restrictions.
- Working with Restrictions: The data source is working in SAP S/4HANA, but with noteworthy restrictions. For example, not all fields are available.
- Obsolete: The data source is no longer relevant after system conversion. BW extractors in this category are legacy extractors.
- Not Working: All data sources in this category are not working in SAP S/4HANA. The following subcategories exist:
- Alternative Exists: The data source is not available with SAP S/4HANA, but an alternative exists. For example, by means of a new extractor or a CDS view.
- Alternative Planned: The data source is not available with SAP S/4HANA yet, but an alternative is planned in the roadmap for future release. For most of the BW extractors assigned to this subcategory, the alternative will be an extractor based on a CDS view. To find out about the status, please check SAP Note 2500202 or create a support incident under the corresponding component.
- No Alternative Exists: The data source is not working in SAP S/4HANA, and there is no alternative planned.
One of the standard programs or function modules associated with an interface is on the internal blocklist and can’t be used with SAP S/4HANA. Interfaces with this impact category will dump on first use due to an access to a blocked object.
One of the objects associated with an interface becomes binary incompatible upon system conversion or upgrade due to a field length extension. These interfaces should not be used without adjustments on the caller or receiver side to avoid possible data inconsistencies.
There are three types of cases:
- An SAP S/4HANA version of an RFC-enabled standard function module and its SAP ERP version are binary incompatible. These function modules are listed in the external blocklist.
- An RFC-enabled custom function module becomes binary incompatible upon system conversion or upgrade. Such custom function modules are identified by the ABAP test cockpit.
- A custom or extension IDoc segment becomes binary incompatible upon system conversion or upgrade. Such IDoc segments are identified by the ABAP test cockpit.
The last two become available once you upload the ABAP test cockpit results to your SAP Readiness Check analysis.
Previous blogs in this blog series:
- Extended Integration Analysis in SAP Readiness Check Is Now Live – Provides a short summary of the extended functionality; areas of improvement, supported interfaces, and an overview of the results.
- Extended Integration Analysis in SAP Readiness Check – Prerequisites and Data Collection – What you need to install and why; what data is collected and transmitted to perform the analysis; and what option you have if you prefer to limit the data submitted for analysis.
Next blogs in this blog series:
- Extended Integration Analysis in SAP Readiness Check – Findings, Next Steps, and Examples – How to interpret and address the findings; we will walk through the next steps proposed by SAP Readiness Check using real examples.