Between Applications

The other assistants bring a new system into CMS. This one solves the opposite case: both sides are already configured and the middle piece is missing — the Transformer that converts one payload into the other’s format, and the forward that links one to the other.

Opens from the “Integrate two Definitions” button, under Transformers.

The Observed Contract

Writing that Transformer by hand means knowing the format on both sides. CMS works that out on its own: as messages go through, it builds a schema of what actually flows in each Collector and Delivery — which fields appear, of what type, and in how many of the observed messages.

That last part is what makes the difference. A real example:

samples=5   required=[order, status]
  order        string          in 5 of 5
  status       string          in 5 of 5
  items        number|string   in 4 of 5
  note         string          in 2 of 5

The contract does not merely say “there is an items field”. It says items arrives sometimes as a number, sometimes as text, and that it is missing in one of the five. A Transformer written without that would break on the third message.

The three steps

1. Choose source and destination

The source can be a Collector or a Delivery — whoever produces a message can be either. The destination is always a Delivery, which is who consumes in the CMS model.

Both combos have text search and come grouped by the Application’s Connection Type category (SAP, database, IoT…), with the Application icon and Application · Interface under each code — in an installation with dozens of Definitions, identical codes in different Applications were indistinguishable. The ✓ next to a code marks the ones that already have an observed contract.

If either side has no observed contract yet, the wizard stops with a clear error. Better to refuse than to generate a script over a format nobody knows — let some traffic flow and come back.

2. Generate the script

The AI receives both schemas and writes the Transformer. Note what it receives: the schemas, not the messages. It needs to know that goodQuantity: number exists, not that order 4711 had 37 pieces.

In the example above, it was the schema that made the script come out with a type conversion and a default for the missing field — the AI handled the hard case without seeing a single message, because the contract already told the story.

3. Test against real traffic, and apply

The generated script runs against messages the source has already processed, inside the Transformer sandbox, on the server. Real messages never leave: the AI wrote the script without seeing the data, and the data validates the script without leaving home.

The result comes as “X of Y converted”. When one fails, CMS shows the payload that caused the failure (up to five) — without that you would only know that “some failed”, which is the least useful information possible.

The apply button only unlocks after the test has run. Applying without testing wastes exactly the part only CMS can do.

On apply, the Transformer (marked as AI-generated) and the forward from source to destination are created — the latter, like everything an assistant creates, disabled.

Privacy, in one line

Schemas go to the AI; messages do not. The test runs on the CMS server. If your policy forbids sending even data structure to an external provider, use a local model — CMS talks to OpenAI-compatible providers, which includes Ollama running on your network.