In the first lesson, we examined the different types of exits that were traditionally implemented by customers to enhance functionality with delivered SAP applications. SAP S/4HANA uses completely redefined applications based on the consumer-grade UX experience (SAP Fiori, to be discussed later), and also new data models and code, so we can assume that some extensions are no longer necessary. This could be because the original functional purpose of the extension is now covered by SAP S/4HANA standard functionality, or changed business processes render the functionality no longer necessary. Either way, the code contained in these exits should be systematically removed from the system. But how do we find and evaluate that code? SAP recommends the following approach:
- Collection and aggregation of extension usage data
- Determination of extensions that can be removed via custom code analysis
- Preparation of backup and restoration procedure
- Verification of desired app functionality with extension removed
- Deletion of extension during system conversion
Collection And Aggregation of Extension Usage Data
Two tools have been created to help project teams with the collection of extension usage data. Either one can be used. The first is Usage and Procedure Logging (UPL) and the second is the ABAP Call Monitor (transaction code SCMON). Both collect information regarding the execution of ABAP code in whichever form (that is, class methods, function modules) and both provide information on what ABAP code is being executed and in what context. ABAP Call Monitor is the newer of the two tools and goes one step further by providing information on the caller of the ABAP code. However, it is discouraged to use both tools simultaneously (to minimize potential system performance issues), so if UPL is currently being used and the customer wants to continue to do so, that is fine. It is important to make sure that the customer uses the chosen tool in the production system. Actual usage of the extension by end users is the determining factor here. Note that both tools are capable of integrating their data with Solution Manager. As a general rule, SAP recommends running the preferred tool for 6–18 months, which should include at least one year-end closing.
Once usage data has been collected transaction code SUSG can then be used to both aggregate and manage this data. This step is important since data collected via transaction code SCMON is deleted after a short period of time.
Determination of Extensions That Can Be Removed via Custom Code Analysis
Here, the project team has two options to perform custom code analysis. The first is to use the SAP Fiori app Custom Code Migration. The app can be found on a newly converted sandbox SAP S/4HANA system that is used for testing (more on that topic in a moment). If a sandbox SAP S/4HANA system is not available yet, the app can be found and used from the SAP Business Technology Platform, ABAP environment and executed against an SAP ERP system via RFC and the Cloud Connector. The second option is to use the ABAP test cockpit, available as part of ABAP development tools for Eclipse. One advantage of the SAP Fiori app is that based on the usage statistics collected by Usage And Procedure Logging (UPL) and ABAP Call Monitor, it can identify unused extensions. These unused extensions can then be removed during the system conversion (see the section, Deletion of Extension During System Conversion).
Preparation of Backup and Restoration Procedure
It is understandable that there may be legitimate concerns about deleting unused code especially if there exists the possibility that it may be needed again in the future. As result a backup and restoration procedure can be designed and adopted by the project team. There are several approaches that can be considered. One would be a separate ABAP system specifically provisioned for backup. Another would be a third-party product backup system. While either option can be adopted one potential factor to be considered is the cost of maintaining (or purchasing) a system dedicated for backup purposes. To address this concern SAP has created the "Git-enabled Change and Transport System" (gCTS) option for customers to consider. It uses an external Git repository to store unused code. For more information on custom code backup with gCTS see "How to backup custom code with gCTS". An important point to remember is that irregardless of which backup approach is adopted, if a restore is needed, the restore procedure must include ABAP checks on the code (ATC must be used for this purpose) and testing of the code. Once these checks and tests are concluded and no problems are discovered, then the restored enhancement can be transported to production.
Verification of Desired App Functionality with Extension Removed
This would be a normal test executed by the quality assurance team to make sure that there are no technical issues with the extension removed.
Deletion of Extension During System Conversion
The previously mentioned SAP Fiori app Custom Code Migration is able to generate a transport request containing all enhancements to be deleted. During the conversion process, the Software Update Manager tool prompts for the transport request and relevant development objects are deleted.
