Middleware: proč jej e-shop se sítí integrací potřebuje

Na začátku je to jednoduché. E-shop posílá objednávky do účetnictví, jednou za den stáhne sklad od dodavatele a odešle feed na srovnávač. Pak přibude Kaufland, druhý sklad, CRM, dopravce s vlastním API a platební brána, která vrací stav platby. Najednou má e-shop osm napojení a každé funguje trochu jinak.

Typický symptom: objednávka zmizela „někde mezi“ e-shopem a ERP a nikdo neví, kde hledat. Každý dodavatel integrace ukazuje na toho druhého. Přesně v tuhle chvíli dává smysl middleware, tedy jedna mezivrstva, přes kterou tečou všechna data. V článku vysvětlujeme, co řeší, jaké jsou varianty a na co si dát pozor.

Point-to-point vs. hub: proč přímá napojení přestanou stačit

Přímé napojení (point-to-point) znamená, že každý systém mluví s každým napřímo. E-shop volá API ERP, ERP volá API skladu, sklad posílá data marketplace. U dvou nebo tří systémů je to nejlevnější a nejrychlejší cesta.

Problém je v matematice. Mezi n systémy, které spolu potřebují mluvit všechny navzájem, je až n × (n − 1) / 2 spojení. U 4 systémů je to 6 spojení, u 8 systémů už 28. Každé má vlastní formát, vlastní autentizaci, vlastní způsob, jak ohlásit chybu. A když jeden systém změní API, rozbije se několik napojení najednou.

Hub (hvězdicová architektura) otočí logiku. Každý systém se napojí jen na middleware. Middleware ví, že nová objednávka z e-shopu má jít do ERP, do CRM a do skladu, a každému ji pošle v jeho formátu. U 8 systémů tak máte 8 napojení místo 28.

Middleware není jen „přeposílač“. Typicky dělá tři věci: převádí formáty (XML dodavatele na JSON e-shopu, kódy stavů objednávek ERP na stavy e-shopu), rozhoduje o směrování (kam data poslat) a hlídá doručení (opakuje, loguje, upozorní).

iPaaS, nebo vlastní middleware

Middleware si můžete pronajmout jako službu, nebo si ho nechat postavit.

iPaaS (Integration Platform as a Service) jsou cloudové platformy s hotovými konektory a vizuálním editorem. V českém e-commerce se nejčastěji potkáváme s nástroji n8n, Make a Zapier. Pro orientaci ceny dvou z nich (ceník k září 2026, aktuální ceník ověřte u poskytovatele):

• n8n Cloud: tarif Starter za 20 € měsíčně při ročním placení s 2 500 spuštěními workflow za měsíc, Pro za 50 € měsíčně s 10 000 spuštěními. Platí se za spuštění workflow bez ohledu na počet kroků. n8n má i Community Edition pro vlastní server pod licencí Sustainable Use License. Tu smíte zdarma používat pro interní potřeby firmy, bez limitu spuštění, a platíte jen server a správu.
• Make: bezplatný tarif s 1 000 kredity měsíčně, placený tarif Core od 9 $ měsíčně při ročním placení za 10 000 kreditů. Kredit se spotřebovává za každý krok (modul), který zpracuje data, takže složitější scénář stojí víc.

Na tom je vidět důležitý rozdíl. Scénář s deseti kroky, který běží pro každou objednávku, spotřebuje v Make zhruba desetkrát víc kreditů než jednokrokový. V n8n je to pořád jedno spuštění. Naopak polling, tedy dotaz „je něco nového?“ každých 5 minut, znamená 8 640 spuštění měsíčně, i když se nic nestane. Proto je lepší spouštět workflow webhooky tam, kde to systém umí.

Vlastní middleware je aplikace napsaná na míru, obvykle jako služba v cloudu s vlastní databází a frontou. Dává smysl, když:

• zpracováváte vysoké objemy (desítky tisíc zpráv denně) a platba za spuštění nebo kredit se prodražuje,
• potřebujete složitou logiku, kterou vizuální editor zvládne jen s obtížemi (rezervace skladu napříč kanály, rozpad objednávek na více skladů),
• máte požadavky na umístění dat nebo audit, které cloudový nástroj nesplní,
• integrace je pro byznys kritická a chcete ji mít plně pod kontrolou včetně testů a verzování.

Často volíme kombinaci. Kritické toky (objednávky, sklad) běží ve vlastní službě s frontou a okrajové automatizace (notifikace do Slacku, zápis do tabulky, štítek v CRM) v n8n nebo Make.

Fronty: pojistka proti výpadkům

Každý systém občas nejede. ERP má noční údržbu, dopravce vrací chybu 500, marketplace vás na chvíli omezí kvůli počtu požadavků. Když middleware posílá data synchronně („pošli a čekej“), při výpadku se data ztratí nebo zasekne celý proces.

Řešením je fronta zpráv. Middleware nejdřív zprávu uloží („nová objednávka 12345“) a teprve potom ji zpracovává. Když cílový systém neodpovídá, zpráva zůstane ve frontě a zkusí se znovu později. Nic se neztratí.

Na co u front myslet:

• Opakování s rostoucím rozestupem. Ne desetkrát za sekundu, ale třeba po 1, 5 a 30 minutách. Jinak přetížíte systém, který se zrovna vzpamatovává.
• Fronta nedoručitelných zpráv. Zprávy, které selžou opakovaně (chybný formát, neexistující produkt), se přesunou stranou a čekají na člověka. Neblokují ostatní.
• Idempotence. Stejná zpráva může dorazit dvakrát. Zpracování musí být navržené tak, aby druhé doručení nic nezdvojilo, třeba nevytvořilo druhou fakturu.
• Pořadí. Změna stavu „odesláno“ nesmí předběhnout „zaplaceno“. U některých toků je pořadí zpráv kritické.

Víc o tom rozebíráme v článku Fronty a asynchronní zpracování v ecommerce.

Monitoring: middleware, o kterém nevíte, je časovaná bomba

Nejhorší integrace je ta, která tiše přestane fungovat. Sklad se tři dny nesynchronizuje, e-shop prodává zboží, které není, a přijdete na to až podle stížností zákazníků.

Minimální monitoring middleware:

1. Log každé zprávy s identifikátorem (číslo objednávky, SKU), časem a výsledkem. Musíte umět dohledat, co se stalo s objednávkou 12345.
2. Alert na chyby do e-mailu nebo chatu, ideálně se souhrnem, ne po jedné zprávě.
3. Alert na ticho. Když za poslední hodinu nepřišla žádná objednávka, i když obvykle chodí desítky, něco je špatně. Tohle chyby nezachytí, protože žádná chyba nevznikla.
4. Délka fronty. Když fronta roste a neubývá, zpracování nestíhá nebo stojí.
5. Pravidelná kontrola konzistence. Třeba jednou denně porovnat počet objednávek v e-shopu a v ERP.

Podrobný postup máme v článku Monitoring integrací.

Kdy middleware nasadit: rychlý test

Middleware pravděpodobně potřebujete, pokud platí aspoň dvě z těchto vět:

• Máte čtyři a více systémů, které si vyměňují stejná data (objednávky, sklad, ceny, zákazníky).
• Prodáváte ve více kanálech a sdílíte mezi nimi jeden sklad.
• Chyby v napojení řešíte ručně víc než jednou týdně.
• Nevíte s jistotou, kde hledat, když objednávka nedorazí do ERP.
• Plánujete změnu platformy nebo ERP a nechcete přepisovat všechna napojení.
• Každý nový kanál nebo dopravce znamená nový projekt od nuly.

Poslední bod je častý důvod, proč firmy middleware zavádí při migraci. Když je logika integrací v mezivrstvě, výměna e-shopu znamená přepojit jeden konektor, ne deset napojení.

Jak na to prakticky

1. Zmapujte toky. Nakreslete všechny systémy a šipky mezi nimi: jaká data, jakým směrem, jak často a který systém je pro daná data zdrojem pravdy.
2. Seřaďte podle rizika. Objednávky a sklad jsou kritické, notifikace do chatu ne.
3. Vyberte variantu. Pro menší objemy a jednodušší logiku iPaaS, pro kritické toky s vyššími objemy vlastní služba s frontou. Často obojí.
4. Postavte monitoring hned od začátku, ne až po prvním incidentu.
5. Přepojujte postupně. Jeden tok za druhým, s během obou variant souběžně a kontrolou výsledků.

Návrh a stavbu middleware děláme v rámci služby Integrace a middleware, realtime toky skladu a objednávek pak v rámci Automatizace a realtime synchronizace. Na n8n workflow se u nás specializuje oddělení AI a automatizace. Cenu připravíme po konzultaci podle počtu systémů a objemu dat. Pokud řešíte hlavně napojení účetnictví, začněte článkem Propojení ERP, e-shopu a skladu.