Concepts

Almost every CMS setup combines the same few objects. Understanding this chain answers most usage questions.

Application

Represents an integrated system (ERP, MES, WMS, scale, PLC…). It has a short code — used in URLs and reports — and is the grouping unit of the system: interfaces, definitions, tokens, alerts and reports are always organized by Application.

The Application is also the availability monitoring unit: CMS checks its connection in cycles (keep-alive), records online/offline periods and produces the uptime report.

The selector at the top of the screen sets the Application in focus: pick one and the screens show only what belongs to it, and that choice follows you across screens.

Ticket tools (Help Desk) are Applications too, in a category of their own. They show up in Interfaces, Message Definition and the Messages filters, but stay out of the Application in focus selector and out of the shop-floor configuration screens.

Interface

A processing interface. It defines how messages in that flow are consumed:

• Sequential — one message at a time, preserving arrival order.
• Parallel — several messages at once, with configurable concurrency.

An Interface can be blocked (manually or automatically by a business error rule). While blocked, messages keep arriving but are not delivered — which avoids firing hundreds of errors at a destination system already known to be down.

Delivery Definition

The delivery contract: where the message goes and how.

Delivery type

Defines the protocol used to deliver the message to the destination:

Fields common to every type

Fields by delivery type

Collector Definition

The mirror image of the Delivery Definition: instead of waiting for someone to send, CMS goes and fetches.

Collector type

Defines where the data comes from and how it is obtained:

Fields common to every type

The frequency of pull types belongs to the Interface (interval in milliseconds or a cron expression), not to the Collector. Turning it on and off, and running it now, live on the Schedulers screen.

Fields by collector type

The result mode of SQL queries decides the granularity: LINHA_UNICA_PAYLOAD_UNICO (the whole result becomes one message) or UMA_LINHA_POR_PAYLOAD (each row becomes its own message).

Transformer

Sandboxed JavaScript (node:vm inside worker_threads, in an isolated pool) that takes a payload and returns another: JSON ↔ XML, field remapping, aggregate calculation.

The same Transformer is reusable in Delivery Definitions and Collectors. It can be written by hand in the Monaco editor or generated by AI from an input sample, an output sample and a prompt — with generation history and explicit approval before it goes live.

On a Delivery that receives from several systems in different formats, each producer Application can have a Transformer of its own, which converts that producer’s format into the Delivery’s and runs before the Delivery Transformer — see Transformer by producer Application.

External Connection

Reusable connection settings, with a test connection button. Collectors and Deliveries point at a Connection instead of repeating host/port/user in every configuration.

The connection type linked to the Application decides which Collector and Delivery types are available in it — an Application with a MongoDB connection, for instance, only offers the MONGODB Collector and the MONGODB_WRITE Delivery.

Variables

Reusable values that go into Collector, Delivery and Transformer settings through {{name}} — addresses, plant codes, names that change from one environment to another. They come in two scopes: Global (valid across the CMS) and Per Application (valid only inside it). When the same name exists in both, the Application value wins.

They exist to pull out of each configuration whatever changes between environments: what differs from development to production lives in one place, instead of scattered across dozens of definitions.

Credential

Authentication used on outbound calls (HTTP/SOAP): basic, bearer, header token, WS-Security. Stored encrypted at rest and never returned by the API.

How it all fits together

Application (MES)
 └── Interface (MES_PALLET)           ← ordering, concurrency, blocking
      ├── Definition (AnyToMES_Pallet) ← destination, timeout, retries, transformer
      │    ├── Credential              ← how to authenticate at the destination
      │    └── Transformer             ← how to convert the payload
      └── Collector (SAP_ProdOrder)    ← external source + forwardings
           └── External Connection     ← host/port/user for SAP, MQTT, OPC UA…