V sekci A nastavení aplikace v replikátoru se nastavuje vedle obecných údajů také typ instance ( CODE, DEV, TEST, PRE, PROD, SPEC, OTHER), která určuje účel dané instance. Jedna aplikace má většinou DEV (develop) instanci sloužící pro tvorbu konfigurace a výchozí replikaci připravených XDS. Pro účely testů se pak tyto struktury a nastavené konfigurace přehledů, akcí, složek atd. přenášejí na TEST pro ověření, pak případně na PRE (předprodukci) a pak na PROD (produkční, provozní prostředí).

K čemu omezení distribuce slouží

První problém, který řízení distribuce řeší, je ošetření „slepých uliček“ při XDS návrhu struktury a jejího ověřování na běžící DEV či případně i TEST instanci. Může být, že před vypuštěním finální verze na PROD ještě dojde k mnoha úpravám a s tím souvisejících deaktivací již zavedených struktur na DEV. Potíž je ale v tom, že jakmile se určitá struktura z XDS definice dostane do uzavřené verze dané instance, již v dané struktuře zůstává natrvalo, a to i v případech, kdy je v návrhovém XDS opět odebrána. V historii aplikace zůstává. Každá aplikace má všemi instancemi sdílené soubory historie pro XDS a analogicky i DAD, které se s XDS přímo odvíjí. Tyto historické soubory ( history.xds a history.dad) jsou uloženy v podsložce data v definiční složce aplikace, která je zpravidla sdílena mezi různými typy instancí dané aplikace ( DEV, TEST, PROD atd.). Hlavním cílem těchto souborů je zachovávat historickou konzistenci struktury a řízení povolených změn, například nemůžete změnit určité pole z textového na číselné, nelze zkracovat délku polí atp. Existence history XDS/DAD a jejich role při porovnání verzí a přípravě dalších fází replikace je v konceptové dokumentaci výslovně popsána. Právě v historických souborech jsou také zachovávána XDS id dokumentů, jejich oblastí a prvků, tedy segmentů. Podobně pak v historickém DAD se zachovávají id array polí předepisující strukturu tabulek relační databáze. Jakmile se struktura vypropaguje a uzavře ve verzi, zapisuje se v okamžiku uzavření verze do historických souborů. Historická stabilita identifikátorů segmentů a jejich role v dalších vrstvách systému je součástí popisu XDS a konceptu platformy.

Princip atributu only-for

Mimo tohoto zápisu se ale také označuje pomocí atributu only-for kódem typu instance. Například při prvním zavedení replikované struktury, například prvku z XDS, atributem:

 only-for="(DEV)"

Závorky jsou zde chápány jako oddělovače. Na místo čárek a mezer se kódy uzavírají do běžných závorek a každý kód je uveden maximálně jednou. Jakmile jde tento nový prvek v příkladu replikací podkladového XDS na TEST instanci, zapíše se při uzavření verze do atributu only-for tohoto prvku v historickém souboru hodnota (TEST), výsledný zápis atributu pak je:

 only-for="(DEV)(TEST)"

Tím je na úrovni historie evidováno, pro které typy instancí byl daný segment v okamžiku uzavření verze skutečně zaveden.

Jak funguje ochrana proti „slepým uličkám“

Pokud pak v našem příkladu v rámci testů dojde implementační tým k závěru, že prvek je „slepá ulička“ a nakonec nebude v provozu používán, odebere se z návrhového XDS, které vstupuje do replikace. V historii pro DEV a TEST už zůstane platný. Tedy i při odebrání zůstává součástí historie těchto instancí a tedy i jejich databází. Právě podle historických souborů se ověřuje, zda je databáze kompletní, a i při již neaktivních prvcích by se do databáze zavedla, protože databáze je tvořena dle historických souborů. Ale tady právě nastupuje automatická evidence kódů na segmentech XDS. Pokud tedy například náš prvek odebereme před prvním vyreplikováním na PROD, nebude v historii již kód pro PROD přidán. Před umístěním DAD mapy pro tvorbu databáze do složky role je pro danou instanci struktura odebrána, pokud nemá z uzavřené verze potvrzen výskyt kódem pro replikovanou instanci. Náš prvek, který byl z návrhu XDS odebrán a byla následně provedena krom DEV a TEST ověřovacích replikací nakonec také replikace na PROD, bude tedy z historie pro tuto instanci odebrán, jelikož v době první replikace již nebyl platný a není tedy pro tuto instanci určen. Výsledek je následující:

Na DEV a TEST zůstává historická stopa segmentu zachována.



Na PROD se segment při první produkční distribuci vůbec neuplatní.



Do produkční DAD a tím ani do produkční databázové struktury se takový segment nedostane.



Vývojové a testovací „slepé uličky“ se automaticky nepropíší do finálního prostředí.

Vazba na tvorbu DAD a rolových souborů

Tento mechanismus je důležitý právě proto, že replikace nepracuje pouze s návrhovým XDS, ale v dalších fázích vytváří DAD a připravuje soubory pro jednotlivé role. V konceptové dokumentaci je popsáno, že po převodu XDS na DAD dochází k porovnání s historií, vyznačení identifikátorů a následně jsou soubory XDS a DAD připravovány i pro další „osekání“ v rámci tvorby struktur pro jednotlivé role. Atribut only-for tedy neřeší pouze „vizuální“ nebo návrhové omezení, ale přímo omezuje, zda se určitá část struktury vůbec dostane do podkladů pro danou instanci a její databázovou realizaci.

Příklad průchodu mezi instancemi

Příklad 1: slepá ulička zachycená před produkcí

V DEV je zaveden nový prvek:

 <element name="new_temp_field" only-for="(DEV)" />

Po přenosu na TEST a uzavření verze se v historii segment rozšíří na:

 only-for="(DEV)(TEST)"

Během testování se ukáže, že jde o nevhodný návrh, a prvek je z návrhového XDS odebrán. Následně dojde k replikaci na PROD. Protože prvek již v době první produkční replikace v návrhu neexistuje, nevznikne pro něj kód (PROD). Při přípravě struktury pro produkční instanci je takový segment pro PROD odstraněn a nepromítne se ani do produkční DAD mapy ani do produkční databáze.

Příklad 2: pomocná vývojová struktura pouze pro DEV

Je možné mít v návrhu pomocná pole určená pouze pro vývoj nebo interní testy:

 <area name="debug_area" only-for="(DEV)">
<element name="debug_note" />
<element name="debug_flag" />
</area>

Při replikaci na jinou než DEV instanci se tato struktura odebere již v průběhu distribuce na cílovou instanci. Na DEV naopak zůstane. Tím se ani v historii nevyznačí pro jiné instance než DEV při uzavření verze.

Cílené použití only-for přímo v návrhovém XDS

Tuto funkci je ale možné používat nejen jako automatický hlídací mechanismus, který zajistí, že se zbytečné „slepé uličky“ struktury nedostanou do finálního prostředí. Je možné ji používat také cíleně přímo v návrhovém XDS. I zde existuje pro segmenty, tedy dokument, oblast i prvek, možnost je označit vlastností only-for a uvést, do které instance se má daná struktura dostat. Pozor jen na jedinou věc - vlastnost only-for zapsaná v návrhovém XDS má jinou syntaxi, používá čárkami oddělený seznam typů instancí: Například: Takový zápis znamená, že segment je určen pouze pro vývojovou a testovací instanci, ale nikoli ještě pro PRE nebo PROD. Princip je ale jasný, díky přímému zápisu v návrhu XDS můžeme pro DEV či TEST mít pomocná pole, která jinde vůbec nechceme, nebo je možné si už před release verze na produkci připravovat další struktury pro další verzi, další release. Můžeme tak ve formuláři mít například novou oblast prvků a označit ji přímo v návrhu, že má být použita nejprve pouze pro DEV. Při replikacích na TEST a další se tato struktura odebere při replikaci na jiné než DEV instanci a na DEV naopak zůstane. Jakmile potřebujeme postoupit tyto určité připravené struktury dále, můžeme buď:

omezující atribut úplně z návrhu XDS odebrat, nebo



cíleně přidat například TEST a tím zajistit distribuci jen při replikaci na TEST instanci (tak jak je uvedeno v příkladu výše).

Vztah návrhového zápisu a zápisu v historii

Je dobré si uvědomit jednu klíčovou okolnost, vztah mezi atributy only-for zapsané v návrhu a only-for evidované automaticky v historii. Zápisem v návrhu nemáme plně pod kontrolou to, co je pak evidováno v historii aplikace. Zápisy only-for atributů do historie replikátorem (v závorkové syntaxi) funguje jako kontrolní mechanismus zajišťující, že určitá struktura, pokud již byla do databáze instance zapsána, nevypadne z úplné historické evidence pro danou instanci tak, aby mohly být prováděny dostatečné kontroly. Tj. pokud bychom chtěli po uzavření verze na TESTu vrátit zápis only-for z původního

only-for="DEV,TEST"

na pouhé

only-for="DEV",

tak to nebude mít žádný dopad do historického zápisu, tedy zápisu only-for v history souborech, tam bude i nadále:

only-for="(DEV)(TEST)"

Tedy jakmile je jednou pro danou instanci segment zařazen, již není možné jej nástroji replikátoru odebrat.

Typické případy použití

Pomocná vývojová pole

Pomocná pole, ladicí indikátory, interní poznámky nebo přechodové technické prvky, které mají existovat pouze na DEV nebo TEST.

Postupná příprava další verze

Struktury připravované dopředu pro další release, které zatím nemají být součástí produkčního prostředí, ale implementační tým je chce mít připravené a průběžně rozpracované.

Oddělené ověření na TEST

Struktura se nejprve zpřístupní pouze na DEV, následně pouze na TEST, a teprve po ověření je uvolněna i pro další instance.

Ochrana finálního prostředí

Mechanismus automaticky zajistí, že segmenty, které v návrhu zanikly ještě před první produkční distribucí, nebudou do produkce historicky zavedeny.

Praktické zásady

Atribut only-for je třeba chápat jako omezení distribuce struktury podle typu instance, nikoli jako běžný prostředek pro řízení práv uživatelů nebo rolí. Řeší, zda se určitý segment stane součástí replikované a uzavírané struktury konkrétní instance. Je rovněž třeba počítat s tím, že jakmile je segment jednou pro určitý typ instance historicky uzavřen, zůstává v historických souborech této instance zachován. Ochranný efekt mechanismu se tedy naplno projeví zejména tehdy, když je nevhodná nebo přechodná struktura odstraněna ještě před prvním zavedením do cílové instance.

Shrnutí

Atribut only-for slouží k omezení distribuce segmentů struktury podle typu instance aplikace. Jeho význam je dvojí:

automaticky chrání finální prostředí před zavedením vývojových a testovacích „slepých uliček“,



umožňuje cíleně připravovat a udržovat struktury určené jen pro vybrané instance.

V návaznosti na historické soubory history.xds a history.dad a na další fáze replikace, zejména tvorbu DAD a rolových souborů, představuje only-for důležitý mechanismus řízení životního cyklu struktury mezi DEV, TEST, PRE a PROD. Vazba replikace na historii XDS/DAD, další tvorbu DAD a přípravu rolových struktur je v koncepční dokumentaci popsána přímo.