VÝBĚR Z OBLASTI
Postupy, pojmy
Segmenty a jejich vlastnosti
Klonování flexideo aplikací
Jednotlivé aplikace flexideo mohou být velmi různorodé. Jejich primární charakteristika, utvářená obsahem XDS, udává s jakými druhy informací ta či ona aplikace umí pracovat. K jakému účelu slouží. Nad touto základní strukturou utvářené funkcionality ve formě složek, přehledů a akcí pak předurčují její konečně rozhraní donastavované ve třetí, nejvyšší vrstvě - v COMEXu.
XDS, které je na samém začátku se tak promítá i do každé další části systému podobně, jako se DNA projevuje v každé části organismu. Z každé tabulky, akce či samotného dokumentu jedné flexideo aplikace je možné vyčíst zda je příbuzná s aplikací jinou nebo zda je dokonce jejím klonem. K těmto identifikacím slouží signatura v podobě jedinečných celočíselných id a také pojmenování použitých struktur.
Dostáváme se tak k tomu, že některé aplikace jsou si cizí, jiné jsou více či méně příbuzné, některé jsou jako jednovaječná dvojčata a jiné jsou čistě klony nebo jimi původně byly.
To co vypadá tak trochu jako science fiction má své praktické dopady a je třeba tyto faktory předem důkladně zvážit, než se pustíme do tvorby aplikace tím či oním způsobem.
V následujících sekcích tohoto článku o Klonování flexideo aplikací si ukážeme proč klonovat.
Klon nebo kopie? V čem je rozdíl
Zde je zobrazeno pár základních pojmů.
Pojďme se na ně podívat.
Kopie - je prosté zkopírování hotové aplikace z jednoho úložiště do druhého. Všechny kopie sdílejí jedno XDS a společná nastavení aplikace v replikátoru. Všechny takto vzniklé instance jsou strukturálně a funkčně identické.
Klon - je vytvořen založením nové instance v replikátoru a může tak mít své vlastní XDS. Vždy však má své vlastní nastavení (*.xcf) a seznam verzí. XDS se jako výchozí přebírá z jiné aplikace. A přebírá se nejen návrhářské XDS, ale také historické XDS a historické DAD. Mohou být použity jen části nebo komplet. Díky komplexnímu přenosu struktur je přenášena i celočíselná signatura. To je pro klon určující.
Příbuzná - aplikace je tvořena buď s velkým přispěním XDS výchozí aplikace (blízký příbuzný) nebo jen velmi podobným způsobem řeší určité téma. U blízkých příbuzných aplikací je možný mapovací přenos nastavení intranetových uzlů. Na rozdíl od klonu u příbuzných nedochází k přenosu signatury a není tedy možný přenos přímý, bez tvorby mapování.
Ostatní - aplikace jsou ty, které nevykazují při srovnání žádné výraznější podobnosti. Zde je i mapovací přenos nastavení zcela vyloučen.
Postupy a využití klonování
Základní charakteristikou klonu aplikace je tedy, vedle dostatečného strukturálního průniku (shody struktury), především provedení kompletního přenosu XDS včetně signatury strukturálních segmentů.
Kompletní tvorba klonu aplikace probíhá ve dvou základních fázích:
1. Založení aplikace klonu a převzetí XDS a DAD;
2. Přenos stromu nastavení z běžící aplikace.
Klon XDS
Klon ovšem nemusí z XDS přebírat všechny dokumentové typy, ale jen vybrané pomocí voleb pro klonování. A rovněž tak nemusí přebírat veškeré uzly stromu, ale jen určité větve. Záleží na účelu a rozsahu využití klonu.
Pokud tak chceme vytvořit klon úplný, například pro účely disponování zkušebním a produkčním prostředím téže aplikace, pak přebíráme kompletní XDS a DAD (viz. dále “Klon jako produkční prostředí”). Naopak v případě založení aplikace pro jiného konzumenta můžeme mít zájem postupovat při nasazení postupně a nebo s výraznými dalšími modifikacemi. Pak dočasně či definitivně přebíráme z XDS jen vybrané dokumentové typy a zakládáme vlastní historické definice. Rovněž v druhé fázi dochází k přebírání jen některých větví.
Vzhledem k tomu, že přebíráním celé definice tvoříme v klonu i celou šíři databázové struktury, je lépe postupovat opatrněji, pokud není od začátku jasně dán záměr převzít vše. Za tímto účelem aplikace, postavená jako klon umožňuje vybírat další, dosud nepoužité dokumentové typy, dodatečně až v době, kdy budou využity.
Při zakládání klonu, kde přebíráme jen část aplikace a nebo je předpoklad, že klon se bude strukturálně a funkčně odklánět a přizpůsobovat jinému uživateli, zakládáme aplikaci od začátku. Tvoříme pro ni nová nastavení s volbou “tvořit> jako klon”.
Při tvorbě klonu pro produkční prostředí či jiný účel, kde chceme zachovávat identickou shodu i do budoucna, provedem pouze kopii souboru nastavení a upravíme úložiště, název a adresu serveru, ale složku pro definici a ukládání historických XDS a DAD ponecháme stejnou. Stejně tak budeme používat stejné XDS pro návrh změn. Jen je doporučována jiná složka verzí, aby bylo možné tvořit úpravy odděleně. Replikátor si v takovém případě zajistí stejnou číselnou řadu napříč oběma aplikacemi, klonem i aplikací výchozí. Takto může být provozován i více než jeden klon.
Přebírání nastavení
V případě, že flexideo aplikace je vytvořena jako klon jiné aplikace výchozí, může být využito nástroje pro převzetí nastavení.
Jde tu o nastavení složek, přehledů, akcí a procesů. Přebírány jsou jak stromové struktury x_item, tak i jednotlivá nastavení settings a to jak pro intranetové rozsahy corporate a public, tak také pro COMEX třídy.
Při přebírání nastavení jsou respektována id jednotlivých položek informační struktury výchozí aplikace.
Převzít je možné jak jednotlivé uzly tak také celé větve, včetně těch kmenových, jimiž jsou tvořeny dílčí subaplikace COMEX jedné instance flexideo aplikace.
Aby bylo možné uzel či uzly převzít, je jednak zapotřebí mít admin oprávnění ve výchozí i cílové aplikací a jednak tyto uzly samy o sobě musí mít pro přenos povoleny. Každý uzel (id) stromů aplikace disponuje jedním ze čtyř stavů:
enabled - možný směr ven i dovnitř (zpravidla na klonovaných uzlech);
disabled - nemožno pro klon použít ani klonem přepsat;
rewritable - možno přepsat, ale z nějakého důvodu nelze klonovat;
usable - použitelné pro klonování, ale nelze jej přepsat;
Jednotlivé stavy jsou ukládány do x_item záznamů databáze a v intranetu jsou vyznačeny vyznačeny odpovídajícím symbolem.
Jakmile je v určitě instancí určitý uzel upraven, mění se automaticky jeho případné povolení přepisu na zákaz, aby nedocházelo ke ztrátám úprav. Tyto stavy je možné s patřičnými oprávněními v intranetu upravit dle potřeb a to jak pro dílčí uzel, tak i pro celou větev.
Bližší popis viz. použití nástroje pro převzetí nastavení.
Klon jako produkční prostředí
Specifickým, ale častým využitím principu klonu je pokrytí potřeby vývojového a produkčního prostředí určité implementace.
V takovém případě mají dvě či tři aplikace velmi úzkou vazbu v otázce definice. Většinou mají společné návrhářské XDS a také společné XDS a DAD historické, aby byla zajištěna velmi úzká návaznost.
V praxi to pak funguje tak, že instance mají společnou definiční složku a každá z nich si udržuje jen svá vlastní aplikační nastavení, jenž jsou třeba k samostatné existenci instance. Replikátor si v takovém případě sám od sebe udržuje napříč instancemi jednu číselnou řadu verzí, byť každá z obou či více sdružených instancí má svůj vlastní seznam verzí (většinou je složka verzí daných instancí oddělena).
V rámci vývojové instance se pak provádějí patřičné úpravy a ty se většinou jednosměrně přenášení jak v rovině XDS při replikaci, tak také v rovině intranetových uzlů na produkci.
Je ovšem možný i přenos zpět z produkce do develop instance. To platí zejm v případě rychlých oprav či operativních úprav. V takovém případě je potřeba přenastavit povolení přenosu těchto uzlů v intranetu tak, aby byl přenos možný, tj. povolen.
Kopie aplikace
V případě kopie aplikace nemůže docházet k jejímu samostatnému rozvoji, protože nedisponuje svou vlastní identitou v replikátoru, jako je tomu u klonu, který je plnohodnotné samostatnou aplikací.
Veškeré případné úpravy výchozí aplikace je třeba do těch cílových přenášet opět kopírováním, ať již přímým nebo sofistikovanějším, pomocí flexideo aktualizátoru.
Přenos uzlů ve struktuře aplikace je také možný, ale jednosměrný přenos aktualizátorem je v tomto případě mnohem smysluplnější volba. Viz. “Systém aktualizací”.