Dear All,
This is the fourth blog in the series. Links to the other blogs in the series are provided at the end.
In this blog, we will explore how to deal with findings and will follow the next steps proposed by SAP Readiness Check using real examples.
We will start by investigating each impact type, with the help of a few real-life examples.
Functionality Unavailable
In short, this impact type tells us that some part of an interface belongs to or depends on functionality that is either unavailable or used differently in the target SAP S/4HANA release.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Functionality Unavailable. In the Details column, you will find corresponding simplification items, business impact notes, or SAP Notes reported by the ABAP test cockpit. You might need to redesign and/or rebuild the interface, or even remove it completely from the system if it becomes obsolete in SAP S/4HANA.
If required, create a separate support incident under the respective component for each BW extractor assigned to the subcategory Not Working (Alternative Planned or No Alternative Exists). This helps you find out if old extractors can be released for you, or if and when a replacement is planned. If the replacement is not available at the time you need it, you may need to create a project-specific development to extract the required data.
Let’s illustrate this now with a few examples.
Example 1. A BW extractor is not supported in the target SAP S/4HANA release.
The analysis of BW extractors now goes beyond the content of SAP Note 2500202 and includes the analysis of data sources against the piece lists of simplification items.
You may still start with SAP Note 2500202, which refers to SAP Note 2543543 for IS-Retail-related BW extractors.
Or you may go via the simplification item S4TWL – Article Hierarchy identified by SAP Readiness Check since the views V_CMMD_CDT1_BW and V_CMMD_CDT1T_BW are both part of its piece list. The corresponding note, SAP Note 2368680, refers you to the same SAP Note 2543543 – Restrictions for BW extractors relevant for S/4HANA in the area of Retail.
Sometimes that is just another way to get to the same information, and sometimes it helps identify an impact that is not mentioned in the SAP Note 2500202.
Regarding the next steps, as mentioned on the Learn More panel, you should familiarize yourself with SAP Note 2543543 and, if necessary, open a support incident to get advice from SAP.
Example 2. Change of BW extractor behavior due to a change in a data source.
In this example, the BW extractor is and therefore not mentioned in SAP Note 2500202. The data source, however, is a standard table, which is no longer maintained in SAP S/4HANA. As the table still exists, technically the BW extractor still works.
The referenced SAP Note 2328419 (S4TWL-Data Model in Oil and Gas Inventory management) seems to be from the oil and gas industry, but in fact, the SAP Note talks about the data model change that is very much relevant in this case.
The SAP Note provides a technical solution to the problem, but, as usual, start with understanding the role of this BW extractor in your future SAP S/4HANA implementation and determine whether it is still needed. This should be done before you start with technical adjustments.
Example 3. An object does not exist in the target SAP S/4HANA release.
This analysis is identifying objects that existed in a standard SAP ERP 6 system (within any Enhancement Package) and that do not exist in the latest SAP S/4HANA releases. These objects are often not part of any simplified functionality and but might still impact some interfaces.
The example above contains an RFC-enabled standard function module that was not found in the target SAP S/4HANA release. As a result, the call will fail after a system conversion.
First, it is important to notice that the Usage column indicates infrequent appearance of these calls based on the runtime statistics for the past 15 months.
Second, we must check the All Details view to get details about the caller systems. The intent of this additional detail is to help provide context to you, so that you can decipher where and how the interface is used within your business process logic.
In such a case, when no additional information is available about an object that is missing in the target release, the best approach is to identify the usage of the object in the source system. You might need to turn to your internal documentation or activate and analyze runtime statistics in the calling system. ABAP call monitor (transactions SCMON and SUSG) can help you greatly here. For instance, the ABAP call monitor can determine in the context of which transactions, reports, RFC, or Web service calls an ABAP object was executed. With this data, you can conclude the transaction or background job initiating the RFC call.
Example 4. Preconfigured (shipped by SAP) interfaces marked as impacted.
There are going to be findings for which you do not need to take any action. A good example is a group of preconfigured Web services that belong to deprecated functionality of an industry solution that you do not use.
The usage frequency should help you identify those that you use. It might happen, however, that the usage statistics are not available for a particular interface (as in the example above).
In such cases, where usage frequency is not available and you are uncertain whether you use the interface, you will have to turn back to your internal documentation and/or ABAP call monitor (as in the previous example).
However, if you are sure that IS-H is not part of your solution, you may ignore these findings.
Blocked
In short, this impact type indicates that at least one of the ABAP objects required for an interface is restricted for use in SAP S/4HANA.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Blocked and find out if identified blocked objects can be substituted. Search for simplification items in the functional area the object belongs to. You might need to redesign and/or rebuild the interface, or even remove it completely from the system if it becomes obsolete in SAP S/4HANA.
Example 5. An RFC-enabled function module on a blocklist.
In this example, the function module WRB_RFC_VENDOR_GET_CONTACTDATA cannot be used in SAP S/4HANA. With the Details field highlighting three data sources confirming the status, there is enough information to act upon.
First, the function module is mentioned in the S-Item S4TWL – Retail iViews, which describes corresponding simplified functionality. This triggered the Functionality Unavailable impact type classification.
Second, the function module appeared on the internal blocklist, therefore it cannot be called even internally within SAP S/4HANA. This triggered the Blocked impact type classification for the interface.
Third, the function module appeared on the external blocklist, which blocks external RFC calls to this function module. The resulting Serialization Issue impact type was, in this case, overwritten by the Blocked impact type classification, since the internal blocklist has a wider scope than the external blocklist.
There is nothing we can do about blocked objects. Effectively, they must be treated as if they do not exist in SAP S/4HANA. So, your next step would be to familiarize yourself with the referenced simplification item and the corresponding SAP Note describing the business impact. It might not always specify the API to use instead, but it might direct you to the successor functionality that should have its own set of integration options.
Serialization Issue
In short, this impact type marks interfaces that, if being used without any change, lead to a serialization issue. Example 6 below will illustrate what this means.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Serialization Issue.
For Remote Function Call (RFC) interfaces, note that the impact is only relevant for external inbound calls. Perform the following steps:
Alternatively, familiarize yourself with the fast RFC serialization, which might offer an easier solution if a high number of function modules needs to be corrected. For more information, see SAP Note 2315100 and How to Profit from FAST RFC Serialization.
For IDoc interfaces, rework data types behind custom fields. For example, change the associated data element MATNR to MATNR18 to restore field length and, if required, add a new field with a long material number using data element MATNR. For more information, see SAP Note 2218350.
Example 6. IDoc segment becomes binary incompatible.
Binary incompatibility means the following in this context. The field length extension of certain data elements and domains might cause changes to the overall IDoc structures’ length. This leads to a situation where the IDoc definition on the sender side (which stayed the same in our example) differs from the IDoc definition on the receiver side (which gets changed during system conversion). This means that the sending system converts the IDoc data into a single string for transmission (serialization process) using one schema, while the receiver converts it back to an IDoc structure (deserialization process) using another schema. The result is that the data in the IDoc will be misaligned and therefore it will not contain the same information. These schemas are called binary incompatible in this case.
Here are a few screenshots to illustrate the result.
Case 1.
Sometimes IDoc structure definitions are enhanced as part of a system conversion.
For instance, in the case that a system with long material number, which extends the field length to 40 characters, sends an IDoc to a system expecting a material number to consume only 18 characters, the remaining 22 characters will be distributed across subsequent fields.
In the opposite direction, a system that expects 40 characters for a material number will concatenate values of several fields until it fills the material number field with 40 characters.
Case 2.
Sometimes, the IDoc structures stay the same upon system conversion but become inconsistent with the data element definition.
In this example, an SAP S/4HANA system expects 18 characters for a material number field. The MATNR data element though has 40 characters in the DDIC.
Here, everything depends on whether you use leading zeros or not.
If you do, then IDocs from the system with the 40-character data element will contain 18 leading zeros.
If you don't, the data transmission will be performed correctly, and serialization and deserialization processes will run “based on the same rules”. This continues until the IDoc structure gets refreshed to become consistent with the DDIC definition of the MATNR data element. When that will happen is hard to .
In all cases, the IDoc structure must be restored to its initial state. The process is well described in SAP Note 2218350. In short, you will need to replace extended data elements (like MATNR) with their shorter counterpart versions (like MATNR18) to restore the overall length of the IDoc structure. If you spot the problem in a standard IDoc segment, please open an SAP incident so that we can investigate and remediate it, if required. And if you need a long field in the IDoc, please add it to the end of the IDoc segment or, if the segment is already full, to a new one.
Example 7. A custom RFC-enabled function module becomes binary incompatible.
The very same situation of binary incompatibility, as described in example 6, can occur with custom RFC-enabled function modules. Field length extension might cause some function module interfaces to change in a way that makes them incompatible with their preconversion definition.
To restore these interfaces, these function modules need to be adjusted by replacing data elements with their backward-compatible versions (see example 6).
Example 8. A standard RFC-enabled function module becomes binary incompatible.
Some standard remote-enabled function modules have different, binary incompatible interface definitions while having the same name in SAP ERP and SAP S/4HANA. To avoid possible data inconsistencies, these function modules were identified and added to the external blocklist.
If you wish to override the blocklist and enable the remote-enabled function module to be callable by external clients, please refer to SAP Note 2408693.
Once the interfaces identified as impacted are analyzed and adjusted or removed, continue with testing the most critical interfaces.
For more information, see:
Previous blogs in this blog series:
This is the fourth blog in the series. Links to the other blogs in the series are provided at the end.
In this blog, we will explore how to deal with findings and will follow the next steps proposed by SAP Readiness Check using real examples.
We will start by investigating each impact type, with the help of a few real-life examples.
Functionality Unavailable
In short, this impact type tells us that some part of an interface belongs to or depends on functionality that is either unavailable or used differently in the target SAP S/4HANA release.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Functionality Unavailable. In the Details column, you will find corresponding simplification items, business impact notes, or SAP Notes reported by the ABAP test cockpit. You might need to redesign and/or rebuild the interface, or even remove it completely from the system if it becomes obsolete in SAP S/4HANA.
If required, create a separate support incident under the respective component for each BW extractor assigned to the subcategory Not Working (Alternative Planned or No Alternative Exists). This helps you find out if old extractors can be released for you, or if and when a replacement is planned. If the replacement is not available at the time you need it, you may need to create a project-specific development to extract the required data.
Let’s illustrate this now with a few examples.
Example 1. A BW extractor is not supported in the target SAP S/4HANA release.
The analysis of BW extractors now goes beyond the content of SAP Note 2500202 and includes the analysis of data sources against the piece lists of simplification items.
You may still start with SAP Note 2500202, which refers to SAP Note 2543543 for IS-Retail-related BW extractors.
Or you may go via the simplification item S4TWL – Article Hierarchy identified by SAP Readiness Check since the views V_CMMD_CDT1_BW and V_CMMD_CDT1T_BW are both part of its piece list. The corresponding note, SAP Note 2368680, refers you to the same SAP Note 2543543 – Restrictions for BW extractors relevant for S/4HANA in the area of Retail.
Sometimes that is just another way to get to the same information, and sometimes it helps identify an impact that is not mentioned in the SAP Note 2500202.
Regarding the next steps, as mentioned on the Learn More panel, you should familiarize yourself with SAP Note 2543543 and, if necessary, open a support incident to get advice from SAP.
Example 2. Change of BW extractor behavior due to a change in a data source.
In this example, the BW extractor is and therefore not mentioned in SAP Note 2500202. The data source, however, is a standard table, which is no longer maintained in SAP S/4HANA. As the table still exists, technically the BW extractor still works.
The referenced SAP Note 2328419 (S4TWL-Data Model in Oil and Gas Inventory management) seems to be from the oil and gas industry, but in fact, the SAP Note talks about the data model change that is very much relevant in this case.
The SAP Note provides a technical solution to the problem, but, as usual, start with understanding the role of this BW extractor in your future SAP S/4HANA implementation and determine whether it is still needed. This should be done before you start with technical adjustments.
Example 3. An object does not exist in the target SAP S/4HANA release.
This analysis is identifying objects that existed in a standard SAP ERP 6 system (within any Enhancement Package) and that do not exist in the latest SAP S/4HANA releases. These objects are often not part of any simplified functionality and but might still impact some interfaces.
The example above contains an RFC-enabled standard function module that was not found in the target SAP S/4HANA release. As a result, the call will fail after a system conversion.
First, it is important to notice that the Usage column indicates infrequent appearance of these calls based on the runtime statistics for the past 15 months.
Second, we must check the All Details view to get details about the caller systems. The intent of this additional detail is to help provide context to you, so that you can decipher where and how the interface is used within your business process logic.
In such a case, when no additional information is available about an object that is missing in the target release, the best approach is to identify the usage of the object in the source system. You might need to turn to your internal documentation or activate and analyze runtime statistics in the calling system. ABAP call monitor (transactions SCMON and SUSG) can help you greatly here. For instance, the ABAP call monitor can determine in the context of which transactions, reports, RFC, or Web service calls an ABAP object was executed. With this data, you can conclude the transaction or background job initiating the RFC call.
Example 4. Preconfigured (shipped by SAP) interfaces marked as impacted.
There are going to be findings for which you do not need to take any action. A good example is a group of preconfigured Web services that belong to deprecated functionality of an industry solution that you do not use.
The usage frequency should help you identify those that you use. It might happen, however, that the usage statistics are not available for a particular interface (as in the example above).
In such cases, where usage frequency is not available and you are uncertain whether you use the interface, you will have to turn back to your internal documentation and/or ABAP call monitor (as in the previous example).
However, if you are sure that IS-H is not part of your solution, you may ignore these findings.
Blocked
In short, this impact type indicates that at least one of the ABAP objects required for an interface is restricted for use in SAP S/4HANA.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Blocked and find out if identified blocked objects can be substituted. Search for simplification items in the functional area the object belongs to. You might need to redesign and/or rebuild the interface, or even remove it completely from the system if it becomes obsolete in SAP S/4HANA.
Example 5. An RFC-enabled function module on a blocklist.
In this example, the function module WRB_RFC_VENDOR_GET_CONTACTDATA cannot be used in SAP S/4HANA. With the Details field highlighting three data sources confirming the status, there is enough information to act upon.
First, the function module is mentioned in the S-Item S4TWL – Retail iViews, which describes corresponding simplified functionality. This triggered the Functionality Unavailable impact type classification.
Second, the function module appeared on the internal blocklist, therefore it cannot be called even internally within SAP S/4HANA. This triggered the Blocked impact type classification for the interface.
Third, the function module appeared on the external blocklist, which blocks external RFC calls to this function module. The resulting Serialization Issue impact type was, in this case, overwritten by the Blocked impact type classification, since the internal blocklist has a wider scope than the external blocklist.
There is nothing we can do about blocked objects. Effectively, they must be treated as if they do not exist in SAP S/4HANA. So, your next step would be to familiarize yourself with the referenced simplification item and the corresponding SAP Note describing the business impact. It might not always specify the API to use instead, but it might direct you to the successor functionality that should have its own set of integration options.
Serialization Issue
In short, this impact type marks interfaces that, if being used without any change, lead to a serialization issue. Example 6 below will illustrate what this means.
When you choose Learn More in the top right-hand corner, a side panel appears with the following recommendation:
Check all interfaces with the impact category Serialization Issue.
For Remote Function Call (RFC) interfaces, note that the impact is only relevant for external inbound calls. Perform the following steps:
- Ensure that the identified RFC interface is inbound and that the call comes from an external system; otherwise consider the finding a false-positive.
- For standard function modules, follow the procedure described in SAP Note 2408693. Depending on the feedback from SAP, an interface might be exempted as an exception.
- For custom function modules, adjust the signature of the function module either on the remote side or on the SAP S/4HANA side to restore binary compatibility.
Alternatively, familiarize yourself with the fast RFC serialization, which might offer an easier solution if a high number of function modules needs to be corrected. For more information, see SAP Note 2315100 and How to Profit from FAST RFC Serialization.
For IDoc interfaces, rework data types behind custom fields. For example, change the associated data element MATNR to MATNR18 to restore field length and, if required, add a new field with a long material number using data element MATNR. For more information, see SAP Note 2218350.
Example 6. IDoc segment becomes binary incompatible.
Binary incompatibility means the following in this context. The field length extension of certain data elements and domains might cause changes to the overall IDoc structures’ length. This leads to a situation where the IDoc definition on the sender side (which stayed the same in our example) differs from the IDoc definition on the receiver side (which gets changed during system conversion). This means that the sending system converts the IDoc data into a single string for transmission (serialization process) using one schema, while the receiver converts it back to an IDoc structure (deserialization process) using another schema. The result is that the data in the IDoc will be misaligned and therefore it will not contain the same information. These schemas are called binary incompatible in this case.
Here are a few screenshots to illustrate the result.
Case 1.
Sometimes IDoc structure definitions are enhanced as part of a system conversion.
For instance, in the case that a system with long material number, which extends the field length to 40 characters, sends an IDoc to a system expecting a material number to consume only 18 characters, the remaining 22 characters will be distributed across subsequent fields.
In the opposite direction, a system that expects 40 characters for a material number will concatenate values of several fields until it fills the material number field with 40 characters.
Case 2.
Sometimes, the IDoc structures stay the same upon system conversion but become inconsistent with the data element definition.
In this example, an SAP S/4HANA system expects 18 characters for a material number field. The MATNR data element though has 40 characters in the DDIC.
Here, everything depends on whether you use leading zeros or not.
If you do, then IDocs from the system with the 40-character data element will contain 18 leading zeros.
If you don't, the data transmission will be performed correctly, and serialization and deserialization processes will run “based on the same rules”. This continues until the IDoc structure gets refreshed to become consistent with the DDIC definition of the MATNR data element. When that will happen is hard to .
In all cases, the IDoc structure must be restored to its initial state. The process is well described in SAP Note 2218350. In short, you will need to replace extended data elements (like MATNR) with their shorter counterpart versions (like MATNR18) to restore the overall length of the IDoc structure. If you spot the problem in a standard IDoc segment, please open an SAP incident so that we can investigate and remediate it, if required. And if you need a long field in the IDoc, please add it to the end of the IDoc segment or, if the segment is already full, to a new one.
Example 7. A custom RFC-enabled function module becomes binary incompatible.
The very same situation of binary incompatibility, as described in example 6, can occur with custom RFC-enabled function modules. Field length extension might cause some function module interfaces to change in a way that makes them incompatible with their preconversion definition.
To restore these interfaces, these function modules need to be adjusted by replacing data elements with their backward-compatible versions (see example 6).
Example 8. A standard RFC-enabled function module becomes binary incompatible.
Some standard remote-enabled function modules have different, binary incompatible interface definitions while having the same name in SAP ERP and SAP S/4HANA. To avoid possible data inconsistencies, these function modules were identified and added to the external blocklist.
If you wish to override the blocklist and enable the remote-enabled function module to be callable by external clients, please refer to SAP Note 2408693.
Once the interfaces identified as impacted are analyzed and adjusted or removed, continue with testing the most critical interfaces.
For more information, see:
- SAP Note 2500202 (Central SAP Note for BW extractors in SAP S/4HANA).
- SAP Note 2416705 (More information about blocked Remote Function Calls).
- SAP Note 2215424 (General information about field length extension of material numbers).
- SAP Note 2218350 (Field length extension of material numbers in IDoc interfaces and/or Application Link Enabling).
- SAP Note 2781766 (Enabling the export of the ABAP test cockpit check results for SAP Readiness Check).
- If you are using SAP Landscape Transformation Replication Server, refer to SAP Note 2755741 (Potential impact of the replication from SAP Landscape Transformation Replication Server during system conversions) and Compatibility Views and SAP Landscape Transformation Replication Server (explaining the impact of compatibility views on the replication in detail).
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.
- Extended Integration Analysis in SAP Readiness Check – Impact Analysis in Detail – How the new Integration check analyzes your system; which data sources are considered; how impact types are defined, and what they mean from a practical perspective.
- SAP Managed Tags:
