Code Doctors Hours

Above all, it is the business content provided that has made and continues to make SAP standard software so desirable among SAP customers. But it is also the possibility to change SAP software.

And to change it in the way that the individual business and process needs (Intellectual Property, IP for short) require for mapping in the software.

These can be minor program changes or enhancements, such as the addition of a phone number to a report.

However, these can also be function components that have been created from scratch or written by developers to support or handle company-specific business processes, some of which are very finely granular and differentiate between competitors, such as an extensive spare parts management solution or an industry application for quality assurance.

Custom code

Over the last 20 years, an immense volume of so-called custom code based on programming logic methods has been generated at or by SAP customers worldwide.

This program code including the stored rules or logics ultimately bring to life the many, many SAP transactions that are responsible for a functioning SAP software in a company.

Such custom code was created primarily by means of Abap programming (Abap coding). Abap is a programming language (or, in the case of the Abap Workbench, a development environment) that permits both unstructured, structured and object-oriented programming.

New custom code is still being added practically every day. Ten million lines of code, but also sometimes double that for one company alone, are not uncommon.

The number of SAP application developers is certainly large. Corporations sometimes employ hundreds of SAP program developers. And even at a medium-sized company, an application developer division can include a team of 15 or 20 SAP programmers.

Even a little deep look into a company's SAP system or SAP source code will almost immediately display the generated custom code.

This can involve three different transaction types. Firstly, so-called z-transactions and secondly, y-transactions.

In addition, there are programs including transactions with their own namespace (instead of z or y), usually with a company name, which, by the way, have to be reported or registered with SAP.

Test under Hana

The customer need to be able to use precisely this or that custom code created in the long term is obvious. Also in the SAP on Hana world; when using S/4 Hana, Suite on Hana (SoH), BW on Hana or for example the new BW/4 Hana.

For this purpose, it is necessary to analyze the said custom code together with the program rules used or stored, to prepare it for the new Hana database (DB) world, to transfer it by means of a conversion and to test it.

To support this, SAP provides so-called Hana code compliance rules (information on this, for example, in SAP Notes 1912445, 2251947) together with instructions with checklists.

This type of therapy need is rooted in the DB architecture change that SAP has realized with Hana. In simple terms, Hana code processing according to a column-oriented DB table processing including rules works technically differently than with an Any DB (DB2, Microsoft, Oracle) with row/column orientation including indexes - namely not presorted during calls/processing.

This situation has to be taken into account by means of programming additions or assignments that have to be inserted. There are "must-dos" here, otherwise a system simply will not run on the new architecture.

It is also important to note that in order to take advantage of the Hana scope or benefits, various source code enhancements should also be implemented.

Since such optimizations are hardly or very, very difficult to perform manually, it becomes almost impossible to do them manually.

These include, for example: optimization of additional source code constructs in order to exploit the advantages of the Hana database; performance optimization, for example, by means of push-down rules; or: that parts of the business functionality are executed or run on the DB level (filtering, sorting, etc.) - and not on the application layer.

Whether and how the existing custom code (z and y transactions as well as transactions with their own namespace) behaves as desired on the Hana side after a conversion, however, always depends on several circumstances.

Sometimes very deep source code analysis is required to implement successful code therapy.

Because: only in the source code lies factually the truth.

What's more, anyone who starts an on-hana deployment without code therapy runs the risk that the programs will have errors after a move to an on-hana system such as S/4.

Put simply: The program parts in an SAP on Hana system based on custom code no longer function as usual here and there, with sometimes striking negative effects on the business.

According to current experience, the necessary change or conversion of a line of code takes a code expert/SAP developer about ten minutes.

Of course, how many code line changes need to be made as part of a conversion/migration depends on the individual case.

It can be 20, 200 or even 20,000 changes. As a rule, these are mass change jobs. Which logically requires a corresponding use of resources, time and costs.

For major change work, code factories or off-shore programming units spring into action.

For such modification work, automation by means of software naturally makes sense. And not only to minimize the time required or the costs, but also to ensure consistently high quality and corresponding process reliability.

Automation

Furthermore, optimizations can be realized by means of automation.

Ideally, such a conversion tool provides a corresponding analysis functionality with which efforts/milestones can be accurately estimated.

It must also be able to work together with the tools provided by SAP, such as Code Inspector or SQL Monitor, and to supplement or extend them.

With the Code Inspector, for example, it is possible to check SAP repository objects. And it does so according to various criteria. For example, with regard to performance, syntax, security or compliance with naming conventions.

The tool also allows the search for Abap words (so-called tokens). The Code Inspector then provides or lists error messages or warnings.

It is a generic tool that can be quite easily adapted to specific circumstances.

Also, a conversion tool should be based on some kind of meta-model that makes it possible to seamlessly find, read, and examine every line of code and automatically change the code as needed. So that at the end of the day, an error-free code can be used for on-hana usage.

According to the experience of international corporations as well as medium-sized companies, the use of the sophisticated and very powerful Tool for SAP Custom-Code makes it possible to realize even large on-Hana conversions in a period of one to two weeks at the most - including technical integration tests and ready for acceptance by end users.

As a rule, end users do not fully test the functionality after a conversion. Practice shows that customers concentrate on the core business processes.

If there are error rates, they are in the per mille range. If there are systematic errors, these are taken into account in the metamodel.

Affected lines of code can then be quickly regenerated through automation, and the error is corrected.

In addition, the tool provides features that can be used to optimize code. This extends to analyzing whether a custom code can be converted to the SAP standard or, as already explained, whether an existing code can be minimized or relocated (from the application layer to the DB layer) in order to improve a Hana system in terms of performance.

According to experience, there is code lying dormant in SAP systems that is not being used and which - after examination - can be eliminated. This existing unused code can therefore account for up to 60 percent of the total existing code in a system.

This circumstance can be referred to as "technical debt". This technical debt has mostly built up over time due to inefficient development or custom code generation at numerous SAP customers and is still rising.

In the course of an on-hana conversion, you would do well to dismantle them consistently.