Industry 4.Now
Your MES was built to run production, not to keep dozens of connections alive and overloaded. CMS takes over the integrations, the security and the monitoring — and scales, giving you end-to-end visibility of every integration.
The only industrial integrator with AI: describe the field mapping in plain language and CMS builds the transformer between applications, simply and quickly.
Platform
When there is no integration layer, factory data ends up scattered, integrations become hard to trace and the knowledge remains tied to individuals. The result is an operation that is more dependent, less transparent and more exposed to risk.
We built CMS – Collaborative Manufacturing Suite, a platform designed to centralise, control and monitor the integrations between shop-floor systems and corporate systems, covering both the SAP and non-SAP ecosystems.
CMS was conceived to support the main integration needs of an industrial operation, connecting machines, equipment, factory applications, MES systems, ERPs and other corporate platforms.
The five stages
Every flow goes through the same five stages. That is what turns a new integration into configuration instead of a software project.
A ready REST endpoint for each definition and a SOAP web service with a dynamically generated WSDL. Authentication by application API Token or WS-Security.
When data does not come to you, CMS goes after it: SQL query, BAPI call, MQTT topic, an OPC UA tag that changed, a Modbus register, an HTTP endpoint. On a schedule or on an event.
Given the source and destination payloads, you can use an AI prompt to map the fields in plain language and let CMS build a transformer to be used in your collection and delivery definitions.
Asynchronous or synchronous interface with sequential or parallel ordering, plus timeout, retries and backoff per definition. The destination can be an ERP, a database, an MQTT broker — or a PLC tag.
Application availability by keep-alive, blocked interfaces, message backlog, technical and business errors — with alerts by e-mail, WhatsApp and on-screen notification.
Architecture
Pick the scenario and follow every step of the data. CMS connects enterprise and industrial systems, whatever the protocol, making sure data is received, processed and delivered with every integration fully monitored.
Integrations
Each protocol and technology has its own way in and out — the table shows what the system does in each direction.
| Technology | Inbound (Collection) | Outbound (Delivery) |
|---|---|---|
| HTTP REST | Queries to APIs and inbound calls | Sending, updating and deleting records |
| SOAP | Service published by CMS for the other system to call | Calls to the vendor web services |
| MQTT | Subscription to broker topics | Publishing to topics |
| SQL Server | Reading tables and views, marking what has been read | Writing records and running procedures |
| Oracle | Reading tables and views, marking what has been read | Writing records and running procedures |
| PostgreSQL (includes TimescaleDB) | Reading tables, views and time series | Writing records and running procedures |
| SQLite (file-based database) | Reading tables and views | Writing records |
| InfluxDB (1.8, 2.x and 3.x) | Time series queries and aggregations | Writing measurement points |
| MongoDB | Reading collections, only what changed since the last run | Writing documents |
| MongoDB Atlas | Reading cloud collections over an encrypted connection | Writing documents |
| Azure Cosmos DB (Mongo API) and AWS DocumentDB | Reading collections, through MongoDB compatibility | Writing documents |
| SAP RFC / BAPI | Calling SAP functions and BAPIs | Calling SAP functions and BAPIs |
| SAP IDoc | Receiving IDocs of any type | Sending to SAP through a function or BAPI |
| OPC UA | Reading tags and triggering on value change | Writing tags on the equipment |
| Modbus TCP | Cyclic register reads and triggering on change | Writing to registers |
| Sparkplug B | Subscription to the devices published on the broker | Sending commands to devices |
| PI Web API (AVEVA/OSIsoft) | Current value, history, interpolated and summary | Writing values back to PI |
| Files (directory) | Watching a folder and reading the files that arrive | Generating files in a folder or share |
CMS fetches on an interval or cron expression: HTTP, SQL Server, Oracle, PostgreSQL, SQLite, InfluxDB, MongoDB, SAP RFC, PI Web API, Modbus polling and directory scanning.
The external system delivers when it happens: REST and SOAP intake, MQTT publication, Sparkplug B namespace, SAP IDoc, OPC UA tag trigger and Modbus register change.
The native SAP SDK runs in a separate microservice: a failure in the SAP integration does not take down the API, the scheduler or the workers. On the collection screen you search the function, import its parameters and test the call — with local metadata caching so it works offline.
A listener registered in the SAP gateway receives IDocs sent by the ERP, filtered by IDoc type, message type and partner. Restarting the listener does not affect outbound RFC calls.
Built-in OPC UA and Modbus TCP servers, with named tag profiles per PLC, let you validate triggers and writes end to end before getting access to the real equipment.
Every write to an OPC UA tag or a Modbus register goes through a write permission lock, with a trigger tag and value that release the operation and the written value recorded back at the end.
SAP Manufacturing Packs
The expensive part of integrating with SAP is not the software: it is working out which BAPI to call, which fields it requires, in what order and how to read the return. The CMS ships with that knowledge packaged — you pick the scenario and the interfaces are created configured.
Time ticket or order confirmations, component goods issue, finished goods receipt, order release and technical completion, batches and order backlog reads.
Inspection lot backlog, characteristics to measure with nominal and tolerances, result recording, in-process inspection points, usage decision and quality notifications.
Create and close notifications, technician time confirmation, orders and assets — plus measurement recording straight from OPC UA, Modbus or PI.
PP, QM or PM, on the application that talks to SAP.
The essentials preset comes checked. Add the rest when you need it.
Plant, storage location and movement types. Once, for every interface.
You see exactly what will be created before anything is written.
Before installing, the CMS asks your system whether each function exists and whether the fields match that release. An incompatible recipe is not installed — instead of becoming a broken interface that only fails on the first message.
Your MES sends order, operation and goodQuantity. The pack translates them into AUFNR, VORNR and YIELD. A missing required field is rejected before it reaches SAP, with an error the operator understands.
RU 130 becomes "the order has not been released yet". Closed posting period, insufficient stock, counters that only go up: the most common errors of each scenario ship already mapped.
The CMS already reads OPC UA, Modbus and PI. The maintenance pack closes the other side: the asset hour meter becomes a measurement document in SAP, and the preventive plan triggers by itself. Without a line of code.
Included in the CMS. Not a separate module, no extra licence.
AI-assisted configuration
The packs solve SAP, the system we already know from the inside. The assistant solves the rest of the estate: any API with Swagger, OData, WSDL or a Postman collection — and, when there is no documentation at all, the address plus a sentence saying what you need.
Swagger/OpenAPI in JSON or YAML, the OData $metadata of SAP Gateway, a SOAP WSDL or a Postman collection. CMS recognises it by content, not by extension, and looks through the conventional paths on its own when you give it only the base address.
With no documentation, CMS makes a fenced-in read of the URL — GET only, with limits on time, size and redirects — and uses the real response as its base. You add the intent in plain language: "I need to pull open orders and confirm production".
PostgreSQL, SQL Server, Oracle, SQLite, MongoDB and InfluxDB. The tables, the types and the key are already in there: reading and writing come out ready, with the SQL command in plain sight before anything is saved.
A URL, a contract or a database connection you already registered.
Operations arrive grouped by business scenario, not as a raw list of endpoints.
You see what will be created, rename whatever you want and can reuse existing interfaces.
Everything is born disabled. Nothing starts running because the system decided so.
A database catalog states precisely what the columns and the key are — the AI does not go there, because it could only be wrong. It works where the data is ambiguous: giving business names to 450 operations called EventControllerFindAll and saying which are inbound and which are outbound.
Contract, probe or inference: the origin of each operation stays visible on screen. You know exactly what the system read from an official document and what it guessed — which is where a second look pays off.
Token, password and API key are replaced with markers before any text is sent to the AI, including when they appear inside an example in the contract itself. And the model can be local: CMS talks to OpenAI-compatible providers, which includes an Ollama on your own network.
CMS learns the real format of each queue by watching the traffic. With both formats in hand, it writes the transformer between them and tests it against messages that have already gone through — the script is generated without the AI seeing a single record, and validated without any record leaving the server.
Included in CMS. The AI is optional and can run on your own infrastructure.
Lifecycle
From intake to destination confirmation, every step is persisted. When something fails, the difference between a technical problem and a data problem is already classified.
The message arrives over REST, SOAP or an active collection, and is persisted before any processing.
A job is created in the interface. If the interface is blocked, the message waits — instead of failing against a destination already known to be down.
If the definition has a transformer configured, the system transforms the payload into the destination format.
Sent to the destination with its own timeout. A technical failure enters retry with a wait between attempts; the response is stored in the history.
Success becomes Processed. Transport failure becomes Delivery Error. A response matching a business rule becomes Business Error — and can block the interface.
Errors are resent individually or in bulk, always as a new attempt. The retention policy purges old history.
AI Agent
A queue blocks at three in the morning. Today that becomes an e-mail with an error code and someone opening five screens to work out what happened. The agent walks that path before you do: it runs the tools of the CMS itself against your installation, looks at what actually came back, and hands over a report with the evidence behind every step.
"Why did the ORDERS interface stop?" — it chains interface status, recent errors, message search and the definition, and every line of the report shows what the tool returned. In this mode it only reads: the worst case is a poor answer, never damage.
Given a goal in plain language it probes the source, assembles the plan of Interfaces, Collections and Deliveries, and tests it before showing anything. Writing stays parked until someone approves it on the review screen, object by object.
Blocked queue, piled-up messages, application offline: the alert that fires becomes an investigation, and the report lands in the inbox of whoever receives that alert. It ships switched off — it is the one part of the product that would spend the AI key with nobody having clicked.
One sentence. The scope is the application in focus in the header, not one more form to fill in.
Every tool runs against your installation and the real result goes back into the reasoning. When a probe returns 401, it is the agent that fixes the path — before any screen opens.
The timeline shows which tool ran, what came back and how long it took. There is no conclusion without the step that supports it.
Writing happens on your click, in a review that lists object by object — and it is recorded so it can be undone.
The agent inherits the access profile of whoever opened the session: the same tools, the same applications, the same interfaces. When it investigates an alert on its own, it uses the permission of whoever received that alert. There is no technical user with powers nobody controls.
When it tests a transformer, it runs against the messages that actually went through the queue, and the screen tells you which of the two you are looking at: real traffic or a sample. A test that passes on made-up data proves nothing.
When you ask for a number, the AI only turns the request into a filter and opens the usual screen already narrowed down. Counting, searching and exporting still come from the database, the way they always did — the model does not invent a value.
Tokens, passwords and API keys are swapped for placeholders before any text is sent to the model, and the same applies to what is stored in the session. If you prefer, the model runs inside your own network.
Features
50 screens for operation, configuration, auditing and reporting, all subject to the user access profile.
Screens
A sample: these are some of the screens for the main features, among the dozens the system ships. The interface is available in Portuguese, English and Spanish, in light and dark themes.
Security
Production payloads carry sensitive data: production orders, costs, customer identification. Controlling that data is part of the product.
AES-256-GCM before persisting, without changing the content delivered to the destination. One key per rule, conditional on text and flow direction.
Viewing an encrypted payload requires being on the key authorisation list, re-authenticating with your own password (and 2FA, if enabled) and writing a justification.
Every decryption attempt — allowed or denied — records the user, result, technical reason, justification, affected entity and source IP.
TOTP through an authenticator app, activated per user with a configurable global requirement.
Corporate login as an alternative to local users, without duplicating identity management.
Each screen is a tool released in the role — it governs the menu and the API authorisation, not just the interface.
Outbound credentials and API keys are encrypted at rest and never re-displayed by the API once saved.
All external traffic goes through nginx with TLS; the SAP connectors stay on the internal network only, with no published port, protected by an internal token.
Content-Security-Policy on both domains: scripts, styles and fonts only count when they come from the installation itself. Even the code editor in the screens is served by it, not by a third-party CDN.
For SAP MII | PCO users
With the SAP MII/PCO lifecycle coming to an end, companies running WEB applications built on SAP MII/PCO will have to consider not only replacing the platform, but also how to preserve the existing integrations between the shop floor and SAP.
Full SAP support. The best moment to assess and plan without pressure.
31/12/2027: the last date with mainstream maintenance included in the contract.
Support only through Extended Maintenance, contracted separately.
A migration programme takes one to three years. Starting here is tight.
31/12/2030: no fixes, no security patches, no standard support.
Strategic planning
SAP DM (Digital Manufacturing) — an MES running on the SAP BTP cloud, with a monthly cost and consulting for rollout and customisation.
It takes a configuration stage to integrate it with S/4HANA, plus a larger team of consultants, with professionals from different areas, to carry out the rollout.
The SAP strategy of dropping SAP MII | PCO and pushing industries to SAP DM is not for everyone: many companies running SAP MII never developed an MES. The sales teams forgot that SAP MII is a framework that integrates factory applications and the SAP world as well.
CMS was built for companies that do not want to move their applications to SAP Digital Manufacturing (SAP DM), but still need to modernise their architecture and replace the Web applications built on SAP MII with modern technologies.
With CMS, the company keeps its integration architecture with SAP and the whole shop floor and, at the same time, extends connectivity to non-SAP technologies, protocols and systems such as MES, SCADA, DCS, historians, laboratory and maintenance systems, and other industrial applications.
Our team runs a full assessment of the SAP MII / PCO environment, identifying:
From that diagnosis we produce a structured migration plan, which can follow different strategies:
Focus Operational continuity, speed and lower CAPEX.
We keep the legacy WEB applications and front-ends, replacing only the SAP MII / PCO integration layer with the new architecture. Ideal to cut risk quickly without disturbing the operators routine on the shop floor.
This path is for companies that know the front-end is not a business risk right now — but losing support and falling behind technologically with SAP MII is.
Focus Less technical debt, better performance and scalability.
Beyond migrating the integration layer, we refactor the legacy SAP MII front-ends into a modern, decoupled and responsive WEB architecture. Suited to companies seeking technological independence and continuous evolution of their interfaces.
This path is for companies that would rather renew the whole layer at once and keep security and technology updates under their own control, free from a vendor calendar.
CMS was born inside XMII Consulting, a consultancy specialised in SAP MII / PCO and industrial integration — more than 18 years of projects connecting the shop floor to the SAP environment, in plants across different industries. xmiiconsulting.com
Clients
Highlight
CMS is not only an integration alternative to SAP MII and SAP PCO. It is a platform for building a new industrial integration layer, ready to connect the shop floor to the corporate world in a controlled way, monitored with alerts and highly scalable.
SAP applications, machines, MES, ERPs, WEB applications and industrial systems can keep talking to each other — through a single integration platform.
How pricing works
The question that stalls any integration decision is whether the cost will grow along with the estate. Here it does not: the number of plants changes the price, and nothing else.
One key per installation. Each plant licences its own, and what runs inside it is not metered.
Five integrations or two hundred, the licence is the same. There is no cap on applications or interfaces.
SAP RFC/BAPI and IDoc, OPC UA, Modbus, MQTT, databases, REST and SOAP all come in the same package.
The volume the plant produces does not change the price. Nothing is billed per event.
The 108 ready scenarios for PP, QM and PM are part of the product, not a separate module.
It runs on the plant own server. There is no cloud subscription, and no data has to leave the factory.
The AI Agent — which investigates the alert on its own, points to the cause with evidence and says what to do — is licensed separately. Everything else is included. We would rather say so here than at renewal.
The figure comes after an assessment of the environment: the size of the estate changes the implementation effort, not the licensing rule. Talk about your scenario
To prove it works in practice, we run an end-to-end demo: we connect CMS to a test SAP system, a simulated OPC UA server, the database and the API, showing the whole integration cycle, from intake to final delivery.
