In this blog, we’ll cover custom code portfolio which is one of the critical areas for the customer.
Every organisation has specific business requirements that must be addressed by means of custom developed objects, such as reports or tables. First, with fast changing customer needs, requirement changes so quickly that many custom objects and modification to SAP Standard code becomes obsolete. Second, with the new releases or new versions of SAP Software, new and updated objects are provided to customer that render some of custom objects unnecessary and unwanted in the system. This leads to unnecessary high maintenance and operating cost.
Efficient custom code management strategy ensures high quality and scalability of business scenarios thereby reducing TCO and maintenance cost. Getting insights on custom code is one of the biggest challenge customers face on regular basis. To overcome this challenge, customers’ needs to formalize the strategy for managing their custom code efficiently and effectively across the entire lifecycle. This task involves comprehensive analysis, necessary adaptions and optimization of custom code throughout the phases of custom code lifecycle from requirement to retirement as shown in Figure 1.
2. Key Figures
In table1 we have listed down important key figures related to custom code management for consideration by the management.
3. Preparation and Realization Phase and Corresponding Activities
3.1 Preparation Phase: As a part of transition to SAP S/4HANA, first step for concerned stakeholders is to gain transparency on Custom Code and define the scope of custom code management. After scoping next step is to perform custom code analysis to get insights on timeline, phase (before, during or after migration) and effort involved to perform necessary changes.
As a part of custom code analysis activity, customer need to understand the existing custom code, figure out the usage of custom code in business processes and evaluate the impact of necessary changes on custom code. Figure 2 shows the activities which should be performed in Preparation phase.
3.2 Realization Phase: Once the results of the Custom Code Impact Analysis results are obtained, the adjustments on custom code should be discussed with technical, functional and basis leads. To follow and execute, detailed plan should be framed to integrate the adjustments in the development environment and release to production environment throughout the S/4HANA digital journey.
Next step is to retire, improve and adapt the custom code. Figure 3 shows the activities which should be performed in realization phase.
4. Step by Step process
4.1 Gain transparency of Custom code
To understand and plan out custom code activities, customer wants to gain transparency of their custom code, and are interested to gather insights on below mentioned points:
- How many custom code objects are present in landscape?
- How many of those are used in the system?
- How many are unused or obsolete?
- How many are clones which are identical or very similar to SAP standard?
- Which objects are modified?
- Which object requires adjustment from technical and functional standpoint?
- Which object have severe custom code inspection messages?
- Which object must be adapted for SAP S/4HANA?
- Which objects are putting high load on the system?
- Which objects have bad quality code?
4.2 Usage Information – Unused, Obsolete, Modified and Clones
This section covers question 1 to 5. Custom code “Usage” is first measure to be taken care when you plan transition to SAP HANA and SAP S/4HANA. Activate ABAP Call Monitor (SCMON) or Usage and Procedure Logging (UPL) and track what code has been executed in your productive SAP system (before system conversion). Ensure considering important activities scheduled for system such as month-end closing, quarter-end closing, financial closing. SCMON collects the usage data along with the information about the calling business process. Data is collected in the SAP Solution Manager system CCLM can be also used for custom code scoping which captures the information either from SCMON or UPL.
Next measure is to identify the clones of SAP Objects available in customer namespace. Figure 4 shows the screenshot of custom code analysis screen which consists of powerful sub tools such as SAP Interface Analysis, Modification Overview, Reference Analysis, T-Code Similarity that assists in obtaining transparency and maintaining custom code. Use Clone Finder tool (transaction /SDF/CD_CCA) provided by SAP to figure out the list of objects and similarity degree between original SAP object and cloned customer object. Use reference analysis to detect SAP objects like function modules and classes directly called in customer programs and check if the usage can be used, not released or obsolete.
Unused and obsolete custom code has lot of disadvantages listed below:
- Maintenance and Adjustment efforts during change events
- Maintenance and operating cost
- Security and de-stabilization risk during execution
- Testing Effort due to unknown usage behavior of old code
- Data Consistency issues when executing old not used and obsolete code
- Training effort to build and keep up to date development and support skills
- Increase the complexity and build roadblocks on the way to a more simplified landscape
- Documentation effort related to unknown, old and obsolete code
To avoid such issues, ideal way is to decommission the identified objects using Custom Code Lifecycle Management decommissioning Cockpit. Custom Code Lifecycle Management (CCLM) available in solution manager system and provides current status of custom code via dashboards along with availability of lot of tools to manage the custom code.
4.3 Custom Code Adaptations
Questions 6 to 8 are covered in this section. To avoid disruption in business process, any functional issue or dumps while executing the custom code, necessary adaptions should be performed to custom code.
4.3.1 Custom code impacted by software changes
Transactions SPDD, SPAU_ENH and SPAU can be used to identify impacted custom code, which exists as a modification to standard SAP delivered objects and appropriate action should be taken based upon business requirement. This is mandatory step performed in any upgrade or migration. Transaction SPDD is performed during the system conversion whereas all other adaptations take place after the conversion.
4.3.2 Custom code impacted by platform changes
The Code Inspector (transaction SCI) is a tool for checking static ABAP code patterns and DDIC objects under aspects of functional correctness, performance, security, reliability, and statistical information. It consists of 3 main components: check variant, the object set and the inspection.
The ABAP Test Cockpit is successor of SCI which again allows you to run static checks and unit tests for your ABAP programs. It is fully integrated in the ABAP development workbench with high usability for developers and quality experts. To provide transparency of code quality across landscape, it is also integrated with Solution Manager application CCLM.
SAP HANA checks: Figure 5 shows the checks related to SAP HANA. These changes are mandatory changes. In ATC, customer needs to use check variant FUNCTIONAL_DB. For instance, if custom code relies on the database to implicitly sort the data, which is a bad practice, the code will be flagged for correction (e.g. insertion of an “order-by” command) or if the custom code contains a hint for a different database, the hint will no longer be valid.
SAP S/4HANA checks: Figure 6 provides the screenshot of checks related to SAP S/4HANA.
Check Variant S4HANA_READINESS_1909: Variant used to perform the checks in context of SAP S/4HANA migration.
- The Field Extension check finds length conflicts in custom coding such as for material number fields.
- The Search DB Operations check finds write operations on specific database tables. Few Database tables which are simplified or changed with respect to SAP S/4HANA.
- The Search for usages of simplified objects check finds usages of objects stored in Simplification Database.
- The Search for customer’s ABAP dictionary enhancements (append structures, views, customizing includes) which enhance structures, DB views and tables mentioned in Simplification Database.
- The Search for simplified DB tables, which are used as base tables in customer DB views.
- The Search for S/4 related syntax errors, the findings of which are tried and matched to SAP notes describing simplification items.
Simplification Database mentioned above contains a list of simplification items that refer to SAP object simplified in SAP S/4HANA. The simplification list is a collection of simplification items. A simplification item documents differences in application functionality (changed, replaced, removed) between SAP ERP 6.0 and SAP S/4HANA. Each simplification item provides information on changed or removed SAP objects and refers to SAP Note Number that describes the impact and how related custom code can be adapted.
Custom Code Management Tools are included in SAP NetWeaver 7.50 and higher releases. This custom code information includes modifications and enhancements to SAP code as well as customer-owned main objects, respective where-used list information and possibly available usage information.
Upload: Simplification database can be downloaded as ZIP file from SAP Service Marketplace. This zip file can be imported using program SYCM_UPLOAD_SIMPLIFIC_INFO into SAP Netweaver 7.5 or higher system.
Download: Custom Code Analyzer detects all the references/extensions/modifications to SAP Objects in custom code. Program SAPRSEUB can be used to update the where used list index in the system. Schedule the Program SYCM_DOWNLOAD_REPOSITORY_INFO in the managed system to collect or download the result of custom code analysis. Custom Code Analysis Result file can be imported into SAP Netweaver 7.5 system using program SYMC_UPLOAD_REPOSITORY_INFO.
Outcome: Execute transaction SYCM or Execute program SYCM_DISPLAY_SIMPLIFICATIONS to obtain the list of objects that are affected by simplification items into categories such as syntactically and semantically incompatible change, existing functionality not recommended or supported anymore, usage of new functionality is mandatory. This list is known as custom code migration worklist.
4.4. Performance Tuning
Performance aspect can be taken care after the conversion, once the system is stable after the Golive. From performance point of view, customers are interested to get insights on below information:
- What are the most expensive and most frequently executed SQLs?
- Which of the statements are contributing high to the system in terms of total execution time and database time?
- What is the driving transaction or program for expensive SQL?
SAP has provided tools: SCI/ATC, SQLM, SWLT to answer the above highlighted questions.
SCI/ATC: Use check variant PERFORMANCE_DB to figure out the performance issues in custom code. The ABAP Code Inspector can perform a whole range of static performance checks such as:
- SELECTS in LOOPs across modularization units
- Problematic SELECT * statements (where less than a certain percentage of the fields are subsequently used)
- Find SELECT…FOR ALL ENTRIES statements
Since these are static checks hence to get the real picture of system, customer should use SQLM transactions to obtain the current status of productive system.
SQL Monitor (SQLM) and SQL Performance Tuning Worklist (SWLT)
SQL Monitor allows to get performance data for all SQLs executed in your productive system. This is a powerful tool for capturing the SQL Profile of a system or transaction. “SQL profile” refers to aggregated data about all SQL requests executed in the context of a business process, program, application, etc. Result set includes how often each request was executed, which tables were accessed, the total runtime, how many records were fetched, and more.
Normally after the successful migration, customer analyze and start thinking about optimizing the business processes by using code push down techniques of SAP HANA, like the Core Data Services (CDS) and ABAP-managed database procedures (AMDP) implemented by the native HANA language SQL script. Find below the screenshot of SQL Monitor in Figure 7:
After the initial setup of the SQL Monitor, you can activate or deactivate the monitor. When you launch it, it displays the current status. You can activate it for all application servers or for specific application servers. You can also specify an expiration date and an upper limit for the number of records. You can specify several filter criteria. For instance, you can filter by development objects such as package, object type and name, or by request (i.e. transactions, Application), resp. request type (i.e. URL, RFC, Report), concrete database tables.
Finally, for performance optimization it makes sense to combine the results of both static source code analysis (carried out via the ABAP Test Cockpit / Code Inspector) and the SQL Monitor runtime data. This correlation can be done in another new tool, the SQL Performance Tuning Work list shown in Figure 8.