Pre každý objekt určte zdroj pravdy a stabilnú identitu, potom pri každom poli popíšte význam, formát, jednotku, povinnosť, transformáciu a chybový stav. Mapovanie overte na reálnych výnimkách, verzujte ho a každú zmenu koordinujte s vlastníkmi oboch systémov.
Mapovanie dát medzi systémami nie je mechanické spájanie stĺpcov s podobným názvom. Pole zákazník môže v CRM znamenať obchodný kontakt, v ERP fakturačný subjekt a na webe používateľský účet. Ak integrácia nerozlíši význam, prenesie syntakticky platné údaje do nesprávneho procesu a chyba sa môže prejaviť až pri fakturácii alebo podpore.
Kvalitné mapovanie opisuje vlastníctvo, identitu, povinnosť, formát, transformáciu a správanie pri neznámej hodnote. Dokument zostáva spoločným kontraktom obchodného a technického tímu. Musí sa dať testovať a verzovať, pretože oba systémy sa vyvíjajú. Jednorazová tabuľka bez vlastníka rýchlo prestane zodpovedať realite.
Začnite objektmi, udalosťami a vlastníctvom
Nakreslite, ktoré objekty sa prenášajú a pri akej udalosti. Objednávka, zákazník, produkt a platba majú odlišný životný cyklus. Určte systém, ktorý smie meniť konkrétny údaj, a systém, ktorý iba prijíma kópiu. Obojsmerná synchronizácia bez pravidiel konfliktu môže prepísať novšiu hodnotu staršou.
Rozlíšte vytvorenie, aktualizáciu, archiváciu a vymazanie. Nie každý stav sa má automaticky šíriť. Zrušený kontakt v marketingu nemusí znamenať odstránenie účtovného záznamu. Vlastník procesu musí potvrdiť význam udalosti a pravidlá uchovávania; technická integrácia ich nemá vymýšľať podľa dostupných endpointov.
Používajte stabilné identity a párovaciu tabuľku
Uchovávajte interné a externé identifikátory vedľa seba. Názov, e-mail alebo telefón sa môžu meniť a nemusia byť jedinečné. Pri prvom spojení vytvorte dohľadateľnú väzbu a stanovte pravidlo pre duplicitu. Manuálne zlúčenie potrebuje audit, aby ďalšia synchronizácia záznam znovu nerozdelila.
Pri produktoch rozlišujte interné ID, SKU, EAN a identitu variantu. Pri firme môže existovať právny subjekt, prevádzka a kontaktná osoba. Identifikátor vyberajte podľa objektu, nie podľa pohodlia jednej obrazovky. Ak stabilný kľúč chýba, navrhnite kontrolovaný párovací proces s viditeľnými neistými prípadmi.
- stabilné ID zdroja a cieľa
- pravidlo prvého spojenia a duplicity
- audit manuálneho zlúčenia
- správanie pri chýbajúcej identite
Popíšte význam, formát a transformáciu poľa
Mapovacia položka má obsahovať obchodnú definíciu, zdrojové a cieľové pole, dátový typ, povinnosť a transformáciu. Pri sume uveďte menu a prácu s daňou, pri dátume časové pásmo, pri adrese štruktúru a pri zozname povolené hodnoty. Rovnaký názov bez jednotky môže vytvoriť tichú chybu.
Transformácie držte deterministické a testovateľné. Normalizácia telefónu, prevod stavu alebo spojenie mena majú mať popísané vstupy aj stratu informácie. Ak cieľ nedokáže zachovať detail zdroja, rozhodnite, či ho uložíte oddelene alebo prenos odmietnete. Neznámu hodnotu nemapujte automaticky na najbližšiu možnosť.
Rozlíšte prázdnu, chýbajúcu a neplatnú hodnotu
Chýbajúce pole môže znamenať bez zmeny, prázdna hodnota vymazanie a null neznámy údaj. Význam musí byť súčasťou kontraktu. Pri čiastočnej aktualizácii hrozí, že neprítomné polia prepíšu cieľ prázdnou hodnotou. Testujte každý variant a používajte explicitné operácie, ak API umožňuje rozlíšiť zámer.
Validácia má rozlišovať dočasne neúplný záznam od trvalo neplatného vstupu. Chybu vráťte s identifikátorom poľa a bezpečným dôvodom. Ak proces dovolí karanténu, chybný záznam odložte na opravu bez zastavenia celej dávky. Opravenú hodnotu znovu spracujte rovnakým kontrolovaným postupom.
Verzujte mapovanie a testujte reprezentatívne dáta
Ku každej zmene zaznamenajte dôvod, vlastníka, dátum a dopad na historické záznamy. Pridanie novej povinnej hodnoty môže vyžadovať spätné doplnenie alebo prechodné obdobie. Mapovanie ukladajte spolu s kódom alebo konfiguráciou tak, aby sa dalo spojiť s konkrétnym nasadením a bezpečne vrátiť.
Testovacia sada zahŕňa bežné prípady, diakritiku, dlhé hodnoty, neznáme enumy, zmenu identity, časové hranice a duplicity. Výsledok porovnajte na oboch stranách aj v používateľskom procese. Technicky úspešná odpoveď nestačí, ak sa údaj zobrazí v nesprávnej mene alebo priradí inému zákazníkovi.
- zmena významu alebo dátového typu poľa
- nová hodnota mimo známeho zoznamu
- hranica časového pásma a meny
- neúplný historický záznam pri migrácii
- dohľadateľný výsledok na oboch stranách
- zmena identity alebo zlúčenie duplicitných objektov
- bezpečné správanie pri chýbajúcej povinnej hodnote
Časté otázky
Čo je zdroj pravdy?
Je to systém alebo proces oprávnený rozhodovať o konkrétnom údaji. Nemusí byť rovnaký pre celý objekt; napríklad ERP môže vlastniť sklad a CRM obchodnú poznámku.
Stačí mapovanie v tabuľke?
Tabuľka je dobrý spoločný dokument, ale implementácia potrebuje aj testovateľné pravidlá, verziu, vlastníka a väzbu na kód. Bez riadenia zmien sa dokument a prevádzka rýchlo rozídu.
Ako riešiť hodnotu, ktorú cieľový systém nepozná?
Neprekladajte ju potichu. Zaveďte explicitné pravidlo, karanténu alebo rozšírenie cieľa podľa obchodného významu. Vlastník procesu musí rozhodnúť, aká strata informácie je prijateľná.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
