Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide

The Sign-Off Table

Lesson 3 of 5

BTP pipelines

18 min

Listen to this lesson

0:00 / 6:10

Side-by-side extensions on SAP BTP are delivered the way most modern software is: through a continuous integration and delivery pipeline. Every change goes through the same automated stages, and a failing stage stops the change. For Contoso's fleet warranty portal, a CAP service with a Fiori elements UI, the pipeline is the quality gate.

The managed pipeline for CAP

SAP Continuous Integration and Delivery provides a predefined pipeline for CAP projects that works with Node.js, Java and multi-target application (MTA) projects. You subscribe to the service in a BTP subaccount, connect your repository, add a webhook so pushes trigger builds, and create a job with the CAP pipeline. Stages are switched on and configured in the job editor or in a configuration file in the repository. SAP tutorials and blogs describe stages such as build with additional unit tests, acceptance with deployment to a Cloud Foundry space, malware scan, compliance and release. Stage names and options change over time, so check the current service documentation for your setup.

A push starts the whole chain; after the pipeline, Cloud Transport Management promotes the archive under the agreed controls.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-304

BuildBuild the MTA archive; run unit tests through the project's test script. Failing tests stop the job.
AcceptanceDeploy to a test space and run end-to-end or integration tests against it.
ScansMalware scan of the project files; compliance checks where configured.
ReleaseDeploy to the target space, or upload the archive to SAP Cloud Transport Management.
PromoteCloud Transport Management imports the archive into test and production nodes under control.

A typical pipeline for a CAP application on SAP BTP.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-304

SAP's tutorial for the CAP pipeline is explicit that when unit tests fail, the job is marked failed and later stages do not run. That is the essence of a gate: a failing check stops promotion automatically, without a meeting.

Testing CAP services

CAP gives developers fast inner-loop testing. The CAP documentation describes how imported remote services, such as an S/4HANA API, are mocked automatically when you run locally: a CDS service definition is enough to serve a working OData service, with sample data from CSV files next to the model. Tests can therefore exercise the extension's logic against mocked S/4HANA services in seconds, inside the pipeline, without a connected backend. Integration against the real backend then happens in the acceptance stage or in a test subaccount connected to CMQ.

The same CAP logic is tested twice: in seconds against a mocked S/4HANA service, then against the real CMQ in acceptance.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-304

Unit testsService handlers and validation logic, against mocked remote services; run in the build stage.

API testsOData requests against the deployed service in a test space; run in the acceptance stage.

UI testsFiori elements and UI5 integration tests in a headless browser; run in the acceptance stage.

Process testsEnd-to-end through BTP and S/4HANA in CMQ; run after promotion to the test node.

Test levels for a CAP and Fiori extension and where each runs.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-304

Testing UI5 and Fiori front ends

UI5 ships its own test frameworks: QUnit for unit tests of controllers and formatters, and OPA5 for integration tests that drive the app through its controls and wait until the app is idle before acting (see sap-tau-202). Both run in a browser, so in a pipeline they run in a headless browser through a test runner. Keep them fast: the pipeline runs on every push, and a 40-minute UI suite in the build stage turns fast feedback into a queue.

Stage	Target duration	Contents at Contoso
Build with unit tests	Under 5 minutes	CAP handler tests with mocks, UI5 QUnit tests, lint
Acceptance	10–20 minutes	Deploy to test space, OData API tests, a small OPA5 integration set
Nightly	Up to an hour	Full UI suite and end-to-end process tests through CMQ

Ordering pipeline stages by speed for fast feedback.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-304

Hands-on lab · ACCELQ

Create a CI Job and start it from your pipeline

A CI Job is a saved run definition that outside tools can start. ACCELQ offers a REST trigger for it, so any pipeline that can make an HTTP call can run your suite as a gate and keep its credentials in the pipeline's secret store.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first.
Take a short smoke Scenario on the cart from an earlier lab, or record one: Initiate Browser Session, open a category, verify a product list appears.
Click + > Test Suite, choose Static, name it Cart smoke and add the Scenario.
Click Run on the suite. Under When to Run, choose Create a CI Job, then pick the App Environment, your Local Agent, a browser and Optimal screenshots. Click Create Job and copy the job ID from the confirmation.
From your User Profile's Auth properties, copy your API key, tenant code and project code. Put the key in your pipeline's secret store, or an environment variable for this lab, never in a repository.
Build the trigger: a PUT to https://{your ACCELQ server}/awb/api/{tenant code}/{project code}/v1/api_access/jobs/trigger-job with headers user_id, api_key and Content-Type: application/json, and the body {"jobPid": "your job ID"}. Add runProperties only if the job uses them.
Send it with your Local Agent running. The response lists the run PIDs it started. Watch Results: the job sits in Scheduled until the Agent picks it up.
Open the live Test Report. If you use Jenkins, compare this with the accelq-ci-connect plugin's ACCELQ CONNECT Post Build Action.

Done when A Test Report started by your HTTP call rather than the Run button, and a saved trigger request whose API key comes from a secret, not the file. Keep the report link and the redacted request.

Learn more in ACCELQ’s docs: REST API end-point to trigger test execution externally · How do I create a job that I can invoke from CI tool · CI Test Execution: Jenkins

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

What would you do?

The warranty portal team wants to add the full 35-minute end-to-end UI suite to the build stage so nothing slips through. Developers already complain about waiting. What should the test automation engineer recommend?

Key points

SAP Continuous Integration and Delivery offers a predefined CAP pipeline with build, acceptance, scan and release stages.
A failing stage stops the job and later stages, which makes the pipeline a gate.
CAP mocks remote services locally, so unit tests run fast without a backend.
UI5 tests use QUnit and OPA5, run headless in the pipeline; keep build-stage suites fast.
Order stages by speed; run long suites nightly and before promotion; keep secrets out of repositories.

Check your understanding · not graded

Lesson check

1. What happens in the SAP CAP pipeline when the unit tests in the build stage fail?
2. How does CAP let developers test against S/4HANA services without a connected backend?
3. Which UI5 framework drives an app through its controls for integration tests?
4. In Contoso's BTP path, which step is the human test sign-off gate?