Tento článek spadá pod pilíř Produktové feedy a je určen feed manažerům a technickým operátorům, kteří zpracovávají produktová data z více XML zdrojů do jednoho výstupního feedu. Vychází ze zkušeností s feedovými řetězci, kde se slučují data od tří až osmi dodavatelů do feedů pro srovnávače a marketplace. V následujících sekcích projdeme příjem více XML zdrojů, řešení schématických rozdílů, validaci polí na vstupu i výstupu, typické konflikty a jejich řešení, izolaci chyb a rizika pro navazující systémy. XML je standardním formátem pro výměnu produktových dat v českém e-commerce a jeho správné zpracování je základem spolehlivého feedového řetězce. Pro hlubší pochopení standardu samotného doporučujeme dokumentaci XML standardu na W3C.

Spojování dat z více XML feedů je operace, kterou řeší většina e-shopů pracujících s externími dodavateli. Jeden dodavatel zasílá katalog elektroniky, druhý doplňky, třetí oblečení. Každý feed má jinou strukturu, jiné pojmenování elementů a jinou úroveň kvality. Cílem je sloučit je do jednoho konzistentního výstupního feedu, který splňuje požadavky cílové platformy.

Příjem více XML zdrojů

Prvním krokem je spolehlivý příjem dat z více zdrojů. Každý zdroj má svou URL adresu (nebo FTP lokaci), svou periodicitu aktualizace a své technické vlastnosti (kódování, komprese, autentizace).

Nastavení příjmu pro každý zdroj:

URL a přístup. Zaznamenejte URL feedu, způsob přístupu (HTTP GET, FTP, SFTP, API) a případné přístupové údaje. U HTTP zdrojů ověřte, zda server podporuje podmíněné stažení (If-Modified-Since hlavička), což šetří přenosovou kapacitu.

Periodicita. Každý dodavatel aktualizuje feed jinak často. Jeden denně v 6:00, druhý každou hodinu, třetí nepravidelně. Nastavte stahování tak, aby se vždy spouštělo krátce po očekávané aktualizaci zdroje. Pokud feed nebyl aktualizován (nezměnil se hash souboru), přeskočte zpracování.

Validace na vstupu. Než začnete feed zpracovávat, ověřte: je soubor validní XML (parsuje se bez chyby)? Odpovídá kódování deklaraci v hlavičce? Obsahuje očekávaný počet produktů (plus minus 10 procent oproti předchozímu stažení)? Pokud jakákoliv kontrola selže, feed nezpracovávejte a odešlete upozornění.

Schéma příjmu a validace více XML zdrojů
Příjem XML feedů: stažení, vstupní validace, zpracování nebo odmítnutí

Důležité pravidlo: nikdy neslučujte nevalidovaná data. Jeden poškozený feed může kontaminovat celý výstup. Zpracovávejte každý zdroj izolovaně a teprve ověřená data přesouvejte do slučovacího kroku.

Řešení schématických rozdílů

Každý XML feed má své schéma (strukturu elementů a atributů). Dodavatel A používá element <nazev>, dodavatel B <product_name>, dodavatel C <title>. Všechny obsahují totéž (název produktu), ale v jiném formátu.

Řešení schématických rozdílů spočívá v definici kanonického schématu, tedy interní struktury, na kterou se všechny vstupní feedy transformují. Kanonické schéma by mělo odpovídat požadavkům cílové platformy (Heureka, Zboží.cz, Google Merchant Center) nebo vaší interní databáze.

Pro každý vstupní feed definujte transformační pravidla:

Mapování elementů. <nazev> z feedu A se mapuje na <PRODUCTNAME> v kanonickém schématu. <product_name> z feedu B se mapuje na totéž pole.

Transformace hodnot. Cena v feedu A je bez DPH, kanonické schéma vyžaduje s DPH. Pravidlo: vynásobit 1,21. Hmotnost v feedu B je v kilogramech, kanonické schéma v gramech. Pravidlo: vynásobit 1 000.

Defaultní hodnoty. Feed C neobsahuje element pro dostupnost. Kanonické schéma ho vyžaduje. Pravidlo: pokud element chybí, nastavit "in stock" (za předpokladu, že dodavatel C posílá jen dostupné produkty).

Filtrování. Některé produkty ze vstupního feedu nechcete ve výstupu (například zboží, které neprodáváte, nebo produkty s nekompletními daty). Definujte filtrační pravidla pro každý zdroj.

◆ Správa transformačních pravidel
Transformační pravidla verzujte v textovém formátu (YAML, JSON nebo prostý text s jasnou strukturou). Každé pravidlo má: identifikátor, zdrojový element, cílový element, typ transformace (mapování, výpočet, default, filtr), a datum poslední změny. Při změně pravidla vytvořte novou verzi a starou archivujte. Testujte změny na vzorku dat (prvních 100 produktů ze zdroje) před nasazením na plný feed. Tím předejdete situaci, kdy změna jednoho pravidla rozbije zpracování tisíců produktů.

Validace polí

Validace polí zajišťuje, že data v jednotlivých elementech odpovídají očekávání. Nestačí, že XML je formálně validní (parsuje se). Data uvnitř musí být smysluplná.

Typy validací:

Povinnost. Jsou vyplněna všechna povinná pole? Název, cena, URL, obrázek, dostupnost. Produkt bez povinného pole se do výstupu nedostane.

Datový typ. Je cena číslo? Je URL platná adresa? Je EAN 13ciferný kód? Textová hodnota v poli, kde se čeká číslo, projde XML validací, ale způsobí chybu v navazujícím systému.

Rozsah. Je cena kladné číslo? Je hmotnost v rozumném rozsahu (ne 0 gramů, ne 999 999 kilogramů)? Jsou rozměry kladné a menší než fyzicky smysluplné maximum?

Formát. Odpovídá URL schématu https://? Má obrázek příponu .jpg, .png nebo .webp? Je EAN ve správném formátu (bez mezer, pomlček, předpon)?

Konzistence. Má produkt kategorii, která existuje v cílovém kategorizačním stromu? Je měrná jednotka konzistentní v rámci celého feedu (ne jednou "kg" a jednou "kilogram")?

Validaci provádějte ve dvou fázích: na vstupu (po transformaci z dodavatelského feedu do kanonického schématu) a na výstupu (před exportem finálního feedu). Produkty, které neprojdou vstupní validací, se nezařadí do slučování. Produkty, které neprojdou výstupní validací, se neexportují.

Konflikty a jejich řešení

Při slučování dat z více zdrojů nevyhnutelně vznikají konflikty. Dva zdroje dodávají stejný produkt (identifikovaný podle EAN) s odlišnými hodnotami v některých polích.

Typické konflikty:

Cenový konflikt. Dodavatel A uvádí cenu 599 Kč, dodavatel B 549 Kč. Řešení: definujte cenovou politiku. Buď vždy nižší cena (maximalizace konkurenceschopnosti), nebo cena od preferovaného dodavatele (konzistence), nebo cena z interního systému (centrální řízení).

Konflikt dostupnosti. Dodavatel A říká "skladem", dodavatel B říká "na objednávku". Řešení: pokud alespoň jeden říká "skladem" a je schopen expedovat, produkt je dostupný. Ale ověřte, který dodavatel realizuje expedici.

Konflikt parametrů. Dodavatel A uvádí hmotnost 500 g, dodavatel B 520 g. Řešení: definujte autoritativní zdroj pro technické parametry (typicky výrobce nebo dodavatel s nejúplnějšími daty).

Konflikt kategorií. Dodavatel A řadí produkt do "Elektronika > Audio", dodavatel B do "Příslušenství > Sluchátka". Řešení: použijte vlastní mapování na cílovou taxonomii, ne kategorii dodavatele.

Schéma řešení konfliktů při slučování produktových dat
Řešení konfliktů: cenová politika, prioritní zdroj, autoritativní parametry

Pro každý typ konfliktu definujte pravidlo předem, ne ad hoc. Pravidla by měla být dokumentována a přístupná celému týmu.

Izolace chyb

Izolace chyb znamená, že problém v jednom vstupním feedu nezpůsobí výpadek celého výstupního feedu. Bez izolace může jeden poškozený XML soubor od jednoho dodavatele vyřadit z nabídky produkty od všech dodavatelů.

Principy izolace:

Nezávislé zpracování. Každý vstupní feed se stahuje, validuje a transformuje nezávisle. Pokud zpracování jednoho feedu selže, ostatní pokračují.

Fallback na předchozí verzi. Pokud aktuální verze feedu od dodavatele A neprojde validací, použijte poslední platnou verzi (pokud není starší než definovaný limit, typicky 24 až 48 hodin). Pokud je i poslední platná verze příliš stará, produkty od dodavatele A vyřaďte z výstupu a odešlete upozornění.

Kvantitativní kontrola. Po sloučení porovnejte počet produktů ve výstupu s očekávaným počtem. Pokud je výstup výrazně menší (pokles o více než 15 procent), zastavte export a prošetřete příčinu.

Samostatný log. Každý krok zpracování (stažení, validace, transformace, sloučení, export) zapisujte do logu. Při problému musíte být schopni rychle zjistit, kde přesně řetězec selhal.

Rizika pro navazující systémy

Výstupní feed se propisuje do dalších systémů: srovnávačů, marketplace, PPC kampaní, interní databáze. Chyba ve feedu se tak multiplikuje.

Nejzávažnější rizika:

Ztráta produktů. Produkt, který byl ve feedu včera, dnes chybí. Srovnávač ho vyřadí z nabídky. Pokud jde o produkt s vysokým obratem, ztráta je okamžitá a měřitelná.

Chybná cena. Cena se propsala s chybou (chybějící nula, špatné zaokrouhlení). Na srovnávači se zobrazí nereálně nízká cena. Zákazníci klikají, ale objednávku za tuto cenu nemůžete realizovat.

Duplicitní produkty. Slučovací pravidlo selhalo a stejný produkt je ve výstupu dvakrát. Na srovnávači to může vést k penalizaci nebo ke zmatení zákazníků.

Nekonzistentní data. Kategorie v jednom záznamu neodpovídá popisu v jiném. Obrázek zobrazuje jiný produkt, než uvádí název. Tyto nekonzistence snižují důvěru zákazníků a mohou vést k hodnocení "nespolehlivý obchod" na srovnávači.

Prevence: automatizované testy před každým exportem. Test na počet produktů, test na přítomnost povinných polí, test na cenový rozsah (žádná cena nesmí být nulová nebo záporná), test na duplicity (EAN nesmí být ve feedu dvakrát). Pokud jakýkoliv test selže, feed se neexportuje a čeká na opravu.

Pro navazující krok, jak nastavit správně dopravní sazby ve feedech pro srovnávače, doporučujeme článek Ceny dopravy na Heurece a Zboží.cz. Pro celkový kontext správy feedů pak Import dodavatelských feedů a pilíř Produktové feedy.