@mcp-abap-adt/connection 5.0.0 → 6.0.0

package/docs/INSTALLATION.md

@@ -83,7 +83,7 @@ In your code:
 
 ```typescript
 import 'dotenv/config'; // or require('dotenv').config();
-import { createAbapConnection } from '@mcp-abap-adt/connection';
+import { AdtOnPremConnector, BasicAuthProvider } from '@mcp-abap-adt/connection';
 
 const config = {
   url: process.env.SAP_URL!,
@@ -138,7 +138,7 @@ See [JWT_AUTH_TOOLS.md](./JWT_AUTH_TOOLS.md) for detailed CLI documentation.
 ### Test Installation
 
 ```bash
-node -e "const { createAbapConnection } = require('@mcp-abap-adt/connection'); console.log('✓ Package loaded successfully');"
+node -e "const { AdtOnPremConnector } = require('@mcp-abap-adt/connection'); console.log('✓ Package loaded successfully');"
 ```
 
 ### Test Connection (Basic Auth)
@@ -146,7 +146,7 @@ node -e "const { createAbapConnection } = require('@mcp-abap-adt/connection'); c
 Create `test-connection.js`:
 
 ```javascript
-const { createAbapConnection } = require('@mcp-abap-adt/connection');
+const { AdtOnPremConnector, BasicAuthProvider } = require('@mcp-abap-adt/connection');
 
 const config = {
   url: 'https://your-sap-server.com',
@@ -163,9 +163,15 @@ const logger = {
   debug: (msg) => console.log('[DEBUG]', msg),
 };
 
-const connection = createAbapConnection(config, logger, undefined, undefined, {
-  system: 'onprem', // or 'cloud' — said by you, never detected
-});
+const connection = new AdtOnPremConnector(
+  config,
+  new BasicAuthProvider(config.username!, config.password!),
+  new OnPremHttpTransport(() => ({}), logger, {
+    client: config.client,
+    baseUrl: config.url,
+  }),
+  logger,
+);
 
 connection.connect()
   .then(() =>
@@ -216,7 +222,13 @@ npm install --save-dev typescript @types/node
 ### TypeScript Example
 
 ```typescript
-import { createAbapConnection, SapConfig, ILogger } from '@mcp-abap-adt/connection';
+import {
+  AdtOnPremConnector,
+  BasicAuthProvider,
+  ILogger,
+  OnPremHttpTransport,
+  SapConfig,
+} from '@mcp-abap-adt/connection';
 
 const config: SapConfig = {
   url: 'https://your-sap-server.com',
@@ -233,9 +245,15 @@ const logger: ILogger = {
   debug: (msg: string) => console.log(msg),
 };
 
-const connection = createAbapConnection(config, logger, undefined, undefined, {
-  system: 'onprem', // or 'cloud' — said by you, never detected
-});
+const connection = new AdtOnPremConnector(
+  config,
+  new BasicAuthProvider(config.username!, config.password!),
+  new OnPremHttpTransport(() => ({}), logger, {
+    client: config.client,
+    baseUrl: config.url,
+  }),
+  logger,
+);
 ```
 
 ## Troubleshooting

package/docs/JWT_AUTH_TOOLS.md

@@ -123,13 +123,29 @@ source .env
 Or configure `SapConfig` directly:
 
 ```ts
-import { createAbapConnection } from "@mcp-abap-adt/connection";
-
-const connection = createAbapConnection({
+import {
+  AdtCloudConnector,
+  CloudHttpTransport,
+  TokenAuthProvider,
+} from "@mcp-abap-adt/connection";
+import type { SapConfig } from "@mcp-abap-adt/connection";
+
+const config: SapConfig = {
   url: process.env.SAP_URL!,
   authType: "jwt",
   jwtToken: process.env.SAP_JWT_TOKEN!,
-});
+};
+const logger = console;
+
+const connection = new AdtCloudConnector(
+  config,
+  new TokenAuthProvider(config.jwtToken!),
+  new CloudHttpTransport(() => ({}), logger, {
+    client: config.client,
+    baseUrl: config.url,
+  }),
+  logger,
+);
 
 // Note: Token refresh is handled by @mcp-abap-adt/auth-broker package
 // The refresh token credentials in .env are used by auth-broker, not connection

package/docs/MIGRATION-6.0.md

@@ -0,0 +1,359 @@
+# Migration to 6.0
+
+The factory and the six connection classes are gone. What replaces them is not a
+new API so much as the one 5.0 introduced, now the only one: **you state which
+system, which credential, and which wire, and nothing is worked out for you.**
+
+**The wire is a required argument.** There is no default to fall back to and
+nothing is derived from the config, because which wire a deployment uses is a
+fact about the deployment. It also carries the two things only you can supply —
+the credential's TLS material and the client — so it arrives built.
+
+If you already moved to `AdtOnPremConnector` / `AdtCloudConnector` in 5.0, most
+of this does not apply to you — skip to [Taking the RFC wire](#taking-the-rfc-wire).
+
+## What was removed
+
+| removed | take instead |
+|---|---|
+| `createAbapConnection()` | `new AdtOnPremConnector(...)` or `new AdtCloudConnector(...)` |
+| `BaseAbapConnection`, `OnPremAbapConnection` | `AdtOnPremConnector` + `BasicAuthProvider` |
+| `JwtAbapConnection`, `CloudAbapConnection` | `AdtCloudConnector` + `TokenAuthProvider` |
+| `SamlAbapConnection` | `AdtOnPremConnector` + `SamlAuthProvider` |
+| `CertificateAbapConnection` | `AdtOnPremConnector` + `CertificateAuthProvider` |
+| `KerberosAbapConnection` | — see [Kerberos](#kerberos) |
+| `RfcAbapConnection`, `connectionType: 'rfc'` | `AdtOnPremConnector` + `RfcTransport` |
+| `disconnect({ deadlineMs })` | `disconnect()` — see [Teardown](#teardown) |
+
+## Why
+
+The factory switched on things the caller had already said. Given
+`options.system` it did no inference at all, and without it, it inferred the
+session mechanism from the credential — which is the arrangement that gets one
+of them wrong: a bearer token against an on-prem system is ordinary, and it does
+not make that system a cloud one.
+
+The classes had the same shape of problem one level down. Six subclasses
+distinguished by an argument, and `RfcAbapConnection` was a second translation of
+`SADT_REST_RFC_ENDPOINT` beside `RfcTransport` — two of those drift, and these
+had: the class was missing a default `Accept` header and carried cookie-handling
+code that could never run.
+
+## Basic
+
+```diff
+-import { createAbapConnection } from '@mcp-abap-adt/connection';
++import {
++  AdtOnPremConnector,
++  BasicAuthProvider,
++} from '@mcp-abap-adt/connection';
+
+-const connection = createAbapConnection(config, logger, undefined, undefined, {
+-  system: 'onprem',
+-});
++const connection = new AdtOnPremConnector(
++  config,
++  new BasicAuthProvider(config.username!, config.password!),
++  new OnPremHttpTransport(() => ({}), logger, {
++    client: config.client,
++    baseUrl: config.url,
++  }),
++  logger,
++);
+```
+
+`client` is not decoration: SAP answers `sap-usercontext` with the system
+default rather than the client you asked for, and later requests then route to a
+client you never named — on a read-only one, every write comes back `403`.
+
+## JWT / OAuth2
+
+```diff
+-const connection = createAbapConnection(config, logger, undefined, refresher, {
+-  system: 'cloud',
+-});
++const connection = new AdtCloudConnector(
++  config,
++  new TokenAuthProvider(refresher),
++  new CloudHttpTransport(() => ({}), logger, {
++    client: config.client,
++    baseUrl: config.url,
++  }),
++  logger,
++);
+```
+
+The cloud wire is not the on-prem one with a different name. It asks for a
+session at `/sap/bc/adt/core/http/sessions` and gives it back by `DELETE` on the
+address the server publishes; the on-prem wire has neither, and says goodbye
+through the platform logoff. Handing the wrong one to a connector does not
+compile.
+
+The `ITokenRefresher` that used to be a constructor slot **is** the credential
+now. Hand `TokenAuthProvider` a bare string instead and you get a token with
+nothing behind it — fine for a short task, wrong for anything long-lived.
+
+One behaviour to know about: **a credential refused during `connect()` now
+surfaces.** The old class renewed and retried inside its own CSRF fetch. It does
+not any more, and deliberately: renewal is the provider's, and the provider does
+it on an expiry it can see, on every call that asks for a header. A token the
+provider still believes in and the server refuses is a credential that needs
+attention, and `connect()` is one call you make — so the refusal is yours to
+answer.
+
+The request path changed the same way, and in the same direction: a 401 is no
+longer answered here either. See [A refused credential](#a-refused-credential).
+
+## SAML
+
+```diff
+-const connection = new SamlAbapConnection(config, logger);
++const connection = new AdtOnPremConnector(
++  config,
++  new SamlAuthProvider(config.sessionCookies!),
++  new OnPremHttpTransport(() => ({}), logger, {
++    client: config.client,
++    baseUrl: config.url,
++  }),
++  logger,
++);
+```
+
+The cookies are the credential — there is no `Authorization` header at all.
+
+## Certificates
+
+A certificate authenticates through the transport rather than through a header,
+so this is the one place the two axes touch — and you wire them, because nobody
+else can:
+
+```diff
+-const connection = new CertificateAbapConnection(config, logger);
++const credential = new CertificateAuthProvider(config, certLoader);
++
++const connection = new AdtOnPremConnector(
++  config,
++  credential,
++  new OnPremHttpTransport(
++    // A thunk, not a value: the material is loaded during connect(), so a
++    // wire that read it at construction would read nothing.
++    () => credential.transportMaterial?.() ?? {},
++    logger,
++    { client: config.client, baseUrl: config.url },
++  ),
++  logger,
++);
+```
+
+Forget the thunk and mTLS silently does not happen — the connection is built,
+the requests go out, and the server refuses them for a reason that says nothing
+about the certificate.
+
+## Taking the RFC wire
+
+`connectionType: 'rfc'` is gone. The wire is an argument now, which is what it
+always was in fact:
+
+```diff
+-const connection = createAbapConnection(
+-  { ...config, connectionType: 'rfc' },
+-  logger,
+-);
++import {
++  AdtOnPremConnector,
++  BasicAuthProvider,
++  RfcTransport,
++  rfcConversationFrom,
++} from '@mcp-abap-adt/connection';
++
++const connection = new AdtOnPremConnector(
++  config,
++  new BasicAuthProvider(config.username!, config.password!),
++  new RfcTransport(rfcConversationFrom(config), logger),
++  logger,
++);
+```
+
+The wire sits where the HTTP one sits, because it is the same argument. There is
+no option to set and no config field to flip.
+
+`rfcConversationFrom(config)` does what the class's constructor did: `ashost`
+from the url, `sysnr` from the HTTP port by the SAP convention that `80XX` is
+the ICM port for system `XX`, `SAP_SYSNR` overriding it for a port that follows
+no convention. The SAP NW RFC SDK is loaded when a conversation opens, not when
+this is called, so a machine without it fails at `connect()` with a message
+saying what to install.
+
+Everything above the wire is unchanged: `makeAdtRequest`, `setSessionType`,
+`disconnect`, and the session lifecycle. Three things are better than they were
+on the removed class:
+
+- a default `Accept` is supplied, so a call that names none is answered rather
+  than refused with `400 ExceptionResourceBadRequest`
+- `disconnect()` and `getSessionIdentity()` exist, which they did not
+- the identity is the conversation, and it changes when the conversation does —
+  so reconnecting reads as a different session instead of the same one
+
+**Where to look for the session.** An HTTP session is an ICF session and appears
+in **SM05**. An RFC conversation appears in **SMGW → Logged on Clients** as
+`NWRFC`, and never in SM05, because there is no ICM in that path.
+
+## Teardown
+
+`disconnect()` takes no arguments.
+
+```diff
+-await connection.disconnect({ deadlineMs: 5000 });
++await connection.disconnect();
+```
+
+It **notifies**: it tells the server the session is finished and does not act on
+the answer — whether and when the session is freed is the server's affair. The
+`deadlineMs` it used to accept bounded a wait for that answer, which bought you
+nothing and was the one thing that could make a teardown unbounded, since the
+goodbye carries no request timeout by design. `SAP_RELEASE_DEADLINE_MS` is gone
+with it.
+
+Everything else is unchanged: it resolves rather than throws, always settles,
+and a repeat call performs whatever is still owed.
+
+## Writing your own credential
+
+The shipped ones need no change from you — they are handed to a connector and
+that is all. If you wrote your own against `IAuthProvider`, it now states all of
+itself. Five members, and three of them are usually empty:
+
+```diff
+ class MyCredential implements IAuthProvider {
+   readonly kind = 'mine';
++  async prepare(): Promise<void> {}
+   async authorizationHeader(): Promise<string | null> { … }
++  cookies(): string | null { return null; }
++  transportMaterial(): ICertificateMaterial { return {}; }
+ }
+```
+
+Empty is not ceremony: "nothing to prepare", "I am not cookies", "I contribute
+no TLS material" are facts about a credential, and a fact is stated rather than
+left for a connection to discover by checking whether a method exists. What it
+buys is that no base class asks anything — every question about a collaborator
+is answered by the type.
+
+**One credential still has no home, and this is the honest statement of it.**
+SPNEGO's token is consumed by the first request that carries it, so the exchange
+and the establishing call are the same act — and `establish()` may retry, asking
+`authorizationHeader()` again per attempt, which for that credential means
+presenting something already spent.
+
+An earlier cut of this release answered it with an atom the connection narrowed
+to. That is gone: a contract earns its place by something implementing it, and
+nothing here implements that one. What such a credential needs is either an
+exchange it owns end to end, or a signal that the establishing request
+succeeded — neither exists yet, and inventing the seam before there is a
+credential to test it against is how the last one came to be removed.
+
+Everything shipping today authenticates by header, cookie or TLS material, and
+those three are what `IAuthProvider` states.
+
+Needs `@mcp-abap-adt/interfaces` 21.0.0.
+
+## A refused credential
+
+The connector used to answer a `401` for you: it called `renew()` on the
+credential, compared the header with the previous one, and rebuilt the session if
+it had changed. It does not any more, and nothing replaces it — the refusal
+surfaces.
+
+Renewal splits in two, and only one half was ever automatic:
+
+- a token that **expired** is replaced inside `authorizationHeader()`, which is
+  asked per request. Nobody decides anything, and nothing changed here;
+- a token the provider still **believes in** and the server refuses is a
+  different thing, and whether that is what happened is a judgement made with
+  what you know.
+
+So handle it where you can:
+
+```diff
+-await conn.makeAdtRequest(options); // a 401 was retried underneath you
++try {
++  await conn.makeAdtRequest(options);
++} catch (error) {
++  if (isUnauthorized(error) && isRenewable(credential)) {
++    await credential.renew();
++    // ... and decide for yourself whether to try again
++  }
++  throw error;
++}
+```
+
+`isRenewable` is the narrowing the contract recommends, since only some
+credentials have it — a password has nothing behind it to ask again, and a SAML
+session was negotiated elsewhere:
+
+```typescript
+import type { IAuthProvider, IRenewableCredential } from '@mcp-abap-adt/interfaces';
+
+function isRenewable(c: IAuthProvider): c is IRenewableCredential {
+  return typeof (c as Partial<IRenewableCredential>).renew === 'function';
+}
+```
+
+Needs `@mcp-abap-adt/interfaces` 19.0.0, where `renew()` becomes that atom
+instead of an optional member every credential carried.
+
+**The connection is not torn down over it.** A refused credential is not a lost
+session, and discarding one the server never complained about would throw away
+work you can still finish.
+
+## Kerberos
+
+`KerberosAbapConnection` is removed without a direct replacement. It was
+single-leg only, and untested against a live KDC — issue #35 says so. If you
+depend on it, stay on 5.x and say so on that issue; a `KerberosAuthProvider`
+belongs on the credential axis and can be added there, but it should be added
+with a system to test it against.
+
+## Types you can now name
+
+The seam is public, so a signature can say what it needs instead of taking any
+connection and casting:
+
+```typescript
+import { AdtOnPremConnector, RfcTransport } from '@mcp-abap-adt/connection';
+import type {
+  IAdtTransport,
+  IAdtTransportRequest,
+  IAdtTransportResponse,
+  IAdtEstablishContext,
+  IAdtSessionContext,
+  IOnPremTransport,
+  ICloudTransport,
+  IRfcConversation,
+  RfcConnectionParams,
+} from '@mcp-abap-adt/connection';
+
+function overRfc(conn: AdtOnPremConnector<IAuthProvider, RfcTransport>) { /* ... */ }
+```
+
+### Bringing your own wire
+
+The connectors are constrained by a marker, not by the shipped classes, so a
+transport you write is a first-class one. Say which system it is for and it fits
+where the shipped wires fit:
+
+```typescript
+import type { IOnPremTransport } from '@mcp-abap-adt/connection';
+
+class RecordingTransport implements IOnPremTransport {
+  readonly kind = 'recording';
+  readonly system = 'onprem' as const;
+  // ... the rest of IAdtTransport
+}
+```
+
+`system` is read by the compiler and never at runtime. Its only job is to stop
+"ABAP Cloud over an on-prem wire" from compiling — which is also why the
+constraint is this marker and not `OnPremHttpTransport`: the shipped classes
+carry private state and compare nominally, so constraining to them would have
+made this impossible while appearing to allow it.

package/docs/SCOPE.md

@@ -35,7 +35,7 @@ It forwards every `(name, value)` pair from the JS `Client(params)` object to `R
 
 **4. For BTP on-prem scenarios (Cloud Connector), the JWT→x509/SNC swap happens server-side in the CC.** The client-side RFC call still carries classic credentials (x509 + SNC), not the JWT. Supporting that would be adding SNC-over-RFC for on-prem backends behind a CC tunnel — an on-prem extension, not a "cloud RFC" feature.
 
-**Conclusion:** "RFC to cloud" is not a missing feature that would be useful to add; it is a category error. ADT to cloud = HTTP (already supported here). RFC to on-prem = supported here via `connectionType: 'rfc'`. Anything claiming a third combination does not map to what the SAP stack actually exposes.
+**Conclusion:** "RFC to cloud" is not a missing feature that would be useful to add; it is a category error. ADT to cloud = HTTP (already supported here). RFC to on-prem = supported here, by handing `AdtOnPremConnector` an `RfcTransport`. Anything claiming a third combination does not map to what the SAP stack actually exposes.
 
 ## See also
 

package/docs/STATEFUL_SESSION_GUIDE.md

@@ -26,19 +26,47 @@ The connection layer **does not** decide when to lock/unlock objects—that logi
 
 ## Enabling Stateful Sessions
 
+Every example below builds on this much, so it is stated once:
+
 ```ts
-import { createAbapConnection } from '@mcp-abap-adt/connection';
+import type { SapConfig } from '@mcp-abap-adt/connection';
+
+const config: SapConfig = {
+  url: 'https://your-sap-server.com',
+  authType: 'basic',
+  username: 'your-username',
+  password: 'your-password',
+  client: '100',
+};
+const user = config.username!;
+const pass = config.password!;
+const logger = console;
+```
 
-const connection = createAbapConnection(config, logger, undefined, undefined, {
-  system: 'onprem', // or 'cloud' — said by you, never detected
-});
+```ts
+import {
+  AdtOnPremConnector,
+  BasicAuthProvider,
+  OnPremHttpTransport,
+  getTimeout,
+} from '@mcp-abap-adt/connection';
+
+const connection = new AdtOnPremConnector(
+  config,
+  new BasicAuthProvider(config.username!, config.password!),
+  new OnPremHttpTransport(() => ({}), logger, {
+    client: config.client,
+    baseUrl: config.url,
+  }),
+  logger,
+);
 await connection.connect();   // required before any request
 
 // Enable stateful session mode (adds x-sap-adt-sessiontype: stateful header)
 connection.setSessionType('stateful');
 
 // Now all requests share the same session (cookies, CSRF token)
-await connection.makeAdtRequest({ method: 'GET', url: '/sap/bc/adt/discovery' });
+await connection.makeAdtRequest({ method: 'GET', url: '/sap/bc/adt/discovery' , timeout: getTimeout('default') });
 
 // Switch back to stateless
 connection.setSessionType('stateless');
@@ -49,11 +77,11 @@ connection.setSessionType('stateless');
 ## Knowing Which Session You Are In
 
 ```ts
-import { AdtOnPremConnector, BasicAuthProvider } from '@mcp-abap-adt/connection';
+import { AdtOnPremConnector, BasicAuthProvider, OnPremHttpTransport } from '@mcp-abap-adt/connection';
 
 // getSessionIdentity() is on the HTTP connection classes, NOT on the
-// IAbapConnection type that createAbapConnection() returns.
-const connection = new AdtOnPremConnector(config, new BasicAuthProvider(user, pass), logger);
+// bare IAbapConnection type a caller may hand you.
+const connection = new AdtOnPremConnector(config, new BasicAuthProvider(user, pass), new OnPremHttpTransport(() => ({}), logger, { client: config.client, baseUrl: config.url }), logger);
 await connection.connect();
 
 // Which SAP session this connection is talking to. Changes only when the
@@ -84,11 +112,13 @@ Every ADT request issued through `makeAdtRequest` automatically:
 
 This logic is transparent to callers (Builders, handlers, CLI scripts).
 
-On a JWT connection one case is **not** transparent, and cannot be: a 401 that leads to a token
-refresh also replaces the SAP session, because the renewed credential cannot keep the old one.
-Inside a lock window that surfaces as `ADT_SESSION_REPLACED` rather than a request quietly
-continuing on a session your lock is not in. A 403 never does this — it is an authorization
-answer, not a credential one, and nothing is torn down for it.
+On a JWT connection a 401 is **not** handled here at all, and that is the point: since 6.0.0 the
+refusal surfaces and the session is left alone. Nothing replaces the credential behind you, so
+nothing replaces the SAP session behind you either — a lock window is not torn down by an
+authentication answer. A 403 never did this: it is an authorization answer, not a credential one.
+
+If you decide the refusal meant a stale token, `renew()` and reconnect are yours to call — and a
+reconnect is a NEW session, so do it outside a lock window rather than inside one.
 
 ---
 
@@ -123,6 +153,44 @@ made with the cookies and the answers in hand.
 
 ## A Lock Lives In The ABAP Session
 
+### Three lifetimes, and a dropped connection ends none of them
+
+Before anything else, because conflating these is the mistake that produces
+wrong fixes:
+
+| | what it is | what ends it |
+|---|---|---|
+| **the connection** | one TCP socket | you, the network, a timeout firing. **Ends nothing on the server** |
+| **the HTTP session** | the ICF conversation, held by the cookie jar on this side | dropping the cookies, or a logoff. Nothing about it is in doubt |
+| **the ABAP session** | the server-side context named by `SAP_SESSIONID_<SID>_<CLIENT>` — the roll area a stateful request runs in | **only the server.** Its own idle timeout, which this side can neither read nor influence, or an explicit logoff |
+| **the lock** | an enqueue entry, **owned by the ABAP session** | that ABAP session ending. **When it goes, its locks go with it** |
+
+The two middle rows are the ones worth keeping apart, because everything that
+goes wrong here goes wrong between them. The lock does not belong to the socket
+and does not belong to the cookies — it belongs to the **ABAP session**, and
+that session is the server's. This side never ends one: it can ask (a logoff),
+and otherwise waits for a timeout it cannot see.
+
+A closed socket is just a client that stopped listening. The ABAP session
+neither knows nor cares — which is why `SM04` shows sessions left behind by
+connections that never said they were finished, and why this package sends an
+explicit goodbye at all.
+
+And **a lock is never stranded by something dying** — the opposite. If the ABAP
+session ended, the enqueue entry went with it and there is nothing left to
+strand. A lock is stranded when that session **survives** while the caller no
+longer holds the handle needed to unlock it: both sit there, held, until the
+server's own timeout releases them together.
+
+This is what makes an aborted request expensive, and it is not what it looks
+like. Aborting costs you **knowledge**, not a session: whether the modification
+was applied becomes unknowable, and the handle `unlock` needs is gone, while the
+lock is still very much held. That — not any teardown — is why
+`beginCriticalSection()` raises the effective timeout to a large ceiling for the
+duration of a `lock → modify → unlock` chain.
+
+### Two sessions, and they are not the same thing
+
 There are two sessions here, and they are not the same thing:
 
 - the **HTTP session** — the conversation this client is having. It exists as
@@ -173,17 +241,18 @@ you get by asking — `getSessionIdentity()` for which session you are in, and
   `disconnect()` followed by `connect()` — there is no local-only discard, because
   dropping the cookie leaves the ABAP session open on the server. Both live on
   the HTTP connection classes and are **not** on the `IAbapConnection` type
-  `createAbapConnection()` returns — reach them through a concrete type:
+  a bare `IAbapConnection` carries — reach them through a connector type, or
+  through the `ISessionLifecycleAware` atom:
 
   ```ts
-  import { AdtOnPremConnector, BasicAuthProvider } from '@mcp-abap-adt/connection';
+import { AdtOnPremConnector, BasicAuthProvider, OnPremHttpTransport } from '@mcp-abap-adt/connection';
 
-  const connection = new AdtOnPremConnector(config, new BasicAuthProvider(user, pass), logger);
+  const connection = new AdtOnPremConnector(config, new BasicAuthProvider(user, pass), new OnPremHttpTransport(() => ({}), logger, { client: config.client, baseUrl: config.url }), logger);
   await connection.disconnect(); // ends the session on the server, then clears
   await connection.connect(); // a new session, explicitly
   ```
 - **Session expired**: reauthenticate to obtain a new session.
-- **Multiple connections**: each `createAbapConnection` instance maintains its own cookie jar; share the instance if you need continuity.
+- **Multiple connections**: each connector holds its own wire, and the wire holds the cookie jar; share the instance if you need continuity.
 
 ---