Discovery by URL

This assistant starts from an API address and returns a configuration proposal. It is the generalist of the set: it works for any system that speaks HTTP, whether or not it has formal documentation.

Opens from the wand icon on the Application row, under Applications.

What you can provide

A URL, and optionally a note about what you want from that API.

Contracts it understands

The type is detected by content, not by extension — a Swagger served at /api with no extension at all is recognised just the same.

Paths it tries on its own

First, the address you pasted itself: if it already is the contract (.../$metadata, .../openapi.json, ...?wsdl), that is the one used. Alongside it, the $metadata right below it and the one a level up — the case of someone who pasted the root of an OData service or the URL of an EntitySet.

If none of that answers, CMS tries the conventional paths from the host and from the first levels of the address: /openapi.json, /swagger.json, /api-json, /v3/api-docs, /swagger/v1/swagger.json, /api-docs and /$metadata — the latter at every level of the path, because the root of an SAP service sits deep. Parameters such as sap-client go along.

OData

Enter the service root, not just the host. A host usually publishes several services — an SAP Gateway has hundreds — and only the root of each one has a $metadata. The URL of an EntitySet or of an entity (.../Customers('ALFKI')) works too: CMS walks up to the root.

The version comes from the $metadata itself, and the configuration follows its rules:

What the service declares is respected: a read-only set (sap:creatable="false" on SAP, Capabilities annotations in v4) gets no write, a media entity gets no JSON create, and $format=json already comes in the Collector’s Fixed Parameters — without it SAP answers in XML.

SAP Gateway Application

On an Application of the SAP Gateway type, the URL opens as http://host:port/sap/opu/odata/sap/ — complete it with the service (PP_PRODOPS_CONFIRM_SRV/). Leaving only that prefix is rejected with a clear message: SAP would answer 500 “Access using a ‘ZERO’ service”, because there is no service there.

• Reading the contract uses the connection user and client — or the Credential picked in the assistant —, but only when the URL is the connection’s server. For any other address the call goes out without authentication and without following redirects, so nobody receives the SAP user by typing an address of their own.
• The Contract field also accepts the contract URL (.../PP_PRODOPS_CONFIRM_SRV/$metadata), downloaded on the spot. If it cannot be downloaded, the message shows the status the server returned.

The probe, and its limits

When there is no contract, CMS makes a real request to the URL to see what comes back. That is a call into the customer’s system, so it is fenced in:

• GET only — nothing that changes state;
• 10 seconds timeout;
• 1 MB response, at most;
• 3 redirects, at most;
• cloud metadata addresses (AWS/Azure/GCP’s 169.254.169.254 and equivalents) are blocked, so that a URL pasted by mistake does not turn into reading an instance credential.

Where each operation came from

Every operation in the list carries a provenance tag, and it is what separates what CMS knows from what it supposes:

Pay particular attention to the INFERRED ones when reviewing: those are the ones that can be plausible and wrong at the same time.

The operation list

A real-world Swagger file brings hundreds of operations. The list is built for that:

• grouped by scenario, groups collapsed, with a count on each;
• select / clear a whole group at once;
• filter by direction (Collector or Delivery) and text search — searching opens the groups by itself;
• detail on demand: required fields and a body example are fetched when you click “view detail”, not for all 450 operations at once.

Review and install

Before writing, the review shows each object as CREATE, UPDATE or CUSTOMIZED, and lets you rename any code or point at an existing Interface instead of the proposed one.

Test the reads now runs the selected Collectors against the API, at the address and with the Fixed Parameters they will have, and shows each response. Deliveries are never fired from there — they would write to the target system. A read that depends on a message field (the key in /OrdemSet('{{Aufnr}}')) can only be tested with a real message.

The Application URL. The Collector calls the Application’s address plus the operation path. If the Application has no URL yet, it gets the base URL confirmed in the assistant. If it has only the host, the Collectors carry the service root path (/sap/opu/odata/sap/API_X_SRV/OrdemSet). A URL on another host is not changed — that is the call of whoever registered the Application (a proxy, another environment) — so check the Collectors’ path after installing.

After installing, the assistant shows what was created, with a link to each screen — Interfaces, Collectors, Deliveries and Business Errors. Since everything is born disabled, that link is the next step, not a detail.

Authentication

If the API requires a credential, register it first under Credentials and pick it in the assistant. CMS covers Basic, Bearer, API Key, token login and OAuth2 client credentials — the latter with automatic renewal, scope and extra parameters when the provider demands them.