Configuration assistants
Configuring an integration by hand requires knowing the other side’s contract: which endpoints exist, which fields are mandatory, what the table is called, what the key is, which BAPI SAP expects. That knowledge usually lives in a Swagger file, in a database catalog, in a file on a network share — or in someone’s head. Translating it into Interface, Collection and Delivery is repetitive work, where getting one name wrong costs an afternoon.
The assistants do that translation. You point at the source, review what will be created, and install.
In numbers: pointing at the URL of an API with Swagger and installing takes minutes, and covers operations that would take hours to enter field by field. The gain is not only time — it is errors that do not happen, because the field name came from the contract, not from typing.
The six assistants
| Assistant | When | Where it lives | Uses AI |
|---|---|---|---|
| Discovery by URL | The other side is an API — Swagger, OData, WSDL, Postman, MCP, or just a URL | Wand icon in Applications | Yes |
| Database catalog | The other side is a database | Table icon in External Connections or Applications | No |
| Folder catalog | The other side drops files in a folder | The same icon, on a file connection | No |
| SAP Packs | The other side is SAP ECC/S4 (PP, QM, PM) | Boxes icon in Applications | No |
| Between Applications | Both sides already exist in the CMS and only the link is missing | Button in Transformers | Yes |
| Transformer by AI | You know the input and output formats but do not write code | Transformer editor | Yes |
The icon that opens an assistant is always purple and sits last in the actions column.
Which assistant is offered depends on the Application type. An Application with an SAP RFC Connection gets the pack; one with a database or folder connection gets the catalog; the rest get discovery by URL. Where none applies — MQTT, OPC UA, Modbus — no icon appears: offering an inapplicable form is worse than offering nothing.
What they all have in common
These four rules hold for every assistant, and they are what makes it safe to let them generate configuration in bulk.
You see it before it is written
No assistant writes to the database without showing the result first. The review lists every object with the action it will take:
| Mark | Means |
|---|---|
| CREATE | Does not exist yet |
| UPDATE | Already exists and will be overwritten by what the assistant generated |
| CUSTOMISED | Already exists and was changed by hand after the last install — it is left alone |
CUSTOMISED is what makes reinstalling safe: what you adjusted stays yours.
In the database assistants, the review also shows the SQL command that will be stored. Whoever runs a database wants to read the command before letting it run.
The names are yours
Every proposed code is editable in the review, and each generated Interface can be swapped for an existing Interface — useful when you do not want a new queue for everything. Changing the name there fixes every reference at once.
Nothing is born switched on
Collections, Deliveries and forwardings created by an assistant are born disabled. The install prepares the configuration; you decide it may run, after checking. Interfaces are born active — they exist only to group.
Who installed what is recorded
Every install records what was created, by whom and when. That is what lets the CMS know, next time, what is its own and what you customised — and it is what shows up in the audit log.
The role of Artificial Intelligence
AI takes part in three assistants — discovery by URL, between Applications and Transformer generation — and does not take part in the database catalog, the folder catalog or the SAP packs.
The criterion is simple: where exact information exists, inventing makes it worse. A database
catalog states precisely what the columns and the key are; a file sample states the encoding and the
delimiter; the SAP pack knows the BAPI. AI there could only get it wrong. But a Swagger with 450
operations brings names like EventControlController_findAll, without saying which business scenario
it serves or whether it is input or output — and that is exactly what AI is good at.
What the AI does:
- names and groups operations into business scenarios;
- decides the direction (Collection or Delivery) of each operation;
- writes the Transformer that converts one side’s payload into the other’s format.
What it never does: invent a field that is not in the contract, or see production data.
Privacy
| Goes to the AI | Never goes |
|---|---|
| Field names and types (schema) | Message content |
| Contract structure (Swagger, OData, WSDL) | Token, password, API key |
| The prompt you wrote | Production payload |
Secrets are redacted before any text reaches the model — including when they appear inside a sample request within the contract. In the Between Applications assistant, only the schema goes in the prompt; the generated script is tested against real messages inside the CMS server, where they already were.
AI must be configured in Settings → AI. Without it, contract-based discovery (Swagger, OData, WSDL, Postman, MCP) keeps working — what you lose is the grouping by scenario and the Transformer generation.
If company policy forbids sending anything outside, point the provider at a local model: the CMS talks to any server compatible with the OpenAI API, which includes Ollama running on your network. Generation then happens entirely inside the company.