Uplatnění definice

XML soubor(y) s popisem požadovaných dokumentů - XDS (Xml Document Specification) řeší tyto okruhy:

jména, datové typy, ikony a popisy segmentů vč. jejich uspořádání,

přístupová práva k dokumentům či jejich částem, k nástrojům pracovní plochy a datovým procesům,

propojení dokumentů – tj. které dokumenty spolu souvisí a jakým způsobem vč. vzájemného využívání,

formáty zadávaných dat a jejich zobrazování či tisk,

vzájemné ovlivňování zobrazení a výpočty ve formuláři,

kontrolní a ochranné mechanismy,

akce pro usnadnění práce s daty zejm. ve formuláři,

nastavení výchozích a automatických hodnot,

propojení s jinými aplikacemi, mapovací schemata.

Definice je koncipována tak, aby bylo co možná nejjednodušší aplikaci definovat a minimalizovat tak časovou náročnost jejího zavádění i pozdějších úprav.

Struktura navržené definice je před generováním verze replikátorem důkladně prověřována tak, aby byly podchyceny pokud možno všechny chyby způsobené lidským faktorem při návrhu definice.

První návrh XDS je brán v rámci jedné aplikace jako výchozí verze a všechny další jako její aktualizace. Při generování aktualizací na základě upraveného XDS tedy dochází i ke zpětným srovnáním a kontrolám. Tuto činnost zajišťuje správa verzí ve flexideo replikátoru.

Přístupová práva a restrikce se udělují pomocí přístupových úrovní (levels) a upravují pomocí příslušnosti k oddělení (sections) každého uživatele. Podle nastavení uživatele je mu přisouzena nebo vygenerována přesně odpovídající role. Tato role pak slouží pro přidělení práv na aplikačním serveru.

I. Kompletace XDS

Struktura definice je defakto sada nástrojů pro definici segmentů informační struktury flexideo pomocí přiřazování vlastností daným uzlům ve stromové struktuře. Každá vlastnost má svůj význam, syntaktickou strukturu a také má většinou dánu výchohzí nebo odvoditelnou hodnotu.

Dle pravidel zápisu XDS se při definování struktury zcela běžně kalkuluje s tím, že většina vlastností segmentů a definičních substruktur se v návrhu XDS vůbec neuvádí. Celý koncept je založen na skutečnosti, že většina vlastností buď vůbec nejsou třeba a především pak na tom, že většina má výchozí nebo odvoditelný obsah.

Dokonce i samotné uvedení uzlu segmentu či substruktury není mnohdy vůbec zapotřebí a je pováděno jeho odvození dle souvislostí a pravidel zápisu definice.

Cílem první fáze přípravy XDS tedy je:

jednak verifikace zápisu uzlů a jejich vlastností a

jednak doplnění chybějících uzlů a vlastností;

Hlavním vstupem do kompletace je jeden nebo více XDS souborů, které popisují aplikační strukturu replikované aplikace. Tento soubor nebo soubory definice jsou umístěny ve složce aplikace. Bližší info ke složkám replikátoru a aplikace viz. vstupní soubory v popisu souborů replikace. Dále do replikace vstupují také apliační nastavení

Při replikaci verze může být zvoleln režim replikace Pouze změny (ligth upgrade). Pak replikátor před započetím verifikace a kompletace XDS nejprve porovná vstupní XDS se vstupním XDS předchozí verze a po prověření všech propojení a závislostí vybere jen ty definice dokumentových typů, kde došlo ke změně (přímé nebo následené díky některému druhu vazby mezi dokumenty). Verifikaci a kompletaci pak provádí jen nad dokumenty s identifikovanou změnou.

Výstupem první přípravné fáze repliace je pak jednak plně kompletní XDS, jednak také různé další formy pomocných XDS, například XDS pouze s vlastnostmi potřebnými pro tvorbu DAD, které je odvozováno v druhé fázi. Dále je pak připraveno history.xds. Tzv. historická XDS slouží k udržení povědomí o všech segmentech, které byly v minulosti definovány. Zejména jde o kontrolu historických návazností jednotlivých verzí. Jsou tak při kompletaci XDS kontrolovány takové věci jako povolené změny datových typů prvků, unikátnost jmen s ohledem na historii, je předem ověřováno, zda provedené změny jsou povolené z hlediska databáze, ale i ztráty dat. Je tak např. zakázáno zkracování polí atp.

Všechny soubory, které v průběhu replikace vznikají, jsou ukládány do složky verze, kde čekají na dokončení replikace a uzavření verze. Buď budou vloženy na server a aktualizují příp. předchozí soubory nebo aktualizují soubory ve složce verze, aby se tak staly výchozími pro další verze. Pro případ replikace v režimu Pouze změny je řada souborů také ponechána ve složce verze tak, aby byly jejich části použitelné pro rychlejší poskládání souborů verze nové, pokud není třeba jejich znovuvytváření. Stejně tak se ve složce verze uchovávají jak vstupní, takt také kompletní XDS a history XDS verze.

II. Tvorba DAD

Druhou fází replikace je příprava datových polí, která jsou jednoznačně odvozována z XDS definice. Server flexideo nezná XDS definici. XDS definice nikam dál než do složky verze necestuje. XDS tak není nikde vystavováno a není k dispozici ke stažení. Jakožto jeden ze zdrojů aplikace je chráněn jako zdrojový soubor. Ani DAD není k dispozici ke stažení ze serveru, server si jej uloží jen k potřebám verifikace databáze a sesatvování dokumentů, ale není k dispozici. Nicméně z DAD není možné zpětně odvodit XDS, protože celá řada vlastností v něm chybí.

Přesným metodám rozkladu (převodu) XDS na DAD je věnována samostatná kapitola DAD v sekci replikátor Zde jen popíšeme princip replikace a vzniku souborů verze.

DAD soubory mají, stejně jako XDS, svou podobu pro danou verzi a je připravován history soubor pro srovnání s předchozí verzí a kontrolu platnosti změn a identifikaci nových polí anebo jeho prvků.

Do DAD nejsou převáděny všechny dokumentové typy, jsou vynechány pohledové a pseudo typy. Pro tvorbu jsou tak určeny je základní dokumentové typy, které jsou jako jediné určující pro strukturu databáze. Proto se základním dokumentovým typům říká také databázové dokumentové typy.

Jakmile je XDS převedeno na DAD je porovnáno s historií, dle historické evidence polí jsou pak do převedeného DAD vyznačena ID polí a prvků. Stejně tak jsou ID polí a prvků zpětně vyznačena i do XDS verze. Spolu s ukončením tvorby DAD je tak zároveň ukončena i příprava pro aktualizaci XDS a DAD struktur apliakce a jsou připraveny nové soubory historie pro platné uzavření verze.

Soubory XDS a DAD jsou zároveň připraveny na "osekání" v rámci přípravy struktur pro jednotlivé role v další fázi.

III. Tvorba souborů rolí

XDS a DAD soubory z předchozích dvou fází jsou následně, ve fázi třetí, upraveny dostupnost segmentů v jednotlivých rolích, případně jsou segmenty pro určitou roli odebrány, pokud k nim nemá mít uživatel v dané roli mít přístup a jsou vytvořeny soubory role.dad a role.xds.

Soubory, které jsou pro role tvořeny by se daly rozdělit do několika skupin:

seznamy role jde o soubory, které dle upravené XDS role vytvoří různé druhy rejstříků role, například nabídku dokumentů, nabídku pohledů databázového typu, přehled mapování na externí typy atd.;

šablony dokumentů v roli existuje pro každý dokumentový typ v roli obsažený složka, v rámci které jsou k dispozici např. generované nebo vyvinuté tiskové šablony, převodní šablony (pohledy, pseudo-typy, výběrové uzly), vzory pro nové dokumenty, generované mapovací šablony na externí typy;

menu & tools jsou opět soubory zejména pro dokumentový typ, ale i roli, replikátor tvoří podkladové XML pro výběrová menu ze struktur dokumentů, jejich vazeb, prvků a oblastí, tvoří vzory pro zakládání dokument-set v akcích (např. pro save-document, save-draft aj.), soubor s popisem struktury dokumentu a definice dokumentů pro COMEX;

formuláře dokumentu pro každý dokumentový typ - vedle toho, že dokument je možné automaticky poskládat, vytisknout nebo použít dle zdrojových předpisů v jiném dokumentu, je možné jej také editovat formulářem a to vč. pohledových a pseudo dokumentových typů. Pro účely intranetových a COMEX formulářů tak replikátor v rámci každé role připraví patřičné instrukce a potřebné definice pro editaci flexideo definovaných dokumentů, vč. pokročilých možností přístupů, podmíněné editovatelnosti, skrývání či customizací;

Přehled souborů tvořených v každé verzi pro replikovaný dokument je zdokumentován v článku Výstupní soubory verze v sekci replikátor.

IV. Instalace verze

Soubory připravené nebo předpřipravené v předchozích fázích je třeba dostat na flexideo server, odkud jsou dále dle potřeb po přihlášení distribuovány do light-client rozhraní uživatelů.

Soubory jsou na server přesouvány dvojím způsobem:

on-line přímo přes webový endpoint spuštěné flexideo instance (naprostá většina případů) nebo přes namapovaný síťový disk, FTP/VPN apod. nebo

off-line v případech, kdy například startujeme novou instanci a server ještě neběží a není možné jej kontaktovat je možné připravit do určené dostupné složky instalační balík, který je pak doručen a zapsán na server jiným způsobem;

Ať již se podaří login na server či nikoli, jako první je na řadě aktualizace platformy. O aktualizaci replikátoru, intranetu a COMEX rozhraní na úrovni platformy se stará systém aktualizací flexideo. V rámci replikace verze je vždy nejprve prověřeno, zda není třeba pro danou instanci doplnit nějakou platformní aktualizaci. Tutu funkci lze samozřejmě vypnout, ale je to nedoporučovaný postup. Je však možné volit, zda pro určitou instanci chci nebo nechci instalovat beta-verze, které jsou užitečné na zkušebních / testovacích instancích pro ověření, zda připravovaná verze platformy flexideo nepřinese nějaké nežádoucí úpravy (byť by k tomu, vzhledem k obecnosti a konceptu oddělenosti vývoje technologií od aplikační logiky, nemělo takřka vůbec docházet).

Následně je sestaven a odesílán nejobjemnější balík replikovaných souborů aplikační úpravy v rámci verze. U větších instancí, pokud není replikováno v režimu pouze změn nebo je těchto změn hodně, může jít řádově i o tisíce souborů určených pro různé dokumenty a různé uživatele v různých rolích pro výše popsané účely.

Jako poslední jsou na server dopravováný soubory aktualizující nejrůznější protokoly, především pak podklady s mapami externích API, na které se v rámci intranetu bude určitá instance flexideo napojovat. Jde o mapy pro tvorbu, nikoli provozování takových API napojení. Přestou jsou tyto preventivně aktualizovány s každou replikací a následnou instalací verze.

V případě nejčastějšího přesunu přes funkční webový endpoint běžící aplikae dochází po uploadu všech souborů do přípravné složky k dotazu, zda má být verze zavedena. Po jeho potvrzení dojde na staraně serveru k masivnímu přenosu nahraných souborů do jejich cílového uložiště a ve většině případů též k vyvolání tzv. dad update, tedy zavedení odeslaných DAD map do struktury SQL databáze. V takovém případě (a pouze při něm) dojde ke krátké odstávce serveru, o které server flexideo všechny uživatele korektně informuje a rámci této pauzy provede aktualizaci databáze. Následně aplikaci opět zpřístupní, aktivuje komunikaci s uživateli.