System integration that connects ERP, PIM and the web

You can have an order that shows on the website, a stock level in the business system and a product description in PIM, and still lack a working whole. When someone changes a pricing rule or upgrades a system, it becomes clear who is actually responsible for keeping the data correct.

System integration is therefore an ongoing commitment about how data should move, what the data means and who acts when something changes. The technology carries the information. The business needs to own the rules and the work after go-live.

Four patterns for system integration and when they fit

Think of an integration as a postal route between systems. A single order is a letter, but the route itself has to work even when the recipient is busy, the address changes or the delivery fails.

Statistics Sweden describes business systems as systems that share information between internal functions, such as orders, stock, purchasing and project management. That makes the business system a shared information base that needs to exchange data with other systems and channels. Statistics Sweden's definition of business systems is a useful starting point when you decide which data should leave the system, and when.

Point-to-point is easy to understand when two systems need to exchange a limited amount of data. The connection gets harder once more systems need the same information. Every new link can create another place where fields, rules and error handling have to be kept in step. The biggest risk is that each new connection ties more systems to each other.

Batch transfer suits data that does not need to be current to the second. A nightly product file can work for a range that rarely changes, but a price that changes after the transfer can show incorrectly until the next run. Synchronous API calls give a quick answer when the customer is waiting for something like permissions or a price, but the customer's flow then depends on the receiving system responding.

With events and a queue, the sender can hand over a message without every recipient having to be ready at the same time. That fits when several systems need to react to an order or a stock change. You also need to be able to spot growing queues and handle an event that is delivered more than once. For a comparison with a more modular setup, read about composable commerce. The biggest risk here is duplicate deliveries or queues that grow unnoticed.

Choose a pattern based on who is waiting for the answer in each flow and what happens if the answer never comes.

Who owns the data between the business system, PIM and the web

Every data object needs a defined master. An item number in three systems does not automatically create three equal sources. It creates three possible answers when someone asks which value applies.

A common split is that the business system owns item numbers, core data, pricing rules, stock and customer rules. PIM manages the enriched product information, such as copy, attributes, images and documents. The website displays the data and sends orders and customer data back according to agreed rules.

Stock levels are often owned by the warehouse system via the business system and changed by the warehouse process. Customer permissions and customer-specific price lists sit in the business system or CRM and are shown in the customer portal and reseller portal. Order status is owned by the business system and returned to the customer portal and customer service through the integration.

This split is common but needs to be adapted to you. If your warehouse system owns stock levels, your model should say so. Also decide who may change each object and who approves changes to what it means.

A difference in meaning can cause an error that no technical check catches. Say one system counts single units and another counts packs. If an order for a pallet is read as a number of single units, both stock and price can end up wrong, even though the API call succeeds.

The Swedish Agency for Digital Government describes technical interoperability as one part of the whole, and also points to the importance of legal, semantic and organisational interoperability. A working API therefore does not guarantee that the systems interpret item status, unit, price or customer permissions the same way. That is why you need to test the interface, the business meaning and complete processes before go-live, according to the agency's follow-up on digitalisation and interoperability.

Fill in the ownership together with the people responsible for the business system, PIM and the web, and document who decides when ownership changes. For practical guidance on information modelling, there is also the walkthrough of how PIM data is structured.

How an order travels from the website to the business system and back

An order process only works once the whole journey is defined. The following flow shows what needs to happen from the customer's click to an updated order status.

The customer places the order in the webshop. The website needs to save the order so it is not lost if the next step takes time. The website then checks permissions, price and stock against the most recently synced data. If stock is updated less often than prices, the customer may see a stock level that has already changed.

The website sends the order with a stable business ID, a timestamp and a correlation ID. These make it easier to follow the same order through logs and systems. The business system uses the business ID to detect whether the order has already been received. That stops a retry from creating a duplicate order.

The business system returns its order number. The website can then show a confirmation that can be referred to if questions come up. Stock reservation and order status go back to the website. The customer and customer service then get the same up-to-date information.

If the transfer fails, the message waits in a queue and is resent with longer pauses between attempts. If the error persists, it is moved to a dedicated error queue that someone is responsible for reviewing. Duplicates often arise when the business system receives the order but the reply is lost on the way back. The website may then read the wait as a failure, and the customer may try again. A stable order ID and a recipient that recognises repeated messages make the difference.

EDI orders take a different route from a webshop purchase. Statistics Sweden defines e-commerce as covering orders via a website, an app or specially formatted EDI messages, according to Statistics Sweden's figures on ICT use in enterprises. A web order needs to handle presentation and customer login. The EDI flow has to interpret structured formats, identifiers, acknowledgements and error codes.

An API strategy that survives version changes

A REST API gives a clear way to query and update resources such as items, orders and customers. The Swedish Agency for Digital Government's REST API profile and guidance for standardised APIs gives a Swedish reference for consistent design and validation. What matters most is still the rules you document and follow.

Start with authentication. Give each connected system its own service account with the permissions its flow needs. If several systems share one account, it becomes harder to limit access and trace which system made a change.

Then decide the versioning rule. Backward-compatible additions can often fit in the same version, while changes that break existing calls need a clear migration path. The versioning model and the identifier structure become expensive to change once many flows depend on them.

Errors need a shared format with an error code and correlation ID. When an order is created, the recipient must be able to handle an idempotency key or an equivalent stable ID, so a resent call does not create a new order. Large catalogues should be fetched in pages. Requests that fetch stock one item at a time can put unnecessary load on the systems, so gather the data in a suitable single call.

Every message should be traceable from the website to the business system and back. Log latency, errors and queue sizes, and make sure someone gets an alert when messages need manual handling. That makes it possible to tell transport errors apart from errors in mapping or business logic.

Data contracts and responsibility when systems change

The stability of an integration is decided by the data contract: which fields exist, their data types, units, meaning, allowed values and versioning rules. Ownership matters just as much. When the business system or the platform changes, it must be clear who approves the change, who adjusts the mapping and who answers if the flow breaks.

If a field is removed in the business system, the mapping returns an empty value, and if a new field becomes mandatory, the order is rejected. The contract therefore needs to state which fields are mandatory, who approves a removal and which default value and transition period apply.

A changed unit, for example from single units to cartons, can produce wrong stock and prices without any error message, and changed pricing logic can show old prices on the website. The contract needs to state conversion rules, an owner for the pricing rules and approved test cases. For new releases and retired API versions, it needs to state version notices, a test environment, a rollback plan, a retirement date and a migration path.

External data sources change their interfaces too. Statistics Sweden notes that variables in its business register API can be added or removed, and that a coming API will replace the current one. Statistics Sweden's documentation of the business register API underlines the basic rule: plan for change from the moment the connection is built.

A silent drop in quality rarely shows up as a technical error. Track the number of rejected orders, compare samples against the business system and watch whether manual corrections increase. When the price structure changes, a named owner should approve the rules and test cases. The contract should also state how long an older version is supported.

Responsibility needs to be contracted and continue into ongoing management after the project phase. Glanser Care covers version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing at a fixed monthly cost. Whatever the supplier, the model is the same: one owner per data object and one party that answers when the other system changes. A contract without an owner is just documentation.

What a reliable connection requires of you

An order for a pallet passes through a connection that expects single units, and the business system reserves 40 units. Errors like that pass straight through technical checks, so test the connection at three levels, before go-live and every time the systems change.

First, schema and API: field names, data types, mandatory values, error codes and authentication. This is where errors in the transfer itself show up. The next level is business semantics: units, pricing rules, item status and customer permissions. Check both the value that is sent and how the recipient should interpret it. The final level is the whole process. Send an order from the website to the business system, reserve stock, process a return and resend the same message after a simulated timeout. Then you can see whether the rules work together, including that a resend does not create a duplicate order.

The tests place demands on your side. You need a test environment with representative business system data, time set aside for testing before every release and a named owner for each data object. The owner is the person who answers when the other system changes. When the tests are part of every release, an upgrade becomes a check of what is already in place.

Sometimes an advanced connection is too heavy. With low order volume, a catalogue that rarely changes or a one-off import, a controlled file import with a reconciliation report can be enough. That solution still needs someone to review the discrepancies, but it can be more reasonable than running a real-time solution. The walkthrough of the Business Central integration shows how a connection can become part of a larger flow as volume grows.

Three questions to ask the supplier

Who decides that a field may be removed, and how long is the old API version supported? A clear answer names both the responsible role and how the change is communicated.

What happens to an order that ends up in the error queue, who gets the alert and within what time must it be handled? The answer shows whether the supplier has a real routine for errors or only a technical way to set the message aside.

Which test cases do you run against the business system version we use before an upgrade goes live? A written test list shows whether the supplier tests real flows such as orders, stock and returns.

Compare the answers from two suppliers to the same questions and ask for them in writing. A date, a named role and clear test cases show how responsibility is divided. A phrase like "errors are handled as needed" leaves room for the cost to land with you once a change has already disrupted the business.

Choose the pattern by who owns the data

Decide per data object whether syncing should happen in batches or via an API. Data that rarely changes and can wait until the next run, such as product copy, attributes and documents, works well in scheduled batches. Data that drives a real-time decision, such as price and stock at checkout, needs a direct call so the website always asks the current source. The same object can also carry both: the item master can be replicated in batches while pricing is fetched only when the customer actually buys. Choose the pattern based on what it costs the business if the information is an hour old.

Bring the people responsible for the business system, PIM and the web into one working group, identify which data objects lack an owner and document which pattern applies to each flow.

We deliver websites, product websites, PIM and portals with ready-built and tested integrations at a fixed scope and fixed price, and take long-term product ownership after go-live. On the page about integrations with the business system, you can see how we connect business systems, PIM and the web, and who is responsible when the systems change.