Vanilla vs customized SAP systems

Vanilla is the term used when computer software (also other computing related things like hardware) are not customized from their original form, i.e., they are used without any customizations or updates applied to them (see wikipedia).

A vanilla SAP system refers to a standard installation of the SAP software without any additional customizations or enhancements. It is also known as a standard SAP system or a SAP system without any modifications.

When an organization decides to implement an SAP system, they can either choose to use the vanilla SAP system or customize it to meet their specific needs. The vanilla SAP system can be flexible and configurable, in a way that to some extent it meets the requirements of the organization without requiring significant customization. However, it is not uncommon for the organizations to require additional functionality that are not provided by the standard system.

In such cases, the organizations may choose to customize the vanilla SAP system by developing custom programs, reports, and interfaces, or by implementing add-on modules or third-party software solutions. However, customizing the SAP system can be a complex and expensive process that requires significant resources and expertise.

In summary, a vanilla SAP system is a standard installation of the SAP software without any customizations or enhancements. It provides all the standard modules and features that are offered by SAP and can be configured to meet the requirements of different businesses to some extent. However, companies may choose to customize the system to meet their specific needs, although this can be a complex and costly process.

In an era of cloud computing when the organization are moving to the cloud it becomes important to analyze into what extend their SAP installation are customized. Heavy SAP customization can be challenge for the cloud. Mostly because of the customization may not be compatible with the cloud environment or the cloud platform on which the SAP instance is being hosted. In addition, there might be a security and compliance issues, impact on scalability and performance, and maintenance and support challenges. It is important to carefully evaluate the impact of customization when moving SAP to the cloud and plan accordingly to minimize any potential issues.

BW/4HANA: Custom ABAP code in transformations

In BW/4HANA there are some changes with respect to a usage of ABAP code in transformations. In classic BW there are areas called "1st and 2nd global declarations" (*$*$ begin of global ... *$*$ end of global) available where to place ABAP routines. Normally we can use both of the global declaration areas in the classic BW. It only makes a difference in case that the ABAP code shall be able to be reached globally in the transformation we go for 1^st global area. The 2^nd one is originally used for the transformations which are migrated from an update or transfer rules.

In the BW/4HANA only the first global area is respected. The 2nd global area is not supported by the BW/4HANA – it no longer exists. In reality there is just one global area – called global part but the global part is not supposed to be used, it is optional. All custom code shall be placed in the local part of the routine. The ABAP routine is a methods of a local ABAP class that consist of a predefined definition and an implementation area.

For existing transformations this also means that the transformation that uses 2nd global area won’t be displayed in the Eclipse - in the BW Modeling tools. SAP GUI will be opened instead. Then a manual migration needs to happed in the SAP GUI and code from 2nd global area must be moved to 1st global area in order to migrate such transformation to the BW/4HANA.

Another point is that existing custom ABAP code that shall in BW/4HANA must be ABAP OO compatible. Means statements that are non-compatible with ABAP OO coding needs to be removed and the code must be refactored to be the ABAP OO correct. Examples of non-compatible things can be: obsolete statements used in the code like internal tables with header, includes, etc. Again such transformations will be opened in SAP GUI to make required changes.

No need to mention that all this is only valid in case the transformation is being executed by ABAP runtime. This is to be selected in Runtime Properties of the transformation. Of course there can be routines in SAP HANA SQLScript in case the transformation is being executed by SAP HANA runtime.

More information:

Difference between 1st and 2nd global declarations in BW routines

2654109 - Conversion of ABAP/AMDP routines/exits in SAP BW/4HANA to the processing in Eclipse

2639435 - Transformations are opened in SAP GUI instead of in Eclipse

2462639 - BW4SL - Interfaces and Customer-Specific ABAP Development

ABAP Routines in Transformations

Transformation code in INCLUDE: how to perform where-used?

Here let’s have following scenario. ABAP logic for Transformation (TRFN) is encapsulated in ABAP INCLUDE and it needs to be changed. Before a change is done it is beneficial to check what are all TRFN where the ABAP include is used. In case there are several TRFN and change is not supposed to be done for all of them an issues can came.

Normally as the INCLUDE it would be regular ABAP one there is a Where-Used functionality available in t-code like SE38/SE80. However it doesn’t work as the code of TFRN is stored in generated report (GP*).

What actually works in case of the GP* reports is Syntax Check functionality available as well as in the SE38/SE80. Via the Check the list of the all TRFN is available.

Scanning custom ABAP code for security risks

Similarly as SAP is during security checks of the standard software that they are delivering they offering tools enabling doing of the same for customers. There is a tool called "SAP NetWeaver Application Server add-on for code vulnerability analysis" or also known as Code Vulnerability Analyzer (CVA).  The tool carries out a static analysis of the custom ABAP source code in order to reveal possible security risks.

The tool is available in NetWeaver ABAP Stack based deployments starting with version:

7.0 NetWeaver: in EHP2 SP 14 or higher

7.0 NetWeaver: in EHP3 SP 09 or higher

7.3 NetWeaver: in EHP1 SP 09 or higher

7.4 NetWeaver: in SP05 or higher

 

In order to use the CVA tool first execution of system wide security checks needs to be enabled with report RSLIN_SEC_LICENSE_SETUP. Afterwards in standard ABAP code checking tools like: ABAP Test Cockpit (ATC), Code Inspector (SCI), and extended program check; the security checks are available. Option of these checks is usually called: "Security Analyses in Extended Program Check". Also notice that the tool has several limitations -> see SAP Notes below for details.

Notice that usage of the security check features for custom code is licensed separately and there are additional costs incurred.

- update 2022NOV22-

There are following other tools that can be used to scan ABAP code:

- t-code CODE_SCANNER (prog AFX_CODE_SCANNER)

- program RS_ABAP_SOURCE_SCAN

- program RS_B4HANA_CODE_SCAN – specific to BW systems, included in BW/4 Starter-Addon 

More information:

1855773 - Security checks for customer-specific ABAP programs

1697494 - Customer Code Scans

1841643 - Customer Security Vulnerability Scans

1949276 - Code vulnerability analyzer: Restrictions