U každého objektu určete zdroj pravdy a stabilní identitu, poté u každého pole popište význam, formát, jednotku, povinnost, transformaci a chybový stav. Mapování ověřte na reálných výjimkách, verzujte ho a každou změnu koordinujte s vlastníky obou systémů.
Mapování dat mezi systémy není mechanické spojování sloupců s podobným názvem. Pole zákazník může v CRM znamenat obchodní kontakt, v ERP fakturační subjekt a na webu uživatelský účet. Pokud integrace nerozliší význam, přenese syntakticky platné údaje do nesprávného procesu a chyba se může projevit až při fakturaci nebo podpoře.
Kvalitní mapování popisuje vlastnictví, identitu, povinnost, formát, transformaci a chování při neznámé hodnotě. Dokument zůstává společným kontraktem obchodního a technického týmu. Musí být možné ho testovat a verzovat, protože oba systémy se vyvíjejí. Jednorázová tabulka bez vlastníka rychle přestane odpovídat realitě.
Začněte objekty, událostmi a vlastnictvím
Nakreslete, které objekty se přenášejí a při jaké události. Objednávka, zákazník, produkt a platba mají odlišný životní cyklus. Určete systém, který smí měnit konkrétní údaj, a systém, který pouze přijímá kopii. Obousměrná synchronizace bez pravidel pro konflikty může přepsat novější hodnotu starší.
Rozlišujte vytvoření, aktualizaci, archivaci a smazání. Ne každý stav se má automaticky šířit. Zrušený kontakt v marketingu nemusí znamenat odstranění účetního záznamu. Vlastník procesu musí potvrdit význam události a pravidla uchovávání; technická integrace si je nemá vymýšlet podle dostupných endpointů.
Používejte stabilní identity a párovací tabulku
Uchovávejte interní a externí identifikátory vedle sebe. Název, e-mail nebo telefon se mohou měnit a nemusí být jedinečné. Při prvním propojení vytvořte dohledatelnou vazbu a stanovte pravidlo pro duplicity. Ruční sloučení vyžaduje audit, aby další synchronizace záznam znovu nerozdělila.
U produktů rozlišujte interní ID, SKU, EAN a identitu varianty. U firmy může existovat právní subjekt, provozovna a kontaktní osoba. Identifikátor vybírejte podle objektu, nikoli podle pohodlí jedné obrazovky. Pokud stabilní klíč chybí, navrhněte kontrolovaný párovací proces s viditelnými nejistými případy.
- stabilní ID zdroje a cíle
- pravidlo prvního spojení a duplicity
- audit ručního sloučení
- chování při chybějící identitě
Popište význam, formát a transformaci pole
Mapovací položka má obsahovat obchodní definici, zdrojové a cílové pole, datový typ, povinnost a transformaci. U částky uveďte měnu a způsob práce s daní, u data časové pásmo, u adresy strukturu a u seznamu povolené hodnoty. Stejný název bez jednotky může způsobit tichou chybu.
Transformace udržujte deterministické a testovatelné. Normalizace telefonního čísla, převod stavu nebo spojení jména mají mít popsané vstupy i ztrátu informací. Pokud cíl nedokáže zachovat detail zdroje, rozhodněte, zda ho uložíte odděleně, nebo přenos odmítnete. Neznámou hodnotu automaticky nemapujte na nejbližší možnost.
Rozlište prázdnou, chybějící a neplatnou hodnotu
Chybějící pole může znamenat beze změny, prázdná hodnota smazání a null neznámý údaj. Význam musí být součástí kontraktu. Při částečné aktualizaci hrozí, že nepřítomná pole přepíšou cíl prázdnou hodnotou. Otestujte každou variantu a používejte explicitní operace, pokud API umožňuje rozlišit záměr.
Validace má rozlišovat dočasně neúplný záznam od trvale neplatného vstupu. Chybu vraťte s identifikátorem pole a bezpečným důvodem. Pokud proces umožňuje karanténu, odložte chybný záznam k opravě bez zastavení celé dávky. Opravenou hodnotu znovu zpracujte stejným kontrolovaným postupem.
Verzujte mapování a testujte reprezentativní data
Ke každé změně zaznamenejte důvod, vlastníka, datum a dopad na historické záznamy. Přidání nové povinné hodnoty může vyžadovat zpětné doplnění nebo přechodné období. Mapování ukládejte spolu s kódem nebo konfigurací tak, aby se dalo spojit s konkrétním nasazením a bezpečně vrátit.
Testovací sada zahrnuje běžné případy, diakritiku, dlouhé hodnoty, neznámé enumy, změnu identity, časové hranice a duplicity. Výsledek porovnejte na obou stranách i v uživatelském procesu. Technicky úspěšná odpověď nestačí, pokud se údaj zobrazí v nesprávné měně nebo se přiřadí jinému zákazníkovi.
- změna významu nebo datového typu pole
- nová hodnota mimo známý seznam
- hranice časového pásma a měny
- neúplný historický záznam při migraci
- dohledatelný výsledek na obou stranách
- změna identity nebo sloučení duplicitních objektů
- bezpečné chování při chybějící povinné hodnotě
Časté dotazy
Co je zdroj pravdy?
Je to systém nebo proces oprávněný rozhodovat o konkrétním údaji. Nemusí být stejný pro celý objekt; například ERP může vlastnit sklad a CRM obchodní poznámku.
Stačí mapování v tabulce?
Tabulka je dobrý společný dokument, ale implementace potřebuje i testovatelná pravidla, verzi, vlastníka a vazbu na kód. Bez řízení změn se dokument a provoz rychle rozejdou.
Jak řešit hodnotu, kterou cílový systém nezná?
Nepřevádějte ji potichu. Zaveďte explicitní pravidlo, karanténu nebo rozšíření cíle podle obchodního významu. Vlastník procesu musí rozhodnout, jaká ztráta informace je přijatelná.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
