WMS integration at Constellation Cold Logistics: from database writes to a single data model

One file share, written straight into the database

The starting point was a single shared SFTP file share on a local server, tied to the AS/400. All customers delivered files to the same place, and the files were fetched and written straight into the database tables, message by message. There was no shared layer and no shared structure. Each customer’s quirks lived in the code that wrote their files into the tables, and every new customer meant building the same thing all over again. Some customers were not on EDI at all.

The hidden pain

The data model was not the only thing without documentation. The plumbing had none either.

• Every new customer connection raised the same questions: do we fetch the file, or do they deliver it? SFTP, or an API we have to pull from ourselves? And which format is actually in the file?
• Knowledge was held by individuals, not written down. The original integrations were built by a few very experienced people, and when they move on, the reasons behind the choices go with them.
• Old customer profiles were kept as templates, simply so the next onboarding had something to copy from.
• The AS/400 tables that everything was written into were just as undocumented as the files coming in.

It is like inheriting a house without plans, where half the pipes run inside the walls. Before you can lay new pipes, you have to find out where the old ones actually go.

One internal model per message type

At the heart of the solution is a canonical data model, or CDM, for each message type: orders, shipping notices, receipts, adjustments and more. It is a single standardised internal format that Constellation has full control over. The model was derived from large volumes of real production data from across the customer base, analysed with the help of AI, so it holds up across customers rather than being shaped around one customer’s quirks. It sets out the minimum fields that must be present for a customer to be connected at all.

Think of it as a shared working language in diplomacy. Instead of every country needing an interpreter for every other country, each country has one interpreter: from its own language into the shared one and back. When a new country joins, you add one more interpreter. Everyone else stays as they are.

What an order looks like in the model

Having two levels in the lines, the pallet and the cartons beneath it, means that traceability can sit at whatever level each customer is tracked at. Onboarding is this exercise, done once: mapping the customer’s fields to the model, in both directions. Everything downstream already exists.

How customers send it, and what the model requires

Every message can be traced, and every quirk is contained

Every message in the model carries its own metadata: source system, model version, status and timestamp. If something goes wrong (bad data from a customer, a missing field, a failed delivery), it can be traced to the exact message, customer and point in the chain. Being able to prove and trace what happened to the data, and not just move it, was one of the main reasons Constellation chose Lobster as the middle layer.

• Customer-specific logic lives in the customer’s own profile, not scattered through the core process. One customer’s exception cannot bring down another customer’s flow, and the core stays readable.
• A new customer is a mapping task: their format to and from the model, plus the transport. The rest of the flow already exists, with the mandatory fields defined.
• No lock-in to one warehouse system. Today it is Infor WMS. If it is replaced, only the mapping from the model to the warehouse system changes, and an additional warehouse system from an acquisition is an addition, not a migration.

The target: onboarding in around two months

Previously, onboarding a single customer meant months of back and forth, typically six to eight months. With the model in place, the target for a new connection is around two months, and the first customer is currently being connected under the new model. The plan is to connect more Danish customers first and then move on to the group’s other countries. The first warehouse is scheduled to go live on Infor WMS in November 2026, and after months of testing, both the standard processes and the exceptions around them are holding up.

Off the local server and out as APIs

Everything above is built and in operation. What follows is the direction of travel, not a delivery.

• Customers will be moved off the AS/400-bound file share and onto Lobster: at a minimum SFTP hosted in Lobster, and direct HTTP for those that can use an API. The point is not to abolish SFTP, since Lobster speaks almost any protocol. The point is to get off the local server.
• The model and the reports will be exposed as external APIs with Lobster’s own OAuth2 service and access control in API Manager, so customers can fetch their own data whenever they want.
• Onboarding via Trading Partner Manager, where partner setup, transport and access are brought together in one place, so an API-ready customer becomes a setup step rather than a development project.
• Not every customer needs, or has the capacity for, full EDI integration. The vision is a WebEDI portal for the smaller ones, where order and stock data can be viewed in the browser without any EDI setup.

From the start, the solution was designed for several warehouses and several countries, with each customer kept separate as part of the structure, not as an add-on. Every acquisition in the group comes with its own systems and its own version of AS/400, exactly as Denmark did. The pattern established here is not a Danish solution but a reusable blueprint for the next acquisition.