SAP® Integration

Teamscale can integrate with SAP® systems in order to use the analyses provided by Teamscale in the area of ABAP® custom code development. The following is relevant for ABAP developers, quality engineers for ABAP, and SAP NetWeaver® system administrators who want to configure Teamscale, or those of them who want to connect to Teamscale from an SAP system. It covers the SAP and ABAP specific configuration steps and usage scenarios, especially those tasks, which are done within an SAP system. This chapter is irrelevant for all who have nothing to do with custom code development for SAP.

The required configuration steps on the SAP system are independent of clients on the SAP system (in German »mandantenunabhängig«). Therefore, it is not required to transport our add-on to specific clients.

SAP Java Connector (SAP JCo)

A prerequisite for Teamscale to communicate with SAP systems is the SAP Java Connector (SAP JCo) library. SAP's licensing restrictions do not permit redistribution of this library with Teamscale. However, SAP JCo is licensed without additional fees as part of a licensed SAP solution or component license. To connect Teamscale to your SAP system, you need to manually download the library from SAP and put it into Teamscale's library folder. For detailed information on the installation process, please refer to Installation of the SAP Java Connector (JCo)

• Installation of the SAP Java Connector
• Teamscale Connector for SAP NetWeaver® AS ABAP®
  • Installation of the SAP Connector
  • Removal of the SAP Connector
• User and Role for RFC Access
  • Role and Required Access Rights
  • RFC User for Teamscale
• SAP Connection Configuration in Teamscale
  • Configuring Repository Clone Directory
  • Configuring SAP ABAP System Connection
  • Connecting a Teamscale Project with SAP
• Background Full Sync
• Secure Network Communication (optional)
  • SNC Configuration of the SAP System
  • SNC Configuration on the Teamscale Server
• Additional Analysis Configuration for SAP
  • Grouping Changes by Transport Request or Task
  • Integrating SAP Code Inspector / ATC
  • Selecting/Defining a Code Inspector Check Variant
  • Code Inspector Settings in SAP ABAP System Connection
  • Test Gap Analysis Set Up For SAP
  • Troubleshooting: No Coverage Information
  • Using SCOV Lite for Teamscale and UPL
• Integration with ABAP Development Tools for Eclipse (ADT)
• Integration with ATC
  • Configuring HTTPS Connection to Teamscale
  • Configuring HTTP(S) Proxy in the SAP System
  • Test Activation
  • Definition of a Check Variant
  • Execute the Check Variant.
• Integration with SAP Transport Management System
• Teamscale Features for SAP ABAP
  • Properties of ABAP Code Objects

Installation of the SAP Java Connector

1. Download the SAP Java Connector (SAP JCo). SAP JCo is available through the SAP Service Marketplace for registered SAP customers. Download the most recent version (>= 3.1) for the platform running Teamscale. When SAP JCo is needed for deploying our docker container, use the version for Linux for Intel compatible processors.
2. Uncompress the contained library files into a temporary directory.
3. Copy the Java library sapjco3.jar and the native library file for the specific platform (sapjco3.dll for Windows, libsapjco3.so for Linux, or libsapjco3.dylib for macOS) to a directory named lib-ext.

• For Teamscale zip distributions, the lib-ext directory must be inside the Teamscale installation directory.
• For Teamscale Docker distributions, the lib-ext directory must be mounted directly in the volumes section of the docker-compose.yml file to the directory /opt/teamscale/lib-ext, see below. Please consider setting the appropriate access rights (see How to install Teamscale with Docker).

    volumes:
      - /path-on-host/lib-ext:/opt/teamscale/lib-ext

4. On Windows systems, please make sure the prerequisite Microsoft Visual Studio C/C++ Runtime is installed. The architecture (x86 or x64) must match your JVM's architecture. If in doubt, consult the System > System Information view. For details, see SAP Note 2786882.
5. (Re-)start Teamscale to load the SAP JCo library. You can confirm that the JCo library has been successfully loaded on the System > System Information view.

Teamscale Connector for SAP NetWeaver® AS ABAP®

The Teamscale Connector for SAP NetWeaver® AS ABAP® provides the connection between Teamscale and SAP NetWeaver AS ABAP based systems. The connector has to be transported to the SAP NetWeaver system and provides the following main functions:

• An RFC-based interface, which is used by Teamscale to poll the SAP system for custom code changes, so they can be analyzed within Teamscale

• Execution of SAP Code Inspector (SCI) and export of the inspection results to Teamscale

• Extraction of test coverage and usage data for Teamscale to support Test Gap analysis and usage analysis

• A plug-in for the ABAP Workbench and the Change and Transport System to access Teamscale results from the SAP system. This is realized by a custom SAP Code Inspector test case which shows messages for findings identified in Teamscale.

The Teamscale Connector for SAP NetWeaver® AS ABAP® is compatible with SAP NetWeaver AS ABAP 7.0 EHP2 and later versions.

Installation of the SAP Connector

An archive file containing the latest release of the Teamscale Connector for SAP NetWeaver® AS ABAP® can be downloaded via https://www.cqse.eu/get-abap. Download either the .zip or .tar.gz source code file.

For transport, place the K* and R* files from the archive in the cofiles and data directories of the transport directory of your host machine (typically /usr/sap/trans on Unix/Linux or C:\usr\sap\trans on Windows) and import the transport (transaction STMS ). Enable special conditions Overwrite Originals and Ignore Invalid Component Version:

Basically, no further configuration in the SAP system is required. One exception is the use of Secure Network Communications (SNC).

Removal of the SAP Connector

To remove the Teamscale Connector for SAP NetWeaver® AS ABAP® from your system, a deletion transport is provided upon request. Please contact us, attaching a Teamscale support request and mention the System ID the connector should be removed from. We will then provide the deletion transport for the correct version.

User and Role for RFC Access

Teamscale connects to the SAP application server via RFC (remote function call) to retrieve the source code, which should be analyzed as well as some metadata (for example test coverage). The called functions are in function group /CQSE/TEAMSCALE_CONNCT_RFC . Additional functions reside in /CQSE/TEAMSCALE_TIA_RFC . Hence, a (technical) SAP user is required, which will be used by Teamscale to connect to the SAP system.

Role and Required Access Rights

The SAP user for Teamscale must have an appropriate role assigned. The required authorizations are listed here:

Authorizations for SAP Teamscale User

Authorization Object	Field	Value
S_RFC	RFC_TYPE	FUGR (Function Group)
	RFC_NAME	RFC_METADATA, /CQSE/TEAMSCALE_CONNCT_RFC, /CQSE/TEAMSCALE_TIA_RFC
S_RFC	RFC_TYPE	FUNC (Function Module)
	RFC_NAME	DDIF_FIELDINFO_GET, RFCPING, RFC_GET_FUNCTION_INTERFACE
S_BTCH_JOB	JOBACTION	RELE (Release Jobs)
	JOBGROUP	*
S_COV_ADM	ACTVT	02 (Change)
S_DEVELOP	DEVCLASS	*
	OBJTYPE	*
	OBJNAME	*
	P_GROUP	*
	ACTVT	03 (Display)

The authorizations are required for basic RFC access, read access to development objects (source code), scheduling and releasing (own) batch jobs for background processing, and for enabling test coverage analysis.

The role can be defined manually, e.g. using transaction PFCG, or the predefined role /CQSE/RFC_TEAMSCALE can be used.

RFC User for Teamscale

The SAP user for Teamscale can be created in the usual way users are crated in the SAP system, e.g. using transaction SU01.

WARNING

Use a system user, not a dialog user. The role described before (e.g., /CQSE/RFC_TEAMSCALE) must be assigned to this user.
Using a dialog user might result in connection timeouts as dialog connections are by default terminated after 10 minutes without user interaction. The initial extraction of the source as well as the retrieval of SAP Code Inspector results might take longer

Time Zone Settings

It is highly recommended that the user time zone of the SAP user for Teamscale is the same as the SAP system time zone. If the user time zone differs from the system time zone, the continuous polling for code changes might not work correctly, and code changes might not be visible or only with a longer delay. The time zone setting of the user can be checked / edited in transaction SU01 .

Additionally, it is highly recommended that the system time zone in SAP NetWeaver is the same as the time zone of the operating system.

SAP Connection Configuration in Teamscale

This section describes the basic configuration to configure a SAP connection.
The settings need to be done in the web interface of Teamscale. For configuration, switch to the Admin > Settings view.

Configuring Repository Clone Directory

First, you should check if a suiting directory is specified in section Git > Repository Clone Directory. Teamscale will save the (historized) code exports in subdirectories of this directory and access them for analysis there. Under the hood, this is realized by a local Git repository which is managed by Teamscale automatically. Usually, the Teamscale repository clone directory will be specified by the system administrator of the Teamscale server, you should check with them to define the proper location. It can be specified as absolute or relative path and defaults to a folder named repo within the JVM process working directory. In case of a relative path, the location is relative to the parent of the Teamscale storage directory (parameter database.directory of the teamscale.properties configuration file.)

Configuring SAP ABAP System Connection

Under SAP > SAP ABAP System Connection, the parameters to connect to an SAP NetWeaver system must be specified. For every SAP system, a separate connection configuration must be added. To add a new connection, press the Add button. In the opening dialog, a unique connection ID must be specified, for example the three letter SAP system ID could be used. After this, a new configuration section is added, in which the parameters must be specified.

The first options are the parameters for the RFC connection. The required parameters mainly depend on the connection type, i.e. if the connection to the SAP system is direct or via logon balancing. Further options specify the logon data (client, user, password). This table describes these parameters:

System and Logon Parameters for SAP Connection

Direct connection: Application server host	Mandatory parameter for direct connection: The full qualified host name of the SAP NetWeaver application server, e.g., saphost.me.com
Direct connection: Instance number	Mandatory parameter for direct connection: The instance number (formerly called system number) of the SAP NetWeaver application server, e.g., 00
System ID	Mandatory parameter for logon balancing connection: 3-letter SAP system ID, e.g., NSP
Logon balancing connection: SAP message server	Mandatory parameter for logon balancing connection: Host name of SAP message server
Logon balancing connection: Group of SAP application servers	Mandatory parameter for logon balancing connection: Group of SAP NetWeaver application servers (e.g., public)
Logon balancing connection: SAP message server port	Optional parameter for logon balancing connection: Port of message server, typically 36xx where xx refers to the instance number
SAP Router string	Optional parameter for connection to systems behind an SAP Router: SAP router string contains the chain of SAP routers and their port numbers and has the form (\H\<host>[\S\<port>])+
SAP client	Mandatory parameter: Defines the client used for logon (e. g. 001)
Logon user for password-based authentication	Mandatory parameter for password-based authentication: The SAP username which should be used by Teamscale
Logon password for password-based authentication	Mandatory parameter for password-based authentication: Password of the user

Further options of the SAP ABAP System Connection parameters control the code retrieval of Teamscale from the SAP system. These specify which code should be retrieved, how often it should be updated and if other result data should be included (e.g., test coverage data). This table describes these parameters. The most important parameters specify which objects should be retrieved and schedule the update intervals.

SAP Object Selection Parameters

See also: Code Inspector Options

Include objects in default custom namespaces	Specifies if ABAP source code objects within the default custom namespaces Y... / Z... should be retrieved by Teamscale.
Further custom namespaces	Comma-separated list of further custom namespaces like /ABC/, /DEF/ for which ABAP code should be retrieved.
Polling schedule for changes	Defines in which interval continuous code changes are retrieved from the SAP system.
Polling schedule for full sync	Defines in which interval a full synchronization of the code base is performed.
Use background job for full sync	If enabled, full sync is scheduled in the background.
Include objects in ABAP Dictionary (DDIC)	In addition to ABAP source code, this will also retrieve DDIC objects (table definitions, data elements etc.) in the given namespace(s), e.g. for use in architecture analysis.
Include all objects with modifications	In addition to ABAP custom code, this will also retrieve modified ABAP standard objects.
Include programs generated from BW objects	On SAP BW systems, this will also retrieve ABAP programs generated from BW transformations, queries, and DTPs in the given namespace(s). This is used for test gap analysis.
Include package information for standard objects	During full sync, this will retrieve package information for all ABAP and DDIC objects on the system. This is useful for analyzing dependencies to SAP standard packages.
Include code coverage in full sync	This will retrieve procedure execution information recorded by SCOV on the system. If not enabled already, Teamscale will attempt to start SCOV automatically.
Include code coverage with change polling	This may result in very high disk space consumption and long processing time. Especially, this option should not be enabled in combination with very frequent incremental change polling, e.g. every 10 minutes. Further, it should not be enabled when immediate analysis results in SAP or Eclipse ADT are desired, e.g. when using Teamscale during transport release.
Clear table COVRES after coverage retrieval	If enabled, the table COVRES which holds coverage data will be cleared after retrieving the coverage data.

Additional parameters are required for secure RFC communication using Secure Network Communications (SNC), see here. Together with the ABAP code retrieval from the SAP system also the execution of SAP Code Inspector checks in the SAP system can be performed. The Code Inspector configuration in explained here.

Namespace Configuration

The namespace parameters Include objects in default custom namespaces and Further custom namespaces specify which code objects should be retrieved from the SAP system. It is recommended to specify all custom namespaces, which are available for development, e.g., enable the retrieval of the default custom namespaces Y and Z as well as all further custom namespaces e.g. /ABC/ which are registered for your organization. Note that these parameters only define for which code Teamscale keeps track of the change history, but not which code gets analyzed. The actual selection of the analyzed code is specified in the project configuration).

Update Intervals

The scheduling parameters Polling schedule for changes and Polling schedule for full sync define when code (and further data, e.g. coverage results) is retrieved from the SAP system.

Change polling only retrieves objects that have changed since the last retrieval, thus the amount of transferred data is low and the execution time is very short (a few seconds only). A change to an object is only observed once the object gets activated. Here, intervals between 10 and 30 minutes are recommended. Longer intervals may result in an unwanted long delay of analysis results after activation of code changes, shorter intervals may lead to a too fine-grained change history.

The full sync interval controls when retrieval of all code objects (within the specified namespaces) is performed. Usually, no code changes are visible after synchronization. In rare cases, however, the code base can change without Teamscale's change polling recognizing it. Such missed changes are typically not caused by regular development, but may result from special transport or upgrade activities. A regular full sync ensures that the code repository created by Teamscale is in sync with the actual code within the SAP system. We recommend a daily update during night.

Both intervals are specified as cron expressions, for example */10 * * * * specifies an update of every 10 minutes, 0 1 * * * a nightly update at 1:00am. When saving a new SAP connection, an initial full sync will be scheduled automatically. Depending on the amount of code in the system, and other parameters, it will take some minutes until the code is available for analysis in Teamscale.

Asynchronous Communication

The full sync can be also configured to be executed as a background job of the SAP system. Use this mode if the run-time of the code retrieval takes too long time. This is configured by the setting Execute full update asynchronously and its dependent options. Please refer to the detailed description for more information.

Archiving of Raw Export Files

When receiving data from the SAP system, Teamscale archives the raw data as zip files in a directory on the Teamscale server. These archived files can be used to investigate problems. To preserve disk space, Teamscale will retain archived files only for one year. This period can be configured with the JVM option -Dcom.teamscale.abap.archivingPeriodInDays=365 (default value is 365) in the jvm.properties configuration file.

Connecting a Teamscale Project with SAP

After the SAP system connection is specified and the code retrieval was executed for the first time, projects for analyzing the ABAP code of the respective SAP NetWeaver system can be created.

The creation of projects follows the standard project configuration, using the ABAP connector and an ABAP-specific analysis profile.

ABAP Connector Configuration

Technically, Teamscale creates an ABAP repository directory inside the Teamscale repository clone directory. This directory contains a Git repository for every SAP system. To connect projects with these git repositories, we recommend to use our specific ABAP connector. In comparison to the plain Git connector, the ABAP connector simplifies selection of an SAP connection by providing a dropdown list that includes all available connections. Additionally, the ABAP connector is reduced to the essential configuration options. For example, the Default branch option from the Git connector is missing, as ABAP Git repositories do not use branching.

Note that the settings to include/exclude source code are specified using the parameters Included file names and Excluded file names, which refer to the file paths within the internal Git repository of the ABAP source code. The path consists of the full package hierarchy and source code files suffixed with .abap. Furthermore, the slashes at custom namespaces are replaced by an exclamation mark, thus /XYZ/ is replaced with !XYZ!. This tables states some examples of patterns for including and excluding ABAP source code.

Examples for ABAP Code File Include/Exclude Patterns

Pattern	Matched ABAP Source Code Objects
**.abap	All ABAP source code objects in configured namespaces (** matches any path)
$*/**.abap	ABAP source code within local packages (starting with $), * matches all but the path/package separator slash
ZPACKAGE/**.abap	Objects within the top-level package ZPACKAGE and its sub-packages only. Will not match if ZPACKAGE has a super package
**/ZPACKAGE/**.abap	Objects within the package ZPACKAGE and its sub-packages only, regardless if ZPACKAGE is a top-level package
**/!XYZ!*/**.abap	Objects within packages in namespace /XYZ/ only
!XYZ!ROOT_PACKAGE/**.abap	Objects within the top-level package /XYZ/ROOT_PACKAGE and its sub-packages only
**/PROG/*.abap	Programs and program includes only
**/FUGR/**.abap	Function groups only
**/FUGR/ZSOME_FUGR/*.abap	Function group ZSOME_FUGR only
**/CLAS/**.abap	Global classes only
**/CLAS/!XYZ!CL_BASE_**.abap	Global classes whose name starts with /XYZ/CL_BASE_ only
**/CLAS/*/*CCAU.abap	ABAPUnit test classes only (class addition suffixed with CCAU)
**/INTF/**.abap	Global interfaces only

ABAP Dictionary (DDIC) objects.

Besides the ABAP source code in *.abap files, also textual representations of objects defined in the ABAP Dictionary (DDIC) are retrieved from the SAP system. These dictionary objects are stored in *.abap_ddic files. Adding these files to the project will allow to identify dependencies from ABAP source code to ABAP dictionary objects and between dictionary objects when performing architecture conformance analysis. The textual representation of structures and database tables is the same as used in the source code-based editors of the ABAP Development Tools for Eclipse (available from SAP NetWeaver 7.51 or 7.52 on, respectively). For older SAP NetWeaver versions and further dictionary objects, a similar notation is used in Teamscale. As in Teamscale the only purpose of the dictionary objects is to perform architecture conformance analysis, .abap_ddic files will only contain the required information to identify dependencies and omit further attributes.

This table contains typical examples for including and excluding ABAP Dictionary objects:

Examples for ABAP Dictionary File Patterns

Pattern	Matched ABAP Dictionary Objects
**.abap_ddic	All ABAP Dictionary objects in configured namespaces (** matches any path)
**/DOMA/*.abap_ddic	Domains
**/DTEL/*.abap_ddic	Data elements
**/STRU/*.abap_ddic	Data structures
**/TABL/*.abap_ddic	Database tables
**/TTYP/*.abap_ddic	Table types
**/VIEW/*.abap_ddic	Database views

Of course, these path patterns can also be combined with package specifications, similar to the ABAP source code files. The include/exclude pattern for dictionary objects must be added to the list of include/exclude patterns besides the patterns for the ABAP code.

Background Full Sync

By default, all updates of the ABAP code are retrieved from the SAP system by synchronous communication. The full synchronization, which retrieves the entire code of the configured namespaces, can be alternatively configured to use asynchronous communication, i.e. run in the background on the SAP system.

Background processing is used to avoid a long run-time of the RFC session, which would block other jobs within Teamscale and/or result in communication timeouts. A long run-time is to expect especially if SAP Code Inspector check execution is configured.

To achieve background processing of the full sync, a batch (BTC) job is scheduled and released in the SAP system. Jobs are monitored in transaction SM37. It only requires that the RFC user for Teamscale is authorized for RELE (release) activity at authorization object S_BTCH_JOB.

In background processing mode, a full synchronization will initially only schedule a background job in the SAP system. Teamscale is not waiting for the job to finish and closes the connection to the SAP system immediately after scheduling the job. The collection of the source code and meta-data and especially the execution of SAP Code Inspector is then executed in the background on the SAP system. When the background job finishes, the results will be stored in a database table. For retrieving the results, Teamscale is polling the SAP system regularly to check whether the scheduled job is finished and results are available. If so, the result data is retrieved from the SAP system and Teamscale's internal ABAP repository is updated.

Change polling, which only queries changed objects, is always scheduled in synchronous communication mode. Also, initial code retrieval is done synchronously but will not execute SAP Code Inspector to make the entire code base visible in Teamscale without a too long delay.

Background Full Sync Configuration in Teamscale

The main configuration in Teamscale is made by the option Use background job for full sync of the SAP ABAP System Connection settings. This will schedule batch jobs in the SAP system to perform the full sync.

The scheduling interval of the polling job for retrieving the finished results can be specified in the SAP ABAP System Connections - Global Settings of the Admin > Settings in field Schedule for requesting results of asynchronous ABAP exports. In addition, these global options control for how long scheduled jobs are polled from Teamscale if no results could be retrieved for a long time. This is configured with the parameter Maximum wait time.

Secure Network Communication (optional)

If the RFC communication between Teamscale and SAP NetWeaver should be secured (encrypted), Teamscale can connect to the SAP system via Secure Network Communications (SNC). In order to use it, a respective configuration of the SAP system and the Teamscale server is required.

SNC Configuration of the SAP System

To enable SNC, the SAP system must be configured accordingly. In the following a rough outline of the configuration is stated. As the configuration steps vary depending on the SAP version and on the individual configuration needs for a customer SAP system, please refer to this article on help.sap.com for detailed instructions on how to set up SNC. Furthermore, there is a very helpful SAP Community blog post.

The recommended SNC configuration steps for an SAP NetWeaver system are as follows:

1. Ensure that the following instance parameters (transaction RZ10 ) are set:

   snc/enable = 1
   snc/identity/as = snc_name

   where snc_name is the SNC name of the SAP system, something like p:CN=SID, O=ACompany, C=EN .

2. The SAP Cryptographic Library must be installed, see SAP Note 1848999.

3. With the command line tool sapgenpse of SAP Cryptographic Library, a Personal Security Environment (PSE, stored in a file) for Teamscale must be created. This can be done by executing sapgenpse on the application server (or any other sever where the SAP Cryptographic Library is available). For example, enter the following command:

   sapgenpse gen_pse -v -p teamscale.pse

   During creation of the PSE, the tool will ask for the name of the PSE owner, here the SNC name for Teamscale should be supplied (something like p:CN=TEAMSCALE, O=ACompany, C=EN ). Afterwards, the client certificate (*.crt file) must be exported, again by using sapgenpse:

   sapgenpse export_own_cert -v teamscale.pse -o TEAMSCALE.crt

   This file contains the X.509 client certificate which can be also used for logon instead of username and password, see below.

4. In transaction STRUST the following configuration is required:

   • The PSE SNC (SAPCryptolib) must have been created. A respective entry should already exist after the SNC instance parameters were set and the SAP system was restarted. The SNC name should be the same as specified in snc/identity/as

   • The client certificate created previously (e.g. TEAMSCALE.crt ) must be imported and added to the PSE SNC (SAPCryptolib). Base64 file format should be used.

   • The own (server) certificate of SNC (SAPCryptolib) must be exported to a file, e.g. SNC.crt (again, use Base64 file format).

5. The server certificate (e.g. SNC.crt ) must be imported in the client PSE file (e.g. teamscale.pse ) and the credentials file cred_v2 , which will be used on the Teamscale server, must be created from the client PSE file. For both steps, again the command line tool sapgenpse is used, see the following examples:

   sapgenpse maintain_pk -v -a SNC.crt -p teamscale.pse
   sapgenpse seclogin -p teamscale.pse -O root

6. The Access Control List (ACL) for SNC restrictions must allow RFC communication with the client: In view VSNCSYSACL (transaction SM30 ), an entry for work area external (E) with the SCN name of the client (Teamscale), e.g. p:CN=TEAMSCALE, O=ACompany, C=EN, must be added.

7. If you want to use the client X.509 certificate also for logon instead of username and password, the certificate must be mapped to the SAPTeamscale user. To do so, an entry in view VUSREXTID (transaction SM30 ) must be added, again for the SNC name of the client.

SNC Configuration on the Teamscale Server

On the Teamscale server, the following configuration steps are required:

1. The library files from SAP Cryptographic Library must be saved on the Teamscale server. SAP Cryptographic Library can be downloaded from SAP for Me (requires login) for the required operating system, search for COMMONCRYPTOLIB 8.

2. The cred_v2 file must be moved to a directory on the Teamscale server. The file should be only accessible for the operating system user running Teamscale.

3. The environment variable SECUDIR must have been defined pointing to the directory containing cred_v2 .

4. If the X.509 client certificate should be used for logon (SSO mechanism), the client certificate file (e.g. TEAMSCALE.crt ) must be saved on the Teamscale server.

SNC Configuration in Teamscale

On the Admin > Settings view, you have to specify the path to the directory containing the library files of SAP Cryptographic Library under SAP > [SAP ABAP System Connections - Global Settings].

Under SAP ABAP System Connection, SNC must be enabled and the SNC options must be specified:

SNC Parameters for SAP Connection Overview

Use Secure Network Communications (SNC)	Tick to enable SNC
SNC name of the communication partner server	The SNC name of the SAP system, something like p:CN=SNC, O=ACompany, C=EN
Own SNC name of the caller	The client SNC name of Teamscale, something like p:CN=TEAMSCALE, O=ACompany, C=EN
Use SNC Single sign-on (SSO)	Enable logon by X.509 certificate instead of username/password
Path to X.509 certificate	Path to *.crt file holding the X.509 client certificate, only required if SSO mechanism is enabled

Additional Analysis Configuration for SAP

This section describes additional configuration steps required for specific analyses in Teamscale, namely the upload of SAP Code Inspector findings and the usage of coverage results for test gap analysis.

Grouping Changes by Transport Request or Task

If your development workflow is centered around transports and tasks, you can use Teamscale to easily group all changes belonging to the same transport into one view. To do that, add a connector or type Issue Tracker > Commit Message Issues in the project creation / edit dialog with the following configuration:

• Issue ID pattern: Request ([A-Z0-9]{10})[ :]|Task ([A-Z0-9]{10}):
• Issue subject pattern: [^:]+:(.*)

These patterns will extract all requests and tasks. If you are only interested in one of these types, you may remove the other from the Issue ID pattern.

After project creation or reanalysis, the Activity > Issues view will be populated, and all entries in Activity > Commits will reference the respective request and/or task.

Integrating SAP Code Inspector / ATC

Messages resulting from checks of SAP Code Inspector (SCI) can be imported into Teamscale as findings. Thus, all findings management features of Teamscale (e.g., working with baselines, tolerated findings, the definition of tasks, ...) are also available for SCI messages. Once configured, no further manual actions are required by developers to get results of the SCI tests.

The integration of SAP Code Inspector findings in Teamscale requires that an appropriate Code Inspector variant is defined in the SAP system and that the SAP system connection settings and the project configuration in Teamscale are set up accordingly.

The integration of SAP Code Inspector findings also supports findings generated by the Code Pal for ABAP tool which can be installed in Code Inspector (Installation Instructions).

Selecting/Defining a Code Inspector Check Variant

In order to specify which checks should be executed, SAP Code Inspector / ATC uses variants. For Teamscale integration, you can use an existing variant (e.g. the DEFAULT variant that comes pre-configured in every SAP system) or define a custom one based on your coding guidelines. Checks that produce a high amount of irrelevant messages should be excluded, otherwise the storage and backup size of Teamscale could increase heavily. Further, the execution time of some Code Inspector checks might be long, especially if the whole custom code base is checked. If the execution time is too long, we recommend switching off irrelevant checks. Variants can be created or modified in the SAP system using transaction SCI. You should consider using a public variant, as these can be made transportable and therefore be transported to other systems in your organization.

INFO

For findings to appear in Teamscale, the checks you enable in the Code Inspector variant also have to be enabled in Teamscale's analysis profile. Code Inspector messages for checks unknown to Teamscale or disabled in the analysis profile will be logged as warnings in the worker log.

Code Inspector Settings in SAP ABAP System Connection

Parameters for SAP Code Inspector Execution during Code Retrieval

Code Inspector: variant name	Name of an SAP Code Inspector variant which should be executed
Code Inspector: variant user	Specifies the SAP username of the variant owner (leave empty for public variants).
Code Inspector: include specification	Defines for which code objects Code Inspector should be executed.
Code Inspector: exclude specification	Defines exclusions of code objects for Code Inspector execution.

To execute SAP Code Inspector during code retrieval of Teamscale, this must be configured under Admin > Settings > SAP ABAP System Connection (see table above). The name of the executed Code Inspector variant must be specified in parameter Name of the SAP Code Inspector variant. If this is not a public variant, but a user variant, the SAP username of the owner must be additionally specified in the parameter Name of the owner of the SAP Code Inspector variant.

The parameters Code Inspector include specification and Code Inspector exclude specification are used to restrict the code that is checked by SAP Code Inspector. These includes/excludes are stated as a list of Ant patterns matching against the file paths of the ABAP source code objects as visible in Teamscale, this is similar to the patterns used for project configuration.

Note that the single star wild card (*, which matches a sequence of chars but not /) cannot be used in these patterns.

With this configuration, Code Inspector is executed in the SAP system during every code retrieval. During change polling, only changed ABAP repository objects are checked by SAP Code Inspector, but during the full synchronization, Code Inspector is executed for all ABAP repository objects in the specified namespaces. As the full synchronization may take a long time (up to a few hours for code bases of many million lines of code), we recommend to schedule the full synchronization at most once every night.

Potential memory bottlenecks with Extended Program Check (SLIN) inspections

Please note that the SAP Code Inspector inspections in Extended Program Check (SLIN) use internal caching to store and reuse test results. If these inspections are activated in a Code Inspector variant, memory bottlenecks may be caused in case of very large ABAP programs that lead to failing (full) exports. A prominent example of a very long program (with more than 120k LOC) is the standalone version of the AbapGit report. If included in the codebase, we recommend to exclude this report from SAP Code Inspector executions by using the following pattern in the Code Inspector exclude specification: **/PROG/*zabapgit*.abap.

Code Inspector Settings in Project Configuration

To actually include findings from SAP Code Inspector in a Teamscale project, the following must be configured:

• In the analysis profile, Code Inspector must be enabled as an analysis tool.
• Under the expert options of the ABAP connector, the Analysis report mapping rule **.sci -> SAP_CODE_INSPECTOR must be specified (Note: by default, it is).

If the above is correctly configured, findings from SAP Code Inspector should be visible in Teamscale just like other findings and are updated simultaneously with every code change. Note that during change polling, only changed repository objects are analyzed by SAP Code Inspector. New findings from Code Inspector which affect unchanged objects will only be visible after the next full synchronization.

Test Gap Analysis Set Up For SAP

To perform test gap analysis, it is required that the SAP Coverage Analyzer (SCOV) is collecting coverage data from (test) executions. Depending on the actual system, either SCOV Lite (if available) or the regular SCOV has to be used as coverage analyzer. Teamscale will use SCOV Lite automatically, if the Teamscale user has the S_COV_ADM authorization object. SCOV Lite is the preferred method, as it has a smaller performance impact. If you want to use the regular SCOV, it is necessary to activate SCOV manually for every system.

Manually Activating SCOV

This section describes how to manually activate the regular SCOV. Please make sure to check whether this is necessary for you.

User Rights of Processes

This will schedule the batch job RSCVR_TRIGGER_COLLECT to run every 45 minutes. By default, SAP NetWeaver configures this job to be executed by the user that activates SCOV. We suggest to edit this batch job and use a technical user instead in order to be independent of personal account availability and permissions.

Note that background jobs in SAP are always scheduled in the system time zone and do not respect the user time zone. Thus, errors may occur during SCOV activation if the user who activates SCOV has a different user time zone setting. The user time zone can be checked/modified in transaction SU01. It is recommended that a user with no specific user time zone setting performs the activation.

The coverage analyzer is configured via the transaction SCOV . Here it is important that both the coverage analyzer and the data collection for the server are activated. A detailed description of the activation can be found at http://help.sap.com/. No specific settings (e.g., test groups) need to be configured. This image shows the required configuration, the important parts are highlighted:

Ensuring SCOV is Active

In order to make sure SCOV is functional and records data as expected, the start screen of transaction SCOV can be checked. Please ensure the following:

• The General Status area has a green indicator next to Main Switch.
• The Status of Current Application Server area has a green indicator next to Data Collectn.
• The Messages area does not show errors.
• The Last Data Collection is less than 45 minutes ago.

Troubleshooting: No Coverage Information

If the results do not look as expected, most of the time it is enough to use the repair functionality that is included in SAP Coverage Analyzer. Execute transaction SCOV and run the consistency checks with repair option:

Afterwards, you can check the Monitor view for errors. If there are old errors, which are obsolete after the repair, these can be cleared by selecting a line and clicking Completed as shown here:

In case of problems with the batch job RSCVR_TRIGGER_COLLECT, please make sure the user configured for the job does still exist and is not locked.

Using SCOV Lite for Teamscale and UPL

If you would like to use Teamscale to analyze coverage information from a system that is already using Usage Procedure Logging (UPL), there are a few things to consider. Otherwise, these tools may interfere with each other and produce incorrect results. In essence, both the coverage-enabled Teamscale export and UPL use the same raw data created by SCOV Lite in the system table COVRES. However, when UPL extracts that data via the batch job /SDF/UPL_PERIODIC_EXT_JOB every 24 hours, it empties that table, whereas the Teamscale Connector does not.

This means the Teamscale export should run briefly before the UPL extraction job. In order to find out when that job is scheduled, you can either use transaction SM37 in the SAP system or have a look at the file job_status.csv in one of the exported zip files. Afterwards, adjust the polling schedule for coverage data in your SAP System Connection to run a few minutes before that time. You may still have multiple updates per day, as long as one of them always runs shortly before the UPL extraction job.

Integration with ABAP Development Tools for Eclipse (ADT)

Teamscale analyses can be integrated into Eclipse-based development workflows, displaying findings directly in the IDE. Thus, users will get most of the relevant information in their usual development environment, not needing to switch to Teamscale's web interface.

For installation and configuration of the Eclipse plugin, please see this guide.

Integration with ATC

Teamscale findings can be also shown within classical SAP development tools like ABAP Test Cockpit (ATC) and SAP Code Inspector (SCI). Thus, Teamscale findings can be handled within the ABAP Workbench in the same way as any other Code Inspector messages, e.g. by using the check functions available in SE80.

To achieve this, the Teamscale Connector for SAP NetWeaver® AS ABAP® contains an implementation of a custom SAP Code Inspector test which allows to retrieve findings from Teamscale. To be able to execute the respective Code Inspector test Teamscale Findings, the following configuration steps are required.

Configuring HTTPS Connection to Teamscale

If Teamscale is accessible via HTTPS (see section Configuring HTTPS), some configuration steps might be necessary in the SAP system.

General HTTPS configuration

This section assumes that your SAP system is already configured to establish HTTPS connections, and focuses on importing the correct root certificate only. For a more detailed description of general prerequisites, cipher suite settings, or how to obtain the root certificate, please refer to the SSL Setup section of the abapGit documentation. It covers all these topics, and is not specific to abapGit for most of them.

In order to check whether your SAP system can already connect to Teamscale, you may download and use the report zabapgit_test_ssl. Just enter the Teamscale server's URL into the URL field. You can ignore the fact that it refers to Git server, it works just fine with any other HTTPS URL. If the report shows ok, no further steps are necessary. In case the output mentions SSSLERR_PEER_CERT_UNTRUSTED, a required root certificate is likely missing.

Importing TLS Root Certificates

Only import the CA Root Certificate

HTTPS server certificates are relatively short-lived and therefore re-issued frequently. In order to connect to an HTTPS server like Teamscale, you only need to explicitly add the Certificate Authority's (much longer-lived) root certificate to your SAP system's trust store. Importing individual server certificates is not required.

To import the root certificate, perform the following steps in transaction STRUST:

1. Enter edit mode using the Display <-> Change button.
2. Select SSL client SSL Client (Anonymous) on the left.
3. In the Certificate section, click on the bottom-left button Import certificate.
4. Choose the root certificate to import into the system.
5. Select Add to certificate list.
6. Save.

Cipher Suite Configuration

If your Teamscale server has restrictions with respect to accepted TLS ciphers, you may need some additional modifications. For example, if only TLSv1.2 with perfect forward security (ECDHE ciphers) is allowed, on some SAP systems you may need to enable this with profile parameters in the SAP system first:

1. Use transaction RZ10, select the DEFAULT profile and extended maintenance > change.
2. Create or modify the parameter ssl/client_ciphersuites and set it to 908:PFS:HIGH:MEDIUM:+e3DES.
3. Save and activate the changed profile (respective dialogs will appear).
4. Restart the SAP application server.

Further information can be found in the SAP Community.

Configuring HTTP(S) Proxy in the SAP System

The Code Inspector test Teamscale Findings uses the global HTTP(S) client settings configured in transaction SICF. If your SAP System requires an HTTP(S) proxy in order to connect to the Teamscale server, please make sure the system's global proxy settings in SICF > Client > Proxy Settings > Global Settings are configured correctly.

Test Activation

First, Code Inspector test Teamscale Findings must be activated:

1. In transaction SCI, select the action Code Inspector > Management of > Tests (or »Ctrl+Alt+F5«).
2. Mark the checkboxes at the check classes /CQSE/CL_CI_CATEGORY_TEAMSCALE (category for Teamscale) and /CQSE/CL_CI_TEST_TS_FINDINGS (Teamscale findings test).
3. Save your changes.

Definition of a Check Variant

Second, a check variant which contains the Teamscale Findings test must be defined. In transaction SCI, add a new check variant and select the Teamscale Findings test:

Also, the required parameters of this test must be specified:

Teamscale Findings Parameters

Teamscale server URL	URL of the Teamscale instance
Teamscale user name	Name of the Teamscale user which should be used to retrieve the findings
User’s access key	The access key of this user (must be generated in the user preferences of the Teamscale Web UI)
Teamscale project id	The identifier of the project in Teamscale for which findings should be retrieved. If no project ID is provided, the check will query Teamscale for projects that are associated with the respective system ID.
Only new findings since (label)	Optional. If set, only findings which were introduced after the given baseline label are included. Baselines are managed in the Teamscale Web UI under Quality Control > Baselines)
Only new findings since (date)	Optional. If set, only findings introduced after the specified date are included.
Also finds. in changed code	If enabled and also one of the Only new findings since parameters or Filter old transport findings is set, not only new findings but also findings in code changed since the baseline are included
Filter old transport findings	If enabled, only findings that were introduced in a still-open transport request will be included. This setting should only be active in check variants used for ATC checks on transport release. Note that the creation date of the oldest relevant transport request is used.

Baseline parameters are mutually exclusive

The three check parameters Only new findings since (label), Only new findings since (date), and Filter old transport findings all affect to which degree old findings should be returned. In order to have consistent information in all cases, only one of these parameters may be used. If you need different baseline settings for different use cases, e.g. one for on-demand checks and one for check on transport release, different check variants must be used.

Execute the Check Variant.

After the variant is saved, it can be executed like any other Code Inspector variant, e.g. by transaction SCI or from the ABAP Workbench (SE80) using the commands Check > Code Inspector or Check > ABAP Test Cockpit (ATC). Note that you must edit the DEFAULT variant if the Teamscale findings test should be executed when running these Check commands, unless you use command ABAP Test Cockpit (ATC) with ....

The results are displayed in the ATC results browser:

By clicking on the info button at the single messages (leaves in the tree), the Findings Details view of the Teamscale web UI opens, where e.g. more information of the finding can be viewed. Here, the finding can be assigned to a task or flagged as tolerated finding or false positive finding. (Note that the info buttons at other nodes than the leaves are without any meaningful function.)

Integration with SAP Transport Management System

As described in the section above, the SAP Code Inspector test Teamscale Findings allows to retrieve findings from Teamscale and display these in the SAP system. Thus, Teamscale findings can be used in the SAP Transport Management System (TMS) like any other ATC checks. The prerequisites for this are the same as for regular ATC integration, so please make sure to follow the instructions above.

Depending on you SAP release and patch level, different options may be available for configuring ATC runs on transport release or task release.

SAP Note for check on task release

In case one of ATC configuration options is not available in your system (in particular the option to execute checks on task release), please check SAP Note 2495410 (login required), which enables the respective functionality on older systems.

To enable the ATC check on transport release, the following configuration is required:

1. Define a Code Inspector variant which executes the test Teamscale Findings (see previous section).
2. Ensure that checks on request release are globally activated: Transaction SE03 (Transport Organizer Tools), item Administration > Global Customizing, setting for Check Objects when Request Released.
3. In transaction ATC, under ATC Administration > Setup > Configure ATC, configure the respective Code Inspector variant and the setting ATC: Behavior on Release. Choose Inform on Errors (recommended) or Block on Errors.
4. Save.

SAP Note to only consider changed sub-objects

In order to best follow the campsite rule, we suggest implementing SAP Note 3392749 (login required). This adds the option Restrict Findings to Objects on Transports to the ATC settings. Without it, if one method of a class was changed, ATC will report findings for all other method includes (changed or unchanged) as well.

When releasing a transport request or task, depending on your configuration, the check variant will be executed, query Teamscale findings, and display them or block the release. In case individual findings should not block the release, we recommend using Teamscale's toleration feature.

Teamscale Features for SAP ABAP

Properties of ABAP Code Objects

On SAP systems, developers are able to view various information about code objects. However, doing so requires considerable efforts in knowing

• in which database tables they are stored and formulating SQL queries to retrieve them; or
• which user interfaces display them; or
• which APIs are utilized internally to retrieve them.

Teamscale saves ABAP developers these efforts by retrieving the information. A user can later see them on the Code view by clicking Actions > Abap Object Properties.