CPIOps

CPIOps: Bringing Git to SAP Integration Suite

CPIOps is a web app that runs inside your own SAP BTP subaccount. It connects to a CPI tenant and a Git repository, and lets you browse artifacts, run a quality check, and commit clean source files to Git from one screen, with no pipeline, CLI, or Docker required.

For the reasoning behind these design choices, see Why CPIOps.

Features

• Browse your CPI packages and artifacts live, straight from the tenant.
• See sync status at a glance: IN_SYNC, CPI_AHEAD, or NOT_IN_GIT.
• Run a quality check before every commit and read the report right there.
• Commit artifacts to Git as extracted source files, never as a zip.
• Every commit is auto-tagged with its CPI version, like OrderToSAP_iFlow@1.4.
• Works with GitHub or GitLab. On GitLab each iFlow is its own repo (group/packageId/artifactId); on GitHub, which has no subgroups, each package is one repo (org/packageId) and every iFlow lives in its own folder. For GitHub set the Git Organization URL to your org (the owner must be an org or the token's own user) and use a token with the repo scope.

Architecture

Everything runs inside your BTP subaccount. Git is used as plain file storage, so there is nothing to set up on the Git side.

How it works

Connect CPI and Git in Settings, browse a package, run the quality check, and commit; the version tag gets applied automatically. See the full step-by-step walkthrough with video and gifs in docs/WALKTHROUGH.md.

Rune: the quality engine

Rune checks code before it reaches Git. It is written in pure TypeScript and runs inside the same CAP process as the rest of the app, so there is nothing extra to install or patch on the tenant side, with no JVM and no CodeNarc ruleset to sync. error findings block the commit; warnings and info surface without getting in your way. It covers Groovy, XSLT, iFlow XML, and ABAP BAdI source.

See the full rule list, grouped by file type, in docs/RUNE.md.

Optional: AI review add-on

CPIOps can optionally connect to an AI review layer that reads iFlows, scripts, and mappings and adds advisory suggestions on top of Rune's findings. It never blocks a commit, it only advises. This layer is experimental, a separate closed add-on, and not part of this repository. Reach out if you'd like a demo.

Run locally

The app is two separate processes in local dev: the CAP backend (API + auth + DB) and the React UI (Vite). The UI proxies /api and /odata calls to the backend, so both need to be running.

Prerequisites:

• Node.js and npm.
• Optionally, @sap/cds-dk installed globally (npm i -g @sap/cds-dk) for convenience running cds commands directly.
• A BTP destination service instance, bound locally via cds bind (see step 1 below) — this is required for the app to start at all. Whether that destination actually points at a real CPI tenant is up to you: without one, the app still starts but there is nothing to browse or commit. See Creating the CPI Destination for the full walkthrough.

1. Start the backend (from cpiops/):

npm install

# Copy the example config files and fill in your own values
cp .env.example .env
cp .cdsrc-private.json.example .cdsrc-private.json

.env only needs LOG_LEVEL (optional) — the CPI destination name, Git provider, and Git group URL aren't set from files at all; you configure them from the app's own Settings screen once it's running, and they're stored in the app's database from then on.

In .cdsrc-private.json, fill in auth.users by hand (its IntegrationContent.credentials.destination value doesn't matter — CPIOps always overrides it at runtime with whatever destination name you set in Settings). For the destinations service, don't hand-edit the binding block — generate it instead with cds bind (already available via the @sap/cds-dk devDependency, no global install needed):

cf login                                              # if not already logged in and targeted at your space
cf create-service destination lite cpiops-destination-dev    # skip if you already have a destination service instance
cf create-service-key cpiops-destination-dev local            # skip if you already have a key for it

npx cds bind destinations -2 cpiops-destination-dev:local

cpiops-destination-dev / local are just suggested names for a first run — the dev suffix keeps this local-only instance from colliding with the cpiops-destination instance the mta.yaml deploy later creates in the same space. Use your own names if you already have an instance and key.

This reads your current cf target and the service key, then writes the resolved destinations.binding block straight into .cdsrc-private.json under the [hybrid] profile, so there's no CF org/space/API-endpoint JSON to copy by hand.

npm run build:api    # pulls the Integration Content OData metadata into CDS models
                      # (only needed once, or again if the SAP API definition changes)
npm run build:db     # deploys the local SQLite schema
npm run start:dev     # starts the CAP server on the `hybrid` profile

The server listens on http://localhost:4004 by default. In hybrid mode, auth is basic auth; log in with the admin or developer user you set up in .cdsrc-private.json. The hybrid profile is what lets the app run on a local SQLite database while still reaching your real CPI tenant through a BTP destination. This port serves the OData/REST API only; there is no UI here.

2. Start the UI (from cpiops/app/cpiops-ui/, in a second terminal):

cd cpiops/app/cpiops-ui/
npm install
npm run dev

Vite serves the React app at http://localhost:5173 and proxies /api and /odata requests to the backend on :4004 (see vite.config.ts). Open http://localhost:5173 in the browser; this is the actual app UI for local development, not :4004.

Deploy to BTP

The app is built to run on Cloud Foundry in your BTP subaccount.

Before you start, you need:

• A BTP subaccount with Cloud Foundry enabled.
• Entitlements for XSUAA and Destination.
• The cf CLI, logged in to your org and space.
• The mbt build tool installed.

Build and deploy:

npm run build:cf    # builds the multi-target archive with mbt
npm run deploy:cf   # deploys the archive to Cloud Foundry

After the deploy:

1. Open the app at its approuter URL — find it with cf app cpiops, or in the BTP cockpit under Cloud Foundry → your space → Applications → cpiops (the UI is bundled into and served by the approuter itself, not through HTML5 Application Repository).
2. Create a Destination that points to your CPI tenant — see Creating the CPI Destination for the full walkthrough (entitling the API plan, creating the service instance and key, and filling in the destination fields).
3. Open Settings in the app and finish the CPI and Git connection.

For what each module and resource in mta.yaml does, see Deployment details.

Settings

Once the app is open, set up:

• CPI connection: base URL and OAuth credentials for your tenant.
• Git: provider, repository, and access token.
• Branch model: a single main branch, or an optional develop → main flow.
• Quality thresholds: tune which Rune findings you care about.

Contributing

Bug reports and feature requests are welcome. Please open an issue in the repo first.

If you'd like to contribute code, please open an issue first to discuss the change before submitting a pull request. This is a young, mostly solo-maintained project, so an unsolicited PR may sit unreviewed for a while; talking it through first means your effort isn't spent on a direction the project isn't ready for.

License

Apache-2.0, see LICENSE.

Roadmap / Status

The full flow, browse, quality check, and commit, has been tested end-to-end against a real test CPI tenant.

Planned next: wiring up the optional AI review add-on (see Optional: AI review add-on) as a connectable layer instead of a separate demo.