Každá seriózní implementace dělá dva kroky, na které každodenní rozhraní stavěné není. Data přicházejí dovnitř — z odstavovaného staršího systému, z tabulky, kterou někdo pět let udržoval, z exportu od partnera, z jednorázového čištění dat, po kterém zbylo CSV, jež někdo potřebuje nahrát. Konfigurace odchází ven — z testovacího prostředí, kde tvůrci stavěli, do produkčního prostředí, kde budou žít koncoví uživatelé; nebo ze „šablonového“ prostředí představujícího standardní rozjezd do nového zákaznického prostředí, které se z té šablony zakládá. Platformy, které ani jeden z těch kroků neberou jako plnohodnotnou funkci, končí u křehkých ručně psaných skriptů — a přesně tam projekty migrace dat umírají. My jsme obojí postavili jako funkci.
Import záznamů začíná tabulkou. CSV a XLSX jsou dva formáty, které uživatelé už mají — ať přišly ze starého systému, od partnera, nebo od kolegy, který žije v tabulce. Importér přijme oba, přečte sloupce a nabídne krok mapování, kde uživatel platformě řekne, který zdrojový sloupec plní kterou cílovou vlastnost. Rozhraní pro mapování je stavěné na běžný případ, kdy jsou názvy sloupců blízké, ale ne totožné — „Customer Name“ se namapuje na vlastnost Name, „Email Addr“ na Email a tak dále — s rozumnými výchozími návrhy tam, kde je mapování zřejmé.
Mapování sloupců je záměrně pružné, protože zdrojová data málokdy přesně odpovídají cílové struktuře. Ne každý sloupec ve zdroji musí někam vést; sloupce, které nejsou relevantní, lze ignorovat. Ne každá cílová vlastnost musí mít zdroj; vlastnosti bez namapovaného sloupce si vezmou výchozí hodnotu nebo zůstanou prázdné. S chybějícím sloupcem se zachází vstřícně — pokud zdroji chybí sloupec, který cíl očekává, import kvůli tomu rovnou nespadne; pokračuje se sloupci, které má, a uživatel se sám rozhodne, jestli chybějící údaje doplní později. Tahle tolerance je důležitá, protože reálná data nikdy nejsou tak čistá, jak cílový model předpokládá.
Typová bezpečnost brání tomu, aby import cíl poškodil. Importér respektuje typy vlastností: číselné vlastnosti přijmou jen hodnoty, které se dají přečíst jako čísla; datové vlastnosti jen platná data; výběrové vlastnosti jen hodnoty z nakonfigurovaných možností. Řádky s hodnotami, které se nehodí, se označí, místo aby se potichu přetlačily do něčeho špatného. Validační mechanismus je tentýž, který hlídá běžné odesílání formulářů, takže import a rozhraní sdílejí jednu definici „platného“ — a data naimportovaná z tabulky jsou stejně důvěryhodná jako data zadaná ručně.
Náhled před importem je pojistka, díky které se z chyb nestávají krize. Než se cokoli zapíše, platforma ukáže náhled: tolik řádků se vytvoří, tolik se aktualizuje, tolik bylo označeno a vůbec se nenaimportuje. Uživatel náhled zkontroluje, potvrdí a import proběhne naostro. U velkých importů, kde by chyba mohla zasáhnout tisíce záznamů, je právě tento krok tím, co z importu dělá místo strašidelného jednorázového pokusu sebejisté rozhodnutí.
Hromadné vytvoření nebo aktualizace se nastavuje u každého importu zvlášť. Některé importy mají vždy vytvářet nové záznamy (čerstvá dávka leadů z kampaně). Jiné mají vždy aktualizovat existující záznamy podle shody na identifikátoru (noční synchronizace ze zdroje pravdy). Další mají být „upsert“ — vytvořit tam, kde shoda není, aktualizovat tam, kde je. Uživatel zvolí správný režim pro daný úkol a klíčem pro párování může být kterákoli jedinečná vlastnost cílového typu.
Zpracování částečného selhání brání tomu, aby velké importy byly všechno, nebo nic. Pokud řádek 1 247 z 10 000 obsahuje hodnotu, která neprojde validací, řádky 1 až 1 246 se nevrátí zpět a řádky od 1 248 dál se nepřeskočí. Špatný řádek se zaznamená se srozumitelným důvodem; zbytek importu pokračuje; na konci uživatel dostane report se seznamem řádků, které prošly, a těch, které byly označeny k prověření. Takhle import ve skutečnosti funguje, když funguje dobře: většina dat je v pořádku, část potřebuje pozornost a uživatel chce vyřešit výjimky, aniž by dělal celou práci znovu.
Export datového modelu je doprovodná funkce pro stranu konfigurace. Celou implementaci — typy, vlastnosti, dotazy, pohledy, automatizace, e-mailové šablony, uspořádání dlaždic na domovské stránce — lze vyexportovat jako jeden přenositelný soubor. Ten soubor je serializovaná podoba modelu, ne dat: zachycuje „jak aplikace vypadá“, ne „co aplikace obsahuje“. Tvůrce, který postavil funkční konfiguraci v testovacím prostředí, ji může vyexportovat, předat soubor produkčnímu prostředí a znovu ho naimportovat, aby tam tutéž konfiguraci oživil.
Export je dostupný jako akce v rozhraní i jako akce automatizace. Cesta přes rozhraní je to, co použije tvůrce-člověk: otevře dialog exportu, zvolí rozsah, stáhne soubor. Cesta přes automatizaci je to, co používají automatizované nasazovací pipeline: naplánované workflow, které pravidelně pořizuje snímek aktuálního modelu, přiloží export k e-mailu, nebo ho odešle do úložiště souborů k archivaci. Obě cesty produkují stejný formát, takže tentýž soubor poslouží pro ruční i programový opětovný import.
Verzování a záchyt stavu v čase dělají z exportů modelu vhodný konfigurační archiv, ne jen jednorázový přenos. Export pořízený dnes odpovídá modelu ke dnešku; export pořízený příští měsíc odpovídá modelu k příštímu měsíci. Porovnání obou vypráví příběh o tom, co se mezitím změnilo. U regulovaných implementací, kde je potřeba změny konfigurace dokládat, je taková posloupnost exportů opravdovou auditní stopou.
Opětovný import implementace řeší konfliktní případy s rozvahou. Import do prázdného prostředí je ten snadný případ — všechno se vytvoří od nuly. Import do prostředí, které už nějakou konfiguraci má, je tam, kde záleží na řešení konfliktů: importér kolize odhalí, ukáže je uživateli a nechá ho zvolit, jestli přepsat, přeskočit, nebo přejmenovat. Právě tahle pružnost dělá z exportu a importu modelu něco skutečně použitelného v reálných situacích, kde cíl není čistý list.
Synchronizace prostředí je příbuzná funkce pro přenos konfigurace mezi prostředími formou řízeného exportu, náhledu a použití – ne snímkem, který ručně naimportujete zpět. Té se věnuje článek o přizpůsobení pro zákazníky; ve zkratce, tam kde je export modelu „pořiď snímek, přenes ho, znovu naimportuj“, je synchronizace prostředí „vyexportuj balíček, prohlédni si změny a slouči je do cílového prostředí“. Různé nástroje na různou práci: export modelu se hodí na jednorázové přenosy a rozjezdy ze šablony, synchronizace prostředí na opakované, operátorem řízené přenosy mezi prostředími, kde se každé použití nejdřív zobrazí v náhledu a případné konflikty se vyřeší dřív, než se cokoli změní.
Ty dva kroky — data dovnitř, konfigurace ven — jsou místa, kde spousta implementačních projektů ukáže, jestli je platforma bere vážně. My ano. K příbuzným tématům: článek o exportu do tabulek popisuje směr dat ven, článek o přizpůsobení pro zákazníky popisuje alternativu se synchronizací řízenou operátorem a článek o úložišti souborů popisuje, kde zdroje importů a archivy exportů pohodlně bydlí.