# 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.
- Teamscale Connector for SAP NetWeaver® AS ABAP®
- User and Role for RFC Access
- SAP Connection Configuration in Teamscale
- Asynchronous Full Export
- Secure RFC Communication (optional)
- Additional Analysis Configuration for SAP
- Integration of Teamscale in SAP Development Environment
# 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 incrementally extract source code from the SAP system for code analysis within Teamscale
Execution of SAP Code Inspector (SCI) and export of the inspection results to Teamscale
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. It should work on earlier versions, but this has not been tested.
# 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
.tar.gz source code file.
For transport, place the
R* files from the archive in the
data directories of the transdir of your host machine (typically
/usr/sap/trans on Unix/Linux or
C:\\usr\\sap\\trans on Windows) and import the transport (transaction
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).
# 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
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
The authorizations are required for basic RFC access (including background RFC execution), read access to development objects (source code) and scheduling and releasing (own) batch jobs for asynchronous exports and for enabling test coverage analysis.
Depending on which asynchronous mode -
bgRFC or batch (
BTC) jobs - is chosen, the respective authorizations of the other are not needed.
The role can be defined manually, e.g. using transaction
PFCG , or the predefined role
/CQSE/TEAMSCALE_RFC 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
Use a system user, not a dialog user.
The role described before (e.g.,
/CQSE/TEAMSCALE_RFC ) 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 export of 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
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 perspective and there to the page Settings .
# Configuring Working Directory
First, you should check if a proper working directory is specified in section Server Settings / Teamscale Working Directory .
For the SAP connector, it is required that the working directory is explicitly specified.
Teamscale will save the (historized) code exports in sub-directories 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 working directory will be specified by the system administrator of the Teamscale server, you should check with him/her to define the proper location. It can be specified as absolute or relative path.
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
In the opening dialog, a unique connection ID must be specified, for example the three letter SAP system name 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
|SAP ABAP application server||Mandatory parameter for direct connection: The full
qualified host name of the SAP NetWeaver
application server, e.g., |
|Instance number||Mandatory parameter for direct connection: The
instance number (formerly called system number) of
the SAP NetWeaver application server, e.g., |
|System ID||Mandatory parameter for logon balancing
connection: 3-letter SAP system ID, e.g., |
|SAP message server||Mandatory parameter for logon balancing connection: URL of SAP message server|
|Group||Mandatory parameter for logon balancing connection: Group of SAP NetWeaver application
servers (e.g., |
|SAP message server port||Optional parameter for logon balancing
connection: Port of message server, typically |
|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 |
|SAP client||Mandatory parameter: Defines the client used for
logon (e. g. |
|Logon user||Mandatory parameter for password-based authentication: The SAP user name which should be used by Teamscale|
|Logon password||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 the exported objects and schedule the update intervals.
# SAP Code Retrieval Parameters
See also: Code Inspector Options
|Include objects in default custom namespaces||Specifies if ABAP source code objects within the
default custom namespaces |
|Further custom namespaces||Comma-separated list of further custom
namespaces like |
|Schedule incremental code update||Defines in which interval continuous code changes are retrieved from the SAP system.|
|Schedule full code update||Defines in which interval a full synchronization of the code base is performed.|
|Execute full update asynchronously||If enabled, full export is scheduled asynchronously using the background RFC (bgRFC) protocol.|
|Name of the inbound queue||Only required if Execute full update asynchronously is enabled, specifies the name of the inbound bgRFC queue in the SAP system.|
|Enable ABAP exports archive||If enabled, the exported code changes are archived as Zip files on the disk.|
|Include programs generated from BW objects||If enabled, source code objects generated from
SAP BW objects should be included in the code
/ coverage retrieval. |
This is used for test gap analysis. Note the version prerequisites at the end of this Section.
|Include code coverage data in incremental exports||Specifies if coverage data is retrieved for each incremental export for all objects in the selected namespaces regardless of the code changes.|
|Include code coverage data in full exports||Specifies if the coverage data is retrieved during a full export for all objects in the selected namespaces.|
|Clear table COVRES after the export||If enabled, the table |
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 the code base which 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
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 schedule parameters Schedule incremental code update and Schedule full code update define when code (and further data, e.g. coverage results) is retrieved from the SAP system. Two different intervals must be defined: The incremental update interval and the full synchronization interval. The incremental update only retrieves the objects which 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 observed, if an 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 synchronization interval controls when an export of all code objects (within the specified) namespaces is performed. Since in rare cases the code base can change without the incremental export recognizing the change, a regular synchronization export should be scheduled. This ensures that the exported code repository is synchronized with the actual code repository within the SAP system. Usually, no code change is visible during synchronization. Typically, such missed changes which are only visible in synchronization do not result from regular development but may be caused by special transport or upgrade activities. 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.
Typically it will take some minutes until the initial export occurs.
# Asynchronous Communication
The full code update can be also configured to be executed by asynchronous communication where the exeuction will run in 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 settings Execute full update asynchronously and Name of the inbound queue . Please refere to the detailed description here.
# BW Objects
Export of source code objects generated from SAP BW objects is supported from Teamscale release version 5.1.6 and Teamscale Connector for SAP NetWeaver AS ABAP version 1807 onwards.
# Configuring Account Credentials
After the code retrieval is configured and executed for the first time, Teamscale creates an ABAP repository directory inside the working directory.
This directory contains a Git repository for every SAP system.
As for any repository, account credentials must be configured for accessing it.
By default, Teamscale creates a common entry ABAP Repositories , which points to
With these account credentials, all ABAP repositories can be accessed.
It is recommended to use these credentials in the project configuration.
If you need to configure the account credentials manually for a particular SAP connection, go to section Account Credentials (also at the Settings page of the Admin perspective) and add new credentials, the unique ID can be arbitrarily chosen, e.g.,
In the details, the only field which must be filled is the URL field, which is named The URL of the external server .
The URL must be specified as file URL in the following format:
For Unix/Linux based systems:
For Windows based systems:
<working-dir>refers to the Teamscale working directory (relatively to system root, on Windows backslashes must be replaced by forward slashes), see working directory details
<sap-connection-id>refers to to the identifier of the SAP System connection
<drive-letter>refers to the Windows drive letter, e.g.,
# 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. This follows the standard project configuration as described here where the Git connector and an ABAP-specific analysis profile must be used.
For the Git connector, you should use the default account credentials ABAP Repositories together with a path suffix of the form
# Git Connector Configuration for ABAP
(Here, CQI is the identifier of the SAP System Configuration).
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
Furthermore, the slashes at custom namespaces are replaced by an exclamation mark, thus
/XYZ/ is replaced with
This tables states some examples of ant patterns for including and excluding ABAP source code.
# Examples for ABAP Code File Include/Exclude Patterns
|Pattern||Matched ABAP Source Code Objects|
|All ABAP source code objects in configured namespaces (|
|ABAP source code within local packages (starting with |
|Objects within the top-level package |
|Objects within the package |
|Objects within packages in namespace |
|Objects within the top-level package |
|Programs and program includes only|
|Function groups only|
|Function group |
|Global classes only|
|Global classes where name starts with |
|ABAPUnit test classes only (class addition suffixed with |
|Global interfaces only|
# ABAP Dictionary (DDIC) objects.
Besides the ABAP source code in
*.abap files, also a textual representation of objects defined in the ABAP Dictionary (DDIC) is exported from the SAP system.
The dictionary objects are stored in
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 the representation used in the source code based editors of the ABAP Development Tools for Eclipse (available from SAP NetWeaver7.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|
|All ABAP Dictionary objects in configured namespaces (|
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.
# Asynchronous Full Export
By default, all updates of the ABAP code are retrieved by synchronous communication from the SAP system. The full synchronization update, where the entire code of the configured namespaces is exported, can be alternatively configured to use asynchronous communication.
Asynchronous communication is used to avoid a long run-time of the export job what would block other maintenance jobs and/or result in communication timeouts. A long run-time is to expect especially if SAP Code Inspector check execution is configured.
There are two possibilities to achieve the asynchronous export, and both are fully managed by Teamscale:
- Recommended: 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
- The SAP NetWeaver bgRFC protocol is used for asynchronous communication. For details refer to this article on help.sap.com. This variant should only be used if the batch job scheduling is not possible. As bgRFC jobs are executed in a dialog process in the SAP system, time-outs are possible. It is required that bgRFC is configured accordingly in the SAP system.
In the asynchronous mode, a full synchronization update will only schedule a background job in the SAP system first. Teamscale is not waiting for the update 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 checks is then executed in the background on the SAP system. When the background job finishes, the results will be stored in table. For retrieving the results, Teamscale is polling the SAP system regularly if the scheduled jobs are finished and results are available. If so, the result data is retrieved from the SAP system and the internal ABAP repository of Teamscale gets updated.
The incremental update, which only contains changed objects, is always in synchronous communication mode. Also the 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.
# Asynchronous Export Configuration in Teamscale
The main configuration in Teamscale is made by the option Execute full update asynchronously of the
SAP ABAP System Connection settings.
By default, this will schedule batch jobs in the SAP system to perform the full export.
If bgRFC protocol should be used instead of batch job scheduling, the option Use background RFC (bgRFC) protocol must be enabled, too and a name matching the inbound queue prefix (as specified in the SAP system in
SBGRFCCONF under Define Inbound Dest., see below) must be specified.
Furthermore, 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, it is configurable in the global options how long scheduled jobs are polled from Teamscale if no results could be retrieved for a long time, this is configured in parameter Maximum wait time.
# bgRFC Configuration in the SAP System
BTC Jobs are recommended
By default, this is not required. This is only necessary if the bgRFC protocol should be used instead of batch (BTC) jobs.
To be able to use the asynchronous communication by
bgRFC protocol, the
bgRFC queue used by Teamscale must be configured in the SAP system.
This is done in transaction
The following needs to be configured in
In tab Define Supervisor Dest., a bgRFC supervisor destination must be defined. If this is not yet the case, a new one can be created using the create button. The destination requires a name and to specify a bgRFC supervisor user (the user can be created directly in the opening dialog).
# Define Supervisor Destination in
In tab Define Inbound Dest., a destination must be defined as an inbound destination and an identifying prefix must be assigned. A matching name must be used in the Teamscale connection settings, as described in the next section.
# Define Destination Scheduler in
In tab Scheduler: Destination, a scheduler for the before defined destination must be defined. A new one can be crated using the create button.
# Define Inbound Destination in
The settings must be saved (CTRL+S) before leaving this transaction.
To check the state of queued jobs in the SAP system, transaction
SBGRFCMON can be used.
# Secure RFC Communication (optional)
If the RFC communication between Teamscale and SAP NetWeaver should be secured (encrypted), Teamscale can also connect via Secure Network Communications (SNC) to the SAP system. 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:
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.
The SAP Cryptographic Library must be installed, see SAP Note 1848999.
With the command line tool
sapgenpseof SAP Cryptographic Library, a Personal Security Environment (PSE, stored in a file) for Teamscale must be created. This can be done by executing
sapgenpseon 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 (
*.crtfile) must be exported, again by using
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 user name and password, see below.
STRUSTthe 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
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).
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
sapgenpseis used, see the following examples:
sapgenpse maintain_pk -v -a SNC.crt -p teamscale.pse
sapgenpse seclogin -p teamscale.pse -O root
The Access Control List (ACL) for SNC restrictions must allow RFC communication with the client: In view
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.
If you want to use the client X.509 certificate also for logon instead of user name and password, the certificate must be mapped to the SAPTeamscale user. To do so, an entry in view
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:
The library files from SAP Cryptographic Library must be saved on the Teamscale server, SAP Cryptographic Library can be downloaded from SAP Support Launchpad for the required operating system, search for
cred_v2file must be moved to a directory on the Teamscale server. The file should be only accessible for the operating system user running Teamscale.
The environment variable
SECUDIRmust have been defined pointing to the directory containing
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
In the Settings page of the Admin perspective, 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
|Enable Secure Network Communications (SNC)||Tick to enable SNC|
|SNC name of the communication partner server||The SNC name of the SAP system,
something like |
|Own SNC name of the caller||The client SNC name of Teamscale,
something like |
|Enable the SSO mechanism of SNC||Enable logon by X.509 certificate instead of user name/password|
|Path to X.509 certificate||Path to |
# 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.
# Integrating SAP Code Inspector
Messages resulting from checks of SAP Code Inspector(SCI) can be also shown as findings in Teamscale. 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 is set up accordingly.
# Selecting/Defining a Code Inspector Check
Variant An appropriate Code Inspector variant must be specified, or you can use an existing variant. The variant defines, which checks are executed by Code Inspector. We recommend to enable all tests which might be relevant. A detailed selection of the messages which should lead to findings can be done in the Teamscale analysis profile. Tests which will 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 the Code Inspector checks might be quite long, especially if the whole custom code base is checked. If the execution time is too long, you should also switch off irrelevant checks.
To specify a variant, execute transaction
SCI and create a new check variant.
You should consider to use a public variant as public variants can be made transportable, then the variant could be transported to further systems.
You can also ask our Teamscale support for a pre-defined check variant.
# Code Inspector Settings in SAP ABAP System Connection
# Parameters for SAP Code Inspector Execution during Code Retrieval
|Name of the SAP Code Inspector variant||Name of an SAP Code Inspector variant which should be executed|
|Owner of the SAP Code Inspector variant||Specifies the SAP user name 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 in the admin settings of 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 user name 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 base 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 the incremental update, only the changed ABAP repository objects are checked by SAP Code Inspector, but during the full synchronization update, 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 update at most once every night.
# 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 analysis tool, and analysis groups for Code Inspector must be added in the quality indicators.
- Included file names of the Git connector must also include files with suffix
.sci, e.g., by pattern
- Under the expert options of the Git connector, the Analysis report mapping rule
**.sci -> SAP_CODE_INSPECTORmust be specified.
The latter two are set as defaults for new projects.
If all the above is correctly configured, findings from SAP Code Inspector should be visible in Teamscale like any other Teamscale-internal finding and are updated simultaneously with every code change. Note that during the incremental code update, only changed repository objects are analyzed by SAP Code Inspector. Findings from Code Inspector which affect unchanged objects will only be visible after the full synchronization update of the ABAP repository was performed.
# 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. Thus, it is necessary to activate the coverage analyzer SCOV (Lite). This has to be done manually for every system.
Depending on the actual system, either SCOV Lite (if available) or the regular SCOV has to be used as coverage analyzer.
SCOV Lite is the preferred method, as it has a smaller performance impact.
The following two sections describe how to activate SCOV Lite and standard SCOV.
Please make sure to check which case applies in your situation.
In either case, the activation requires the authorization object
User Rights of Processes
Both SCOV modes 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.
# Activating SCOV Lite
The analysis only needs the lite version of SCOV, which cannot be activated via the transaction
SCOV, but via the
Usage Procedure Logging (UPL) functionality of SAP Solution Manager or programmatically.
The ABAP Connector includes a utility which allows to toggle the SCOV Lite mode on and off.
To execute it, call transaction
/CQSE/SCOV_LITE_TOGG. Once executed, it should confirm with the message
Toggled SCOV state from [OFF] to [LIT]:
If the message says
.. from [LIT] to [OFF], execute the toggle again.
Should there be problems at this point, the coverage analyzer has to be activated via the transaction SCOV (see below).
# Activating SCOV
The coverage analyzer is configured via the transaction
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
No specific settings (e.g., test groups) need to be configured. This image shows the required configuration, the important parts are marked in yellow:
# 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.
Depending on the mode in which SCOV is used, the expected output is slightly different.
When using using SCOV Lite, please ensure the following:
The General Status area shows SCOV Lite is active.
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.
When using the regular SCOV, 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.
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
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
SM36 in the SAP system or have a look at the file
job_status.csv in one of the exported zip files.
Afterwards, adjust the scheduling of the incremental code update 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.
Coverage data is contained in the incremental updates, but not in full code updates.
# Integration of Teamscale in SAP Development Environment
The analysis results of Teamscale can be integrated in the SAP environment again. This will reduce switches between SAP and the web interface of Teamscale. Thus, the user will get most of the relevant information in his usual development environment. An integration is possible with the ABAP Development Tools for Eclipse (ADT), with SAP Code Inspector and hence with the ABAP Workbench. Finally, the SAP Transport Management System can check for Teamscale findings on transport releases.
# ABAP Development Tools for Eclipse
Teamscale can be integrated into Eclipse. Hence findings are shown directly in the IDE. This also works the ABAP Development Tools for Eclipse (ADT) and avoids unnecessary context switches between IDE and the analysis tool. For installation and configuration of the Eclipse plugin, please see this guide.
# SAP Code Inspector and ABAP Workbench Integration
The findings in Teamscale can be also shown the SAP Code Inspector (SCI), like the results of other Code Inspector checks.
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
To achieve this, the Teamscale Connector for SAP NetWeaver® AS ABAP® contains an implementation of a custom SAP Code Inspector test which allows to import findings from Teamscale to the SAP NetWeaver system. To be able to execute the respective Code Inspector test Teamscale Findings, the following configuration steps are required:
# Test Activation
First, Code Inspector test Teamscale Findings must be activated:
- In transaction SCI select the action Code Inspector → Management of → Tests (or Ctrl+Alt+F5).
- There, mark the check boxes at the check classes
/CQSE/CL_CI_CATEGORY_TEAMSCALE(category for Teamscale) and
/CQSE/CL_CI_TEST_TS_FINDINGS(Teamscale findings test).
- Save your changes.
# Definition of a Check Variant
Second, a Code Inspector check variant which contains the Teamscale findings test must be defined. Add a new or edit an existing check variant in transaction SCI 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 IDE access key||The [access key](../../glossary/#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|
|Only new findings since (label)||Optional. If set, only findings which were introduced after the given baseline label are included (the baseline is managed in the Findings perspective of the Teamscale Web UI)|
|Only new findings since (date)||Optional. If set, only findings introduced after the specified date are included (this parameter will be ignored if the »Only new findings since (label)« parameter is already set)|
|Also finds. in changed code||If enabled and also one of the »Only new findings since« parameters is set not only new findings but also findings in code changed since the baseline are included|
As of Teamscale Connector for SAP NetWeaver® AS ABAP® v19.07, you may leave the Teamscale project id parameter empty. This is especially relevant when executing the test in a central ATC check system, which is typically connected to may development systems, and therefore would have to reference different Teamscale projects. If no project ID is provided, the Teamscale Findings test will query Teamscale (version 5.2.1 or later) for projects that have the respective system ID configured in their project options.
# 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 ) by the e.g.
Code Inspector /
ABAP Test Cockpit (ATC) commands.
Note that you must edit the
DEFAULT Code Inspector 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 Code Inspector 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 before, 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 integrated in the SAP Transport Management System (TMS) like any other Code Inspector results. Basically two options for integration exist: Using the function of the ABAP Test Cockpit (ATC) for performing checks on transport release, or using a BAdI implementation which is included in the Teamscale Connector for SAP NetWeaver AS ABAP.
# Using the ATC Check on Transport Request Release
If ABAP Test Cockpit (ATC) is available on your system, it can be used to perform Code Inspector checks on transport request release (note that is not possible to perform checks at task release via ATC, but this is possible with the BAdI implementation (see next section).
To enable the ATC check on transport release, the following configuration is required:
Define a Code Inspector variant which executes the test Teamscale Findings as described in the previous section.
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«.
ATC, item »ATC Administration / Setup / Basic Settings« configure the respective Code Inspector variant and the setting »ATC: Behavior on Release«. Choose »Inform on Errors« or »Block on Errors«. (The setting for »Code Inspector: Behavior on Release « in the ATC basic settings refers to the execution of the DEFAULT Code Inspector variant only)
Save the settings.
# Using the BAdI Implementation for Checks on Transport Request or Task Release
The Teamscale Connector for SAP NetWeaver AS ABAP also includes an implementation of the BAdI
CTS_REQUEST_CHECK to check transport requests and/or transport tasks on release.
This is an alternative to the before mentioned use of ATC if ATC is not available or check on task release should be done.
This again uses the SAP Code Inspector test »Teamscale Findings«. If enabled, findings are displayed to the user:
He or she can then decide if the transport should be canceled or released anyway. Thus, there is no automatic blocking of the release, it always needs confirmation by the user.
To enable the BAdI-based check, the following configuration must be done:
Define a Code Inspector variant which executes the »Teamscale Findings« check as described in the previous section.
Add an entry to customizing table
/CQSE/C_TSTRNCHK, e.g. by using transaction
F5). The parameter settings are described in the table below.
Save the new customizing entry.
|CONFIG ID||Arbitrary configuration identifier.|
|CI VARIANT AT REQUEST RELEASE||Specifies the Code Inspector variant which should be executed on request release. This variant typically only includes the »Teamscale Findings« test. Leave empty if no check should be performed on request release.|
|CI VARIANT AT TASK RELEASE||Specifies the Code Inspector variant which should be executed on task release. This variant typically only includes the »Teamscale Findings« test. Leave empty if no check should be performed on task release.|
|CANCEL IN RFC ON FINDINGS||If enabled, the release will be always
canceled (blocked) when the release is
performed via an RFC call, e. g. from ADT
for Eclipse, and Teamscale findings exist.|
This is currently an experimental feature, we recommend to leave it disabled.
When disabled, transports are always released when called from RFC.
The BAdI-based check is active as long as an SAP Code Inspector variant is set in the customizing table
The check has no effect on code which is not included in the Teamscale project which is configured in the specified Code Inspector variants.