System integrations: ERP, PIM, e-commerce and middleware

Integration connects the systems you already run, it is not another system

A distributor or a manufacturer rarely runs on a single system. The ERP keeps the books, the stock levels and the price lists. The PIM holds descriptions, attributes and photography. The shop and the B2B platform take the orders. The WMS knows what is actually on the shelf, and every marketplace has its own expectations about every field. Each of those systems is good at its own job and none of them replaces the others. The trouble starts where they have to talk to one another.

That conversation is our work. We establish which system is the source of truth for which field, which way the data flows, how often, and what happens on the day the other side does not answer. Catalogue, stock and prices usually travel from the ERP to the PIM and on to the shop. Orders, customer records, payments and fulfilment statuses come back the same way. That is what system integration means here: one circuit of data instead of a dozen exports to a spreadsheet and a dozen pastes back.

It also costs less than replacing several systems with one. We will not talk you out of an ERP that works and that your team knows. We connect it to the rest, and the rest to each other.

When the ERP has no API: integrating through a SQL database

Some ERP systems, older ones and ones heavily customised on site, expose no API at all. That does not end the conversation about integration. We connect directly to the SQL database instead and exchange data through staging tables: the ERP writes into them whatever is meant to leave the system, and we write into them whatever is meant to come back. The staging table is the boundary of responsibility, so the integration never writes into the system's production structures and never puts its stability, or its vendor warranty, at risk.

To build that, you first have to know where the data really sits. We reverse-engineer the schema: we read the tables, the keys and the relations, verify against real records which field is which, and write it up as the model the mapping is then built on. A side effect is documentation of the database structure, and it stays with you. Often it turns out to be the only current description of that system anyone in the company has.

The same mechanism covers file-based exchange: CSV, XML or JSON on a network drive or an FTP server. The rules for what moves and when live in the same panel, whether the other side is an API, a database or a directory of files.

How we run an integration project

We start with business and IT analysis: which systems are running, where each piece of data lives, who owns which field, and where the company is doing the same work twice or holding two versions of the same fact. Only then do we design the architecture: point to point or an integration bus, synchronous or event-driven, in which time windows and under what contract between the systems. Those decisions are made before the first line of code, because changing them later is what costs.

Delivery runs in sprints, with logging and monitoring from day one, so a failure can be reconstructed rather than guessed at. After go-live we stay: we watch the flows, react to outages on the partner systems' side, and connect the next system when it arrives. You may own the best integration software there is, but without someone who knows your processes and minds them daily, it will not run itself.