abapify

Open, typed tooling for SAP ABAP Development Tools (ADT) — for the terminal, for CI, and for AI agents.

Using abapify? Head to the user documentation at adt-cli.netlify.app — installation, authentication, guides, and the full CLI / MCP / SDK reference.

This README is about the project: what it is, why it exists, and how it is built.

What it is

abapify is a TypeScript monorepo that speaks the same HTTP protocol Eclipse ADT uses to talk to an ABAP system, and turns it into four things you can actually build on:

Surface	Package	For
adt CLI	@abapify/adt-cli (or the single-file bundle @abapify/adt)	Developers in a terminal, scripts, CI pipelines
MCP server	@abapify/adt-mcp	AI assistants and agents (Claude, Copilot, Cursor, Windsurf, …)
ADT sidecar	@abapify/adt-server	Shared deployments that must keep SAP credentials away from agents
TypeScript SDK	@abapify/adt-client, @abapify/adk, …	Tool builders who want typed access to ADT from their own code

All four sit on the same typed contract stack, so a fix in one place reaches every surface.

Why it exists

ADT is the most complete remote API an ABAP system has — it is what powers Eclipse-based ABAP development. But it is an XML-over-HTTP protocol with a security-session handshake, CSRF tokens, lock handles and ETags, and almost no public documentation. Outside Eclipse there was no first-class, scriptable way to use it.

That gap matters more every year:

• ABAP teams want modern workflows — git, code review, pull requests, CI quality gates — without leaving their system of record.
• CI/CD needs headless access — run ATC and ABAP Unit, publish SARIF / JUnit / coverage, move transports, all from a pipeline.
• AI agents need safe, structured tools — not screen-scraping or raw HTTP, but typed operations with the locking and activation rules SAP expects.

abapify closes that gap in the JavaScript ecosystem: npm i and go, no SAP GUI, no Eclipse, no system-side installation.

How it works

flowchart TD
    XSD["SAP XSD schemas<br/>(downloaded + hand-authored)"] --> TSXSD["ts-xsd<br/>parse · build · infer types"]
    TSXSD --> SCHEMAS["adt-schemas<br/>typed schema objects"]
    SCHEMAS --> CONTRACTS["adt-contracts<br/>endpoint descriptors (speci)"]
    CONTRACTS --> CLIENT["adt-client<br/>security session · CSRF · parsing"]
    AUTH["adt-auth<br/>basic · service key · browser SSO"] --> CLIENT
    CLIENT --> ADK["adk<br/>typed ABAP objects · save · lock · ETag"]
    CLIENT --> SERVICES["adt-services<br/>shared operations"]
    ADK --> SERVICES
    SERVICES --> CLI["adt-cli<br/>adt …"]
    SERVICES --> MCP["adt-mcp<br/>MCP tools"]
    MCP --> SERVER["adt-server<br/>sidecar gateway"]
    PLUGINS["plugins<br/>abapGit · gCTS · ATC · AUnit · export · diff"] --> CLI

Loading

The design rests on a few deliberate choices:

1. Contract-first, schema-driven. XSD-backed endpoints follow an XSD → typed schema → speci contract chain; a small number of endpoints still use focused XML parser adapters. Fix a schema once and every caller of that contract picks it up.
2. Shared service layer where applicable. CLI commands and MCP tools reuse transport-agnostic operations in adt-services for shared workflows, while object-specific flows may use adk or typed client contracts directly.
3. Writes go through the ADK. Lock → write → activate → unlock, ETag refresh and batch lock sessions live in one place (adk + adt-locks), so callers cannot get the SAP protocol subtly wrong.
4. Plugins instead of a monolith. Serialization formats (abapGit, gCTS) and command groups (ATC, AUnit, export, diff, gCTS) are plugins behind small interfaces in adt-plugin; core packages never import a concrete plugin.
5. Credentials stay at the edge. Authentication is pluggable (adt-auth + browser adapters). For shared and agent deployments, adt-server holds destinations and credentials and exposes only scoped MCP / REST access.
6. Tested without SAP, verified against SAP. An in-process mock ADT server backed by real recorded responses drives unit and e2e tests; a separate opt-in suite runs against a real system.

The deep dives live in docs/architecture/.

A quick taste

npm i -g @abapify/adt-cli
adt auth login                     # interactive basic auth (pass --service-key <path> for SSO)
adt search "ZCL_*"                 # find objects
adt source get ZCL_MY_CLASS        # read source to stdout
adt checkout package ZMY_PKG ./src # abapGit-compatible files on disk
adt checkin ./src -p ZMY_PKG -t DEVK900001  # push local changes back to SAP

Hooking an AI assistant up is one entry in its MCP config (npx @abapify/adt-mcp). Everything else — commands, MCP tools, SDK usage, CI recipes — is in the user documentation.

Project map

All packages live in packages/ and are published to npm under @abapify/* (except adt-fixtures, which is test-only).

Layer	Packages
Applications	adt-cli · adt · adt-mcp · adt-server · adt-server-client · adt-pilot · adt-proxy · adt-tui
CLI plugins	adt-atc · adt-aunit · adt-diff · adt-export · adt-flow · adt-plugin-gcts-cli
Format plugins	adt-plugin · adt-plugin-abapgit · adt-plugin-gcts
Object model & services	adk · adt-services · adt-locks · adt-lint · adt-codegen
Protocol	adt-client · adt-contracts · adt-schemas · adt-rfc · speci · ts-xsd
Auth & config	adt-auth · browser-auth · adt-playwright · adt-puppeteer · adt-config
ABAP language tooling	aclass · acds · abap-ast · asjson-parser · openai-codegen
Shared & test	logger · adt-fixtures (private)

Package READMEs (where present) live in the package directories, and every package has a reference page on the docs site.

Status

abapify is pre-1.0 and moving fast: all packages share a single version cut from main, though the default release run publishes only affected packages (run publish.yml with affected_only=false to publish everything). The CLI and MCP server cover the day-to-day ADT surface — repository search and navigation, source read/write, DDIC, CDS, RAP (BDEF / SRVD / SRVB), function modules, BAdIs, transports, ATC, ABAP Unit with coverage, abapGit and gCTS round-trips, RFC, STRUST and Fiori Launchpad inventory. Expect breaking changes between minor versions until 1.0.

• What shipped and why: docs/roadmap/shipped.md
• Open questions and next steps: docs/roadmap/future.md
• Changes: CHANGELOG.md

Documentation map

Where	Audience	What
adt-cli.netlify.app	Users	Getting started, guides, CLI / MCP / SDK reference
Package READMEs (npm)	Users	What each package does, install, a minimal example
docs/	Maintainers	Architecture deep dives, roadmap, deployment, design history
openspec/	Maintainers	Behaviour specs and in-flight change proposals
AGENTS.md and .agents/	AI agents	Repository rules, skills, and workflows for coding agents

Contributing

Contributions are welcome — bug reports, endpoint coverage, plugins, docs. Start with CONTRIBUTING.md for the development setup, conventions and release process. Security issues: see SECURITY.md.

License

MIT