@mcp-abap-adt/adt-clients-legacy

Clients for legacy SAP ABAP systems (SAP_BASIS 7.40, measured on 7.40 SP04), built on @mcp-abap-adt/adt-clients. AdtClientLegacy and AdtExecutorLegacy extend that package's AdtClient and AdtExecutor and only override: each member sends the request measured accepted on SAP_BASIS 7.40 SP04, or keeps an unmeasured request under a collection 7.40 advertises, or answers a refusal without sending a request.

The basis of every claim in this package is SAP_BASIS 7.40 SP04 over RFC, the 7.40 test system. Nothing here is inferred for another release. The probe records behind each claim, and what is not measured, are in docs/LEGACY.md.

Install and construct

npm install @mcp-abap-adt/adt-clients-legacy @mcp-abap-adt/adt-clients

@mcp-abap-adt/adt-clients is a peer dependency (^38.0.0): the consumer installs it, and the legacy classes extend that one copy, so AdtClientLegacy is an AdtClient of the consumer's own version. npm warns when the installed version is outside the range.

import { AdtClientLegacy, AdtExecutorLegacy } from '@mcp-abap-adt/adt-clients-legacy';

const client = new AdtClientLegacy(connection, logger);       // connection: an RFC connection
const executor = new AdtExecutorLegacy(connection, logger);

const program = client.getProgram();                          // the getters 7.40's table serves

• The consumer declares the system type. Nothing here detects a legacy system and no factory chooses a legacy class: createAdtClient(connection, { variant }) of @mcp-abap-adt/adt-clients answers a modern client ('onprem' or 'cloud') only.
• Typed by 7.40's ADT type table (since 0.2.0). AdtClientLegacy is AdtClient<'basis740'> of adt-clients 38, typed by ADT_TYPES_BASIS_740 of @mcp-abap-adt/interfaces-adt: a getter or member that table does not list does not compile (client.getTable(), getClass().checkDeletion()), and every override keeps its base's gate. It is not assignable to a modern AdtClient. The refusals below stay, for callers outside the type system. AdtExecutorLegacy is AdtExecutor<'basis740'> the same way. Every code a member takes is a code of that table ('CLAS/OC', 'FUGR/FF', …): no friendly name, bare R3TR type or lower-case spelling.
• RFC only. The legacy client is supported, and was measured, over RFC; HTTP to a 7.40 system is not a supported wire (no logon without a workaround, a write under a lock answers 423, some reads disagree with RFC; the records are in LEGACY.md). The package does not detect the wire and has no branch for it.
• The package depends on @mcp-abap-adt/adt-clients ^38.0.0. It also exports AdtRequestLegacy.
• Each getter answers a class (since 0.2.0): its legacy class (getProgram(): AdtProgramLegacy<…>, getInclude(): AdtIncludeLegacy<…>, …) or, for a type 7.40 does not have, the base class answering refusals. Each is assignable to the AdtClient getter it overrides. A consumer that names the type of the client it accepts composes that contract from @mcp-abap-adt/interfaces-adt alone (the atoms, the result-set contracts and the config types), as for AdtClient; the compiler checks there that AdtClientLegacy satisfies it. The result-set contracts (IClassResults, …) are imported from @mcp-abap-adt/interfaces-adt.

The package does not engineer around a consumer who ignores what follows: it states what 7.40 SP04 does and passes the request through.

How to read the tables

Where a row says "sends" and its record is a read of a system object (a system program, class, function module or include) rather than of an object a cycle created, LEGACY.md says so; the cycle suites (src/__tests__/integration/legacy/cycles/) measure the read of a created object and T6-20261027 ran them whole on 7.40 SP04 (2026-10-27): the reads of created objects, and the free-name validate of a function group and module are measured there; the DDL source's readTransport 404 by one raw read in the same record (t6-ddl-readTransport).

What a consumer must know

Headers are the caller's

The library passes a request's Accept / Content-Type through unchanged (options.headers, options.accept) and chooses none for 7.40. The measured pairs:

The measured pairs are passed by the tests as a consumer would pass them (integrationHeadersOf).

Empty 200 is not success

• A message class that does not exist reads 200 with an empty body, not 404 — and still does after its delete. Check the body.
• Over HTTP, families 7.40 does not have answer an empty 200 too (over RFC they answer 404). The legacy classes refuse those families, so none of them reads an empty 200 as success. A consumer calling getUtils().readObjectMetadata must check the body.

The rest

• Local class includes' check and validate need the source in the config (getLocalTestClass(), getLocalTypes(), getLocalDefinitions(), getLocalMacros()). Without it the library throws before it sends. With it both are a check run (POST /checkruns, 200).

• A function module's source on 7.40: a parameter comment block is refused (500 ExceptionResourceSaveFailure, "Parameter comment blocks are not allowed"); a plain FUNCTION … ENDFUNCTION body is accepted.

• validate of an existing name answers 400 (InvalidClifName, InvalidProgramName, InvalidMcName, "already exists") for a class, interface, program, include and message class. That is the answer for an existing object, not a failure of the request; a name that is free answers 200. For a function group and a function module, validate answers 200 (measured for an existing name).

• delete is yours to lock. 7.40 has no /sap/bc/adt/deletion/*, so there is no checkDeletion (every one is refused), and delete is one request: DELETE <object URI>?lockHandle=<handle> (plus &corrNr= when the config's transportRequest is given), stateless. The handle is from your own lock(); the member does not lock, unlock or retry. Without a handle the request still goes and SAP's 400 reaches you.

  const include = client.getInclude();
  const config = { includeName: 'ZINCL' };
  const locked = await include.lock(config);                   // stateful
  if (!locked.ok) throw new Error(locked.getError().message);
  const lockHandle = locked.getResult().value;
  try {
    const deleted = await include.delete(config, { headers, lockHandle });
    if (!deleted.ok) throw new Error(deleted.getError().message);
  } finally {
    await include.unlock(config, lockHandle);
  }
  

  A delete with corrNr in a transportable package is measured (the 2026-10-26 live run, LegacyTransportable): lock, DELETE ?lockHandle=&corrNr=, unlock, then 404 on read.

• What ADT does not serve on 7.40 is the user's, one level up. Where-used outside RIS, DDIC sources, transport changes, and the like are not ADT there: a consumer that needs them goes through the legacy MCP server, whose LLM writes ABAP (classes, reports) that does it. This package refuses those members without a request, so no tool can only fail.

The members, per handler

The records B2, B3 (earlier runs) and B4 (the 2026-10-26 cycles) are listed in LEGACY.md. Every handler is the getter AdtClient has for it, fixed to 'basis740'. A member marked refused whose operation ADT_TYPES_BASIS_740 does not list also does not compile; the refusal answers a caller outside the type system.

Class — getClass()

Class includes — getLocalTestClass(), getLocalTypes(), getLocalDefinitions(), getLocalMacros()

Program — getProgram()

Interface — getInterface()

Function group — getFunctionGroup()

A function group has no version members.

Function module — getFunctionModule()

Its members take the group (functionGroupName), required by type.

Function include — getFunctionInclude()

Include — getInclude()

DDL source — getDdl()

Message class — getMessageClass(), and a message — getMessageClassMessage()

Package — getPackage()

Every member refused: the item resource /packages/<name> answers 404 (the collection is advertised, the item is not served) and POST /packages 405. Package contents come through getUtils().fetchNodeStructure('DEVC/K', name), one level per request: the root node answers the subpackages and one node per object type with its NODE_ID, and the objects come with that NODE_ID as nodeId (T6-20261027).

Transport request — getRequest()

A populated list is measured (the 2026-10-26 live run, LegacyTransportable): after a write under the lock with corrNr, the list and readMetadata name the request.

Utilities — getUtils()

Served: search, fetchNodeStructure, getObjectStructure, discovery, getInactiveObjects (7.40 answers the older adtcore:objectReferences document), readObjectMetadata / readObjectSource for the served types, getTypeStructure. readObjectMetadata, readObjectSource, fetchNodeStructure, getObjectStructure and activateObjectsGroup take 7.40's codes (ADT_TYPES_BASIS_740, and DEVC/K for the structure reads; VIEW/DV too for the group activation, ADT_UTILITY_CODES_BASIS_740) and refuse any other without a request — BDEF/BDO, SRVD/SRV, DDLX/EX, DCLS/DL and ENHO/XHH among them. search filters by 7.40's search names (ADT_SEARCH_TYPES_BASIS_740: DEVC, CLAS, INTF, PROG, FUGR, FUNC, DDLS, MSAG, TABL, ENHO, ENHS), since 0.3.0: 7.40 has no object types list, reads a code as its main type, and answers an alias (STRU, DTAB, REPO, INCL, BADI) or an unknown name with no hits — so any other filter does not compile, and is refused without a request. Refused: where-used (7.40 serves it only through RIS), virtual folders, object types, activation runs, group deletion, data preview, and the DDIC and package types' reads. Member by member: LEGACY.md.

Executors — AdtExecutorLegacy

Types 7.40 does not have

getDomain(), getDataElement(), getStructure(), getTable(), getTableType(), getAppendStructure(), getTransformation(), getScalarFunction(), getScalarFunctionImplementation(), getEnhancement(), getAccessControl(), getServiceDefinition(), getServiceBinding(), getBehaviorDefinition(), getBehaviorImplementation(), getMetadataExtension(), getAuthorizationField(), getFeatureToggle(): ADT_TYPES_BASIS_740 has no such API, so the getter does not compile on AdtClientLegacy (since 0.2.0). Called from outside the type system, it hands out a handler and every member of it is refused.

Development

Unit tests need no SAP system: npm test (here, or at the repository root). Live checks need a 7.40 system and its own overlay: see docs/LIVE_TESTING.md.

• npm run check:config checks an overlay that holds both the root package's keys and the legacy keys (environment.is_legacy, legacy_env.*, legacy_740.*). The root package's check:config knows the modern overlays' keys only and refuses an overlay that has legacy keys.
• npm run header:discovery runs the root package's error corpus with the legacy clients probed beside the modern ones; it needs the root package built first (npm run build at the repository root).

License

LGPL-3.0-only