SAP Certification: Tips to consider and Tricks to avoid
This year, we have recently gone through the annual SAP certification process of our Xiting software solutions. There is some effort involved and certain benefits gained from it, but again I came to realize that the prevention of huge efforts or even show-stoppers and also the maximization of the benefits happen long before the certification process. This is particularly true for 3rd party vendor code, which is neither customer code nor SAP code and often goes unchecked into customer systems.
I would like to share some of the things to check when considering (uncertifiable) software solutions. The ideal would be to only consider certified solutions, because by doing so, many of these problems would not accumulate in your SAP systems.
Upward and downward compatibility
For achieving what is Xiting’s current SAP HANA certification, the software must be certified on SAP_BASIS release 7.56, HANA 2021. However many customers are still on 7.31 or even older, which was released 10 years ago and is an important milestone for the ALV development framework. On which release to develop and how to test the upward and downward compatibility is a real challenge. Upward compatibility is important though for new customer sales. Downward compatibility equally so for the recurring income of software maintenance. So, the software must be developed upwardly compatible and also tested on it. Same for backwards compatibility.
Tip: in addition to asking for SAP certification, ask vendors for their test plans / compatibility before evaluating the software, as these are sometimes show-stoppers for your release lifecycle plans.
Use of undocumented objects and component neutrality
Using dictionary objects which have nice names on the development system can be a significant minefield of subsequent problems on foreign systems with different component versions. So much that it might even be possible that the software can never be installed again without having to delete everything first. Reason is that undocumented functions and non-existing objects can change or be deleted at any point in time and cause different follow-on affects depending on the release and how often is an import attempted.
Tip: a component neutral transport should at most give warnings about nametabs and import sequences which wait for other steps. No errors.
Direct updates to SAP tables
This is not something a developer would do voluntarily, unless the sales pressure to provide a function is greater than the common sense to bypass released APIs to the data model. Or the developer in fact does not respect the data model of the foreign package and potential changes of it. In both cases, this is a very bad indication of the product management of the solution and development coordination. If you find one such direct update, then you typically find several, as well as backdoors in an attempt to hide them from code reviews.
Tip: use the SAP SCI CVA code scanner to detect SQL injections from foreign packages. Without a green flag from the CVA, the solution will be uncertifiable and cannot be installed in any SAP hosted system. If it causes program errors or corrupted data, SAP will not help you to correct it. A quick check can be done by using the SE11 where-used-list function on tables such as USR02, AGR_1251 and DEVACCESS etc.
HANA Readiness and CVA scans
The HANA Readiness and CVA scans of transaction SCI are very useful to detect issues early on and should be used regularly to prevent a backlog and big worklist of issues to correct. The more customers using the solution and the longer the backlog, the more the disruption caused for the solution development and lifecycle management. This leads to more required corrections with increasing dependencies, which at some point can only be cleared by a Support Package or Release Upgrade.
Tip: distinguish between bug corrections and feature requests and the release compatibility compared to the priority. If you have the HANA Readiness and CVA adjustments out of the way from the start, bug corrections and even feature requests can often be delivered on the same day by the vendor.
Use of scripting tools, screen recordings and e-CATTs
In the absence of APIs or in case of not using them, the temptation to use various forms of scripting for the UI objects increases. This is a trap though as SAP will and does change or replace UIs regularly and in the case of many applications, it is impossible to script all dialog messages. For example, PFCG package has 6 message classes, more than 1000 messages and even more dynamic dialogs and search helps for the fields of 4000 objects. So, creating a release independent script for all constellations and possible errors is nearly impossible and error prone to maintain.
Tip: as of SAP release 7.50, API methods are provided for PFCG business functions, so there is no valid argument in favor of scripting tools anymore.
No template roles or SU24 authorization proposals
At first, this appears to be uncritical, even if the vendor recommends using SAP_ALL for the users of the application, including technical users such as jobs, RFCs and webservices. At least, these will not have authorization problems. However, your problem will be that you have no idea or control over which functions the application calls and no documentation via the where-used-lists of authorizations to describe what the applications actually do. So, the vendor can tell you about features of the application, but under which conditions they work and what they really do, can only be evaluated by reading all the source code yourself.
Tip: insist on template roles and ideally SU24 based authorization proposals to have where-used-list references.
Attempts to hide license routines and critical statements
Any vendor selling software will want to somehow protect themselves from being copied. Particularly, from being copied by a competitor. There are options for cleverly designed license keys, but unfortunately, there is also the temptation to hide the code or generate it dynamically at runtime. Attempts to hide source code using the obsolete ABAP statement *@#@@[SAP] does not work anymore in higher releases, but the presence of it is a bad omen. Alternately, the ABAP statements GENERATE SUBROUTINE or INSERT REPORT, occasionally found to create code at runtime from (external) code sources.
Tip: with the following simple but powerful program you can detect such programs:
REPORT z_scan_for_hidden_includes.
INITIALIZATION.
DATA: source(255) OCCURS 0,
prog like trdir-name.
SELECT name FROM trdir INTO prog.
READ REPORT prog INTO source.
IF sy-subrc NE 0.
WRITE:/ ‘If sy-subrc = 8 then new kernel hardcoding method is like SAPMSYST.’.
WRITE:/ ‘If sy-subrc = 4 then the old # keyword is still in use.’.
WRITE:/ sy-subrc,prog.
ENDIF.
ENDSELECT.
