SonarQube is an open-source platform to inspect and improve code quality of more than 20 languages. It aims at identifying bugs, security vulnerabilities, code smells and can be used as guideline for code complexity or test coverage. To achieve this static program analysis SonarCube supports integration with build tools like Maven and continuous integration (CI) tools like Jenkins in form of a so called scanner, which runs through all the code and executes pre-designed rulkes to pass pre-designed quality gates.

NWDI (SAP NetWeaver Development Infrastructure) is the code repository and transport mechanism for SAP’s Java-based development on the PO (Process Orchestration). It strictly follows the SAP’s component model, meaning a piece of Code must belong to a Software Component (SC). The NWDI is mandatory for managing the source code and PI artefacts like iFlows of the PO.

(Source https://docs.sonarqube.org/latest/architecture/architecture-integration/)

The picture above shows how SonarQube integrates with other tools.

It seems to be a normal setup in state-of-the-art development projects, where source control management systems like Git or SVN are in place. Here you normally use a certain SonarQube Scanners to analyze the code with dedicated plugins for tools like MSBuild, Maven, Gradle, Ant, Jenkins.

Problem:

What if you have a different project setup, but the customer instructs you to use SonarQube in your project, otherwise your piece of software will never see a productive system? At least all developers that are in a BPM or PI project using the PO are strategically bound to the NWDI; they have a different setup indeed.

Solution:

Luckily SonarQube also has a command-line based code scanner for all operating systems which can be used if there are none of the above integration tools, but an NWDI. So here is briefly what needs to be done to get this NWDI-SonarQube-scenario running:

1. download and unzip the command-line based scanner. See: https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
2. adjust the target-SonarQube-server in /conf/sonar-scanner.properties
3. create a start batch file. It could happen that you are not allowed to permanently set system variables on customer Laptops or virtual desktops, so It might help creating a batch file for           a) to set the bin path with this command: path %path%;C:\xxx\sonar-scanner\binb) the scanner execution with this command: sonar-scanner -D project.settings=                  C:\xxx\myProject.properties
4. configure all project relevant properties in a properties file e.g. myProject.properties. – Mandatory information is:sonar.projectName=myProject // more or less free textsonar.projectKey=myProject  //this has to match the project name given in SonarQubesonar.projectVersion=1.0 // maintain it, to make use of the SonarQube project history

   sonar.java.source=1.6 // if you are on NW731 or 7.40 you still need to maintain an elder Java version here, because SonarQube uses Java 8.

   sonar.projectBaseDir=C:/workspace.jdi/0 //the root-path of your development configuration containing the (checked out) sources

   sonar.java.binaries=t/. // pointing to all build-files in your workspace

   sonar.sources=DCs/myProject/xyz // only here are the to-be-scanned sources

5. execute the batch file from 3.) to get the scanner running and subsequently transmitting the results to the SonarQube server.