1 minute to read

Shopware integrations: How to make complex system landscapes work

Shopware integrations: How to make complex system landscapes work

An interview with Yann Karl, CTO Germany at Strix

Connecting an ecommerce platform to ERP, procurement, personalization, and other business-critical systems can quickly become complex – especially in B2B. So, what separates a good integration from one that creates more problems than it solves?

We spoke with Yann Karl, CTO Germany at Strix, about the principles behind successful Shopware integrations, from ERP connectivity and EDI to OCI PunchOut and intelligent search.


Yann, merchants often talk about “integrating” Shopware with their existing systems. What does a good integration actually look like?

Yann Karl: A good integration starts with the business process, not the connector.

Before deciding how two systems should communicate, you need to understand which system owns which data, where that data needs to go, how quickly it needs to get there, and what should happen when something goes wrong.

That becomes especially important as the system landscape grows. An ERP may manage inventory, prices, or financial processes, while Shopware handles the commerce experience. Then you might have a PIM, search and personalization technology, procurement systems, marketplaces, or other services in the mix.

The objective shouldn't simply be to connect everything to everything. It should be to give every system a clear role and create reliable data flows between them.

ERP is often at the heart of that landscape. What have you learned from integrations such as Shopware and Navision?

Yann: The biggest lesson is that the technology itself often isn't the hardest part. The complexity comes from the processes and data structures that have grown around an ERP over many years.

Navision is a good example. In many companies, Microsoft Dynamics NAV has been running for years before Shopware enters the landscape. During that time, custom modules, pricing structures, workflows, and exceptions have accumulated. That means there usually isn't one standard Navision integration you can simply switch on.

You might connect the systems directly through APIs, introduce middleware, or use an extension as a starting point. You also need to decide which information should move in real time and which can be synchronized periodically.

Most importantly, look at data quality and business logic before implementation. An integration project is a useful opportunity to ask whether every legacy process really needs to be recreated in the new environment.

Deep dive: A Tale of Two Systems: Shopware x Navision

Does the same principle apply to a more modular ERP such as Odoo?

Yann: Yes, although the starting point can be different.

Odoo's modular approach can be attractive to growing businesses that want to introduce ERP capabilities gradually. But you still need to make an architectural decision about how Shopware and Odoo communicate.

A direct API connection can work for relatively straightforward requirements. Standard integrations can accelerate common use cases. Once you have more individual B2B processes, multiple sales channels, or additional systems, middleware can become useful because it separates the systems and gives you a central place to control data flows.

The broader point is that you shouldn't choose an integration method just because it looks simplest on day one. Think about what happens when your processes, channels, and system landscape change.

Deep dive: Shopware x Odoo: Integration Instead of Isolated Systems

B2B merchants also need to exchange data with customers and suppliers. Where does EDI fit in?

Yann: EDI – Electronic Data Interchange – addresses a different integration challenge: standardized, automated communication between businesses.

Instead of somebody receiving a purchase order by email and manually entering it into another system, EDI enables systems to exchange structured business documents directly. That can include purchase orders, invoices, order confirmations, shipping notices, and inventory information.

In a typical Shopware architecture, EDI does not necessarily sit inside the commerce platform itself. Shopware may pass orders to the ERP through an API or middleware, while the EDI layer connects the company’s internal systems with external customers, suppliers, or logistics providers.

For organizations processing high order volumes or working in wholesale environments, the business impact can be significant. You reduce repetitive manual work, lower the risk of data-entry errors, and process transactions faster.

The interesting thing about EDI is that it's hardly new technology. But the problem it solves is still extremely relevant: getting business systems to exchange information reliably without requiring a person to bridge the gap every time.

Deep dive: Machine-to-Machine Communication: EDI Interface for E-Commerce with Shopware

And what about Open Catalog Interface (OCI) PunchOut? Why is that particularly relevant in B2B commerce?

Yann: OCI PunchOut is a good example of an integration that can make a complex process feel simple to the buyer.

A purchaser starts in their company's procurement or ERP system and enters the supplier's Shopware store. They browse the supplier’s current catalog and build a cart there. Instead of completing the order in Shopware, the cart is transferred back to the procurement system as the basis for an internal purchase requisition. Approval, budget control, and creation of the actual purchase order take place there. The subsequent transmission of the order to the supplier is a separate integration step.

That means the buying organization can keep its existing approval processes, budgets, and procurement rules while the purchaser still benefits from the supplier's current product information and commerce experience.

For merchants selling to larger organizations, this can be strategically important. You're not asking the customer to abandon their procurement process in order to buy from you – you're fitting the commerce experience into that process.

Deep dive: OCI PunchOut x Shopware: A Knockout Solution for Eliminating Media Disruptions in B2B

Integrations aren't only about back-office efficiency. What does the Shopware and Nosto use case show?

Yann: It shows that integration architecture can directly affect the customer experience as well.

Search is a good example. When a store has a large catalog, simply matching a query against keywords may not be enough. Nosto can interpret the intent behind a search query using the available catalog data. When behavioral data and the appropriate tracking setup are also available, search results, recommendations, and other parts of the experience can be further personalized.

But introducing another technology isn't automatically valuable. You need enough product information for semantic search, and behavioral data plus the appropriate tracking setup for personalization. Teams still need to monitor and optimize the experience.

That's a useful principle beyond search: integrating a tool is the beginning, not the end. The real value comes from how well it supports the customer journey and how effectively the organization operates it afterward.

Deep dive: Shopware x Nosto: Intelligent Search and Discovery in E-Commerce

With all these possibilities, how can merchants avoid creating an integration maze?

Yann: Start with responsibilities and processes.

Ask which system should be the source of truth for each type of information. Map the data that actually needs to move between systems. Decide where real-time synchronization creates business value and where a scheduled update is enough.

And don't underestimate exceptions. The standard order process is rarely what makes an integration difficult. It's often the special pricing agreement, unusual fulfillment process, customer-specific catalog, or legacy rule that has existed for fifteen years.

If you understand those requirements before you start building, you can make much better architectural decisions.

The goal isn't the highest possible number of integrations. It's a system landscape that stays understandable and adaptable as the business changes.


What's next for Shopware integrations at Strix?

Strix’s integration series also covers Shopware x SAP via IDoc and Shopware x Microsoft Dynamics 365 Business Central. Together, these examples illustrate an important point for merchants with complex technology landscapes: integrations shouldn’t be treated as isolated technical projects. They are part of the architecture that connects commerce with the rest of the business.

Explore the Strix integration series

Want to go deeper into a particular setup? Explore Strix's detailed articles on:


You might also be interested in:

Copied to clipboard