ZDE - KOMIX

KOMIX NOVINY 2011/2012
Vážení čtenáři,
minulý rok jsem v úvodníku použil větu: „Domnívám se, že právě v oblasti eGovernmentu má Česká
republika šanci se prosadit a tyto projekty se mohou stát naším exportním artiklem. KOMIX by byl
samozřejmě rád u toho a přispěl svou prací k úspěchu těchto projektů.“ Když se však dnes dívám
na projekt registrů, kde v době, kdy píši tento úvodník (tedy na začátku července) stále nejsou
uzavřeny smlouvy se všemi řešiteli, tak vidím, jak se tato šance zmenšuje. ICT Unie se snaží apelovat
na dokončení rozjetého projektu a její president burcuje zodpovědné úředníky pod obrázkem
nedostavěného Avignonského mostu, aby projekt dokončili. Nám nezbývá než volat s prezidentem
ICT Unie Svatoslavem Novákem: „Řešení dotažená do konce přinášejí úspory a politický kapitál.
Řešení zanechaná na půli cesty naopak oboje spotřebovávají!“
Obsah
Úvodník ...................................................................................... 1
„Čisté“ informační systémy........................................... 2
3 pilíře strategie testování...............................................3
Retrospektivy – nic složitého........................................5
Bohužel v politice to vypadá tak, jak to vypadá,
a firmy se musí připravit spíše na období nejistoty, na období, kdy nebudou do prosince vědět, jaké
budou platit daně v lednu a jestli pravidla stanovená jeden rok budou ještě ten další rok platit.
To samozřejmě vyžaduje od českých firem docela
slušnou míru flexibility a možná se za čas ukáže, že
trénink, který dostaly od vlády dnes, bude užitečný, až se začne ještě více otřásat Eurozóna a globální ekonomika bude mnohem více nestabilní.
Uvidíme!
My v KOMIXu hodně diskutujeme o tom, co dělat,
na co se v této trochu komplikované době zaměřit.
V rámci těchto diskusí padl také návrh trošku zmodernizovat logo a vypustit z něj pojem „systémový integrátor“, protože samotná systémová integrace již není v módě. Chvíli jsme si s tou myšlenkou
hráli, ale nakonec jsme to vzali od základu, od toho,
co děláme a co chceme dělat. Vyšlo nám, že většina našich projektů je právě o integraci – ať již jsou
to projekty, které konsolidují informační systémy
nebo do již existující IT infrastruktury zasazují nové
funkční celky. Skupina, která se zabývá datovými
sklady a oblastí Business Intelligence fakticky odvádí integrační práci v oblasti datařiny. Nejprve je třeba data z různých zdrojů integrovat a konsolidovat,
pak teprve nad nimi lze dělat smysluplné výstupy.
Implementace Identity managementu je čistá integrace. Stavíme-li portály, které dnes nutně slouží ke komunikaci s produkčními systémy, opět integraci neutečeme, to je integrace jako vyšitá! Má-li
být implementace CRM nebo systému pro Talent
management či aplikace pro podporu schvalovacích procesů úspěšná, musí být tyto systémy integrovány s okolím – ERP, Identity managementem,
HR atd. Když se zmíním o tom, že ať vyvíjíte to, či
ono, všude potkáváte stále se zvyšující požadavky
na bezpečnost, tak jsme zase zpět u integrace aplikací do bezpečnostní infrastruktury.
Naše diskuse tedy nakonec vedla k tomu, že logo
necháme a pokusíme se spíše rehabilitovat onu
systémovou integraci, o které se přestalo mluvit,
protože už je to stará a nemoderní disciplína. Jenže my si myslíme, že systémová integrace znamená
to, že informační systém vnímáme jako celek včetně všech jeho vazeb na okolí. Pohled integrátora
od sebe netrhá infrastrukturu a aplikace, neodděluje aplikace a jejich data, uživatelské rozhraní a uživatele, ale naopak propojuje IT technologie s potřebami zákazníků.
Právě současný rozvoj mobility, cloud computingu,
nových chytrých koncových zařízení, a požadavky
na to, aby to všechno moc nestálo a přitom to bylo
odolné proti nájezdům hackerů i proti obyčejné lidské nedbalosti či hlouposti, si přímo vyžaduje nějakého toho integrátora. Tedy někoho, kdo dokáže
požadavky zákazníka dát do kontextu s možnostmi
nových technologií, s požadavky na mobilitu a bezpečnost, a který dokáže zákazníka těmito úskalími
provést. Dnes nejde pouze o inhouse integraci, ale
je třeba zapojit informační systém do okolí, které je
mimo vlastní firmu. Část funkcí dáte do cloudu (někdy do několika), něco si necháte interně, propojujete se s partnery, dodavateli, odběrateli, se státem
(registry, datové schránky...), se zákazníky, s lidmi
na síti atd.
Proto jsme se rozhodli, že si toho „systémového integrátora“ necháme, a budeme se snažit tento pojem trošku zpopularizovat a hlavně dělat integraci jako poctivé řemeslo. Třeba zase přijde do módy.
Petr Kučera
Zajímavé vlastnosti PHP aneb OO v PHP 5
nejsou dvě nuly.......................................................................6
Novinky v aplikaci SONEF................................................7
Kovářova kobyla.....................................................................8
QlikView i pro controlling ve finančnictví?..........9
TalentCare aneb rychlý HR servis vytváří lepší
prostředí pro vaše zaměstnance..............................11
Modelování procesů a služeb, aneb ETL
procesy v praxi......................................................................12
Business Process Management v Activiti...........13
Geneze open-source ESB middleware
- infrastruktura pro novou generaci
podnikových systémů ....................................................14
Aplikační portál Oborové zdravotní
pojišťovny................................................................................17
IBM Infosphere Guardium............................................18
CyberArk – bezpečné řešení?.....................................18
Informix Warehouse Accelerator.............................20
Informix Genero...................................................................21
Vtipy, sudoku ....................................................................... 23
„ČISTÉ“ INFORMAČNÍ SYSTÉMY
Motto:
Kdy je IS hotov? - NIKDY …
Kdy je IS zastaralý? – IHNED
Kdy je IS čistý? …
Jaký informační systém je čistý?
V posledních letech jsme si zvykli na to, že se budují „zelené“ informační systémy (dále jen IS), „zelená“
datová centra, také se mluví o IT v oblacích (cloudu) a zcela jistě si vzpomenete i na další pojmy, kterými vás zasypává marketing výrobců informačních
technologií. Vždy je takový pojem spojen s tím, že
vám výrobce nějaké technologie potřebuje dát důvod pro to, abyste si tuto technologii pořídili.
My v KOMIXu jsme si řekli, že to zkusíme trošku obráceně. Zkusíme upozornit na to, že při dodržování
určitých zásad můžete naopak výrazně ušetřit, aniž
byste si tu úsporu museli kupovat investicí do technologie, kterou nemáte.
Právě dodržování zásad budování „čistých“ informačních systémů je něco, co máte plně v rukou,
něco, co nevyžaduje nákup speciálních nástrojů nebo technologií, co generuje výrazné úspory
a zvyšuje spokojenost uživatelů.
Naopak, nebudete-li zásady budování „čistých“ IS
dodržovat, přivodíte si problémy nejen s kvalitou
výstupů a spokojeností uživatelů, ale toto chování vygeneruje dodatečné investice do datových
pump a technologií pro čištění dat.
Zkusme si tedy „čistý“ informační systém definovat:
„Čistý informační systém je takový informační systém,
ve kterém není nutno pro účely reportingu čistit data
speciálními programy.“
Jak poznáme IS, který čistý není?
Podle jakých příznaků poznáme, že IS není čistý?
• V rozpočtu/účetnictví najdeme vysoké náklady
na projekty spojené s čištěním dat.
• Management nedůvěřuje číslům z reportingu,
jednotliví vedoucí si vedou vlastní minireporting
v Excelu, který je „lepší“ než oficiální. Různé odbory společnosti argumentují svými čísly, která
se neshodují s čísly odborů jiných.
• Rozumný reporting ve společnosti neexistuje,
omezuje se na standardní výstupy z účetního
softwaru.
• Odborné útvary prokazují, že některé činnosti se
nedají automatizovat, protože se nemohou spolehnout na kvalitu dat, o která se automatizovaný systém opírá.
2
• Jeden zákazník dostává tutéž informaci několikrát.
Půjdeme-li hlouběji a podíváme se, jak je IS postaven, můžeme se zaměřit na tyto jeho vlastnosti:
• Je produkční IS vybudován tak, že vytváří na sobě
nezávislá sila realizovaná samostatnými aplikacemi s oddělenými databázemi?
• Jsou navrženy primární databáze produkčního IS
tak, že umožňují evidovat nezávisle na sobě údaje o stejných objektech (zákaznících, produktech,
obchodních případech, ...)?
• Evidují se na různých místech o stejných objektech rozdílné atributy?
• Existuje metodika, jak v celé společnosti spravovat sdílené číselníky?
• Existují sdílené centrálně spravované registry
a číselníky jako takové?
• Existují metodiky pro práci s jednotlivými aplikacemi? Tj. může nastat situace, kdy třeba na několika pobočkách/dceřiných společnostech sice
používají shodné ERP, ale způsoby práce a atributy záznamů se lokálně liší? Pokud ano, pak se
jistě vyvinou „lokální“ ústně tradované zvyklosti
a „metodiky“. Důsledkem je to, že se ve stejných
sloupcích databáze nalézají data různého významu.
• Úplně nejlepší je, když se v rámci úspor při implementaci zvolila metoda: „Všechny atributy záznamu do pole poznámka“.
V takových IS je pak velice obtížné data převést
do konsolidovaného datového skladu a efektivně
je zpracovávat. Je velikým problémem data z takových zdrojů mezi sebou smysluplně propojit a produkovat věrohodné výstupy. Je nesnadné zodpovědět prostý dotaz „Kolik našich produktů si daný
člověk zakoupil?“ a to nemluvím o dotazu „Kolik
a jakých produktů si koupila tato rodina?“. V zásadě se v takovém IS nemusíte dopočítat ani počtu
zákazníků. To se samozřejmě generálnímu řediteli
těžko vysvětluje.
správu a kvalitu jejich dat. Pozor, to není úplně
triviální, je třeba mít procesy a IT podporu pro
řešení případů, kdy se při práci v některé z aplikací používajících registr nebo číselník zjistí nesprávnost.
4)Vytvořme metodiky pro tvorbu a údržbu obsahu registrů a číselníků. Ani to není úplně triviální záležitost. Používané kategorie musí odpovídat požadavkům na reporting, na to, jak
chceme reporty strukturovat, je třeba znát dopady změn.
5) Tím se dostáváme k disciplíně master data management. Doporučuji nastudovat a aplikovat
přiměřeně konkrétní situaci.
6) Stavme IS od samého počátku shora, od procesů, požadavků na výstupy a od požadavků
managementu na způsob řízení společnosti. Mějme na mysli, že nelze vybudovat kvalitní
reporting, jestliže produkční systémy neevidují informace, které management pro řízení potřebuje. Musí být zřejmé, jaké jsou klíčové indikátory, které řízená společnost sleduje, jak se
vypočtou, jak jsou interpretovány. Musí být jasné cíle a metriky, které měří, zda se k cíli blížíme nebo ne. Musí být jasně definováno, jaké
informace jsou pro řízení jednotlivých oblastí
ve společnosti relevantní.
7) Dokumentace. Máme-li budovat důvěru ve výstupy manažerského informačního systému
(dále jen MISu), je třeba přesně a srozumitelně
popsat význam jednotlivých údajů a jejich vazby. Není nic horšího než situace, kdy různá oddělení pracují s parametrem stejného názvu,
ale jeho interpretace a použití se v odděleních
liší. Pozor, to není úkol primárně pro IT, ale pro
ty, kteří s daty pracují na business úrovni.
Zkusme si uvést několik základních zásad budování čistých IS.
8) Péče o kvalitu dat se musí stát součástí podnikové kultury. Podstatným problémem totiž
je to, že lidé potřebná data do systému nezadávají, že nastavují atributy ledabyle, nesprávně atd. Z takových dat pak kvalitní reporty udělat nelze. Zkuste se podívat do svých databází,
co vše se nalézá v různých atributech záznamů,
udělejte si statistiky, jak často jsou nepovinné atributy nevyplněny. Udělejte si revizi toho,
které atributy jsou povinně vyplňovány a jaké
spektrum hodnot se v nich vyskytuje.
1) Centralizujme vše, co lze.
2) Minimalizujme počet různých aplikací.
3)Definujme systém sdílených registrů a číselníků a jasně definujme zodpovědnost za jejich
9) Efektivní a uživatelsky příjemné rozhraní.
Usnadněme lidem práci, umožněme jim, aby
potřebné údaje zadali do systému co nejsnáze.
To snižuje chybovost, snižuje odpor lidí k růz-
Chceme-li nad nečistým provozním IS vybudovat smysluplný reporting a MIS, není to jednoduché a ani levné. Vyžaduje to hodně úsilí, investic
do software, do datových pump a stejně některé
požadavky prostě řešit nelze.
10 zásad budování čistých IS
ným evidencím a zvyšuje jejich produktivitu.
Údaje, které lze získat automaticky, získávejte automaticky.
10)S daty je třeba kontinuálně pracovat
na všech úrovních organizace. Je třeba
ve společnosti vytvořit kulturu, kdy pracovníci na všech úrovních mají k dispozici přehledně prezentovaná data o tom, co dělají, co potřebují k tomu, aby zlepšovali a řídili své činnosti.
V tomto případě je jakákoliv podstatná nekonzistence dat odhalena tím pracovníkem, který
má k dané problematice, danému procesu bezprostřední vztah. Jakmile je odhalena, je zjednána náprava, protože všichni vědí, že kvalita
řízení a rozhodování ve společnosti je závislá
na tom, aby všichni pracovali se správnými daty.
Shrneme-li výše uvedený text, pak můžeme použít hesla:
„Při návrhu IS vycházíme od požadavků na řízení firmy a jejích procesů.“
témy jsou správně navrženy a sbírají relevantní,
konzistentní a smysluplná data;
„Lepší než čistit data, je zajistit, aby čistá již vstupovala a nekazila se.“
• nejen nástroj pro analýzu chování organizace
a lidí, kteří ji tvoří, ale i vlivů okolí;
„Reporty musí být přehledné a srozumitelné, všemi
chápany stejně.“
• jistou kulturu komunikace uvnitř organizace, rozhodování na základě věcných a správných podkladů, sdílené hodnoty a cíle.
„Kvalitní uživatelské rozhraní a vysoká míra automatizace zlepší přístup koncového uživatele k používání IS.“
Kultura organizace musí podporovat vědomí, že
aktuální a správné informace jsou naší konkurenční výhodou.
Na závěr bych rád ještě přidal poznámku.
Kvalitní MIS to není jen reporting.
PS. S tím stavěním čistého systému vám samozřejmě pomůžeme.
Petr Kučera
Kvalitní MIS znamená:
• kvalitní data ve společnosti, tj. primární IT sys-
3 PILÍŘE STRATEGIE TESTOVÁNÍ
Aby testování na projektu mohlo efektivně a smysluplně fungovat, je v prvé řadě nutné nastavit
na projektu a v organizaci testování jasná pravidla.
Tento článek se chce zabývat jedním z nutných kroků tohoto procesu – rozhodnutím vedoucího testování, CO a JAK vlastně testovat. Tedy jak vytvořit
základní strategii testování a o co se při tom opřít.
Postupy a koncepty, o kterých se zde dočtete, vycházejí z více než desetileté praxe na zakázkových
projektech, vedených „klasickými“ metodikami
a s určitými úpravami mohou fungovat také v metodikách agilních. Vycházím z předpokladu, že projekt používá uživatelské požadavky, od kterých se
odvíjí vývoj i testování, a tým složený z analytiků,
vývojářů a testerů.
Vytvořit bez přípravy nějakou funkční strategii
může být někdy stejně náročné jako sníst slona.
Z příruček samozřejmě „víme“, že se na to má jít
systémem „kousek po kousku“ – to je dobrá rada
na začátek, ale jako všechny obecné rady má své
nedostatky. Ukrajovat plátek po plátku, nebo ho
rozdělit na hromadu malých kousků a pak se v nich
snažit vyznat?
Což ale nejdříve slona obejít, zjistit, které části se
vlastně jíst nemusí, uvědomit si, jak ho nahrubo naporcovat a porozhlédnout se, jestli někde v okolí
nezahálí gril? Chce to trochu práce, ale pak se najednou ta příšerná hromada sloního masa změní
v lednici plnou stejků na prvotřídní plážovou párty. Jak tedy na to?
3 pilíře strategie testování
Otázka správného zaměření testování úzce souvisí
s požadavky a potřebami – jak zákazníků, tak projektového manažera. Vedení projektu klade na testování často protichůdné nároky (otestujte vše,
rychle, levně a kvalitně) a je třeba najít řešení.
Tím řešením je systematický, řízený přístup a soustředění se jen na to podstatné. V zásadě půjde
o nalezení odpovědí na tři základní otázky:
• Jak je to důležité?
• Z jaké perspektivy se dívat?
• Kdy a jak to provede (otestuje)?
Jak je to důležité? (severity, závažnost,
důležitost)
Jen pro pořádek – závažnost je něco jiného než priorita. Priorita je časové hledisko, které určuje pořadí
vykonávání činností (vzhledem k důležitosti i naléhavosti). V praxi se tyto pojmy často zaměňují nebo
splývají, v tomto konceptu je však nezbytné je od-
3
dělovat. Priority využije tým při přípravě a provádění testů, strategie pracuje jen s důležitostí.
Jde o první a nejdůležitější rozhodnutí, které ovlivní celý proces vývoje a testování. Snad každá manažerská příručka obsahuje nějakou formu tohoto
rozhodnutí – ať už jako Paretovo pravidlo 80:20, dělení do kvadrantů Naléhavé/Důležité nebo chirurgickou techniku „triage“.
Asi se shodneme, že u auta je důležitější, že fungují brzdy než to, že na zadním sedadle jsou nakřivo
švy. Stejně tak i požadavky na vyvíjenou aplikaci
mají různou „váhu“, jejíž vliv na kvalitu můžeme vyjádřit konceptem CTQ-GEQ-WQ.
CTQ znamená Critical To Quality – tedy kriticky
důležité. Pokud je požadavek, vlastnost nebo část
produktu kritická pro kvalitu, znamená to, že přímo
souvisí se základním smyslem tohoto výrobku, služby anebo software.
Pokud nebude splněn nebo bude vykazovat chyby, bude hotové dílo nepoužitelné, stejně jako auto
bez brzd, židle bez sedáku nebo sklenice beze dna.
Požadavky CTQ je naprosto nezbytné identifikovat
a po celou dobu vývoje se k nim chovat jako k VIP najít je, pochopit, jasně a jednoznačně popsat, dobře implementovat a pečlivě ověřit. Tady je nutné
udělat to nejlepší, co dokážeme – i za cenu toho, že
ubereme někde jinde. Pokud je nutné slevovat z nároků, zkracovat termíny a vynechávat testy, tato oblast je naprosté tabu – zde jde o „život“ a není místo pro šetření.
brání užívání, ale mohou mít velký negativní dopad na spokojenost zákazníků. Pozornost a pečlivost věnovaná testování těchto požadavků záleží
na mnoha faktorech. Jedním z nich může být verze
aplikace – v prvních verzích, kdy „skládáme motor“
jsou většinou nepodstatné a můžeme je s klidným
svědomím ponechat neotestované, před vlastním
definitivním dodáním může být jejich spolehlivě
ověřená funkčnost klíčová pro úspěch produktu.
Víme tedy, jak dělit podle závažností, ale jak poznat,
jak je který konkrétní požadavek pro zákazníka závažný? Mohou testeři vědět, co vše je pro zákazníka
podstatné? Bohužel, většinou nemohou. Jejich práce je ověřovat správnost aplikace, ale nejsou a ani
nemají být odborníci v byznysu zákazníka. Proto
nastupuje důležitý prostředník – analytik vývoje,
fungující jako most mezi zákazníkem a vývojovým
týmem. Jedním z jeho klíčových poslání je zjistit, co
přesně je pro zákazníka důležité a do jaké míry, převést tuto znalost do požadavků a předat informace
vývojářům a testerům.
Rady z praxe:
Pozor na dvě krajní situace – když se na projektu
koncept závažností vůbec nepoužívá, nebo jsou
naopak téměř všechny požadavky „maximálně důležité“. Výsledkem je změna testování v loterii, práce naslepo a manažerská provolání typu „vše je důležité, vše se musí dokonale otestovat, nesmí se nic
vynechat, musí se to zvládnout, jde přece o kvalitu a vy testeři jste za ni zodpovědní“ – a následující marný pokus testovacího týmu zvládnout nemožné.
Trik:
GEQ znamená Good Enough Quality, tedy dostatečnou kvalitu. Požadavky v této skupině spadají do kategorie „standard“ a tvoří většinu požadavků. Zákazník tady očekává běžnou kvalitu a nečeká
žádná překvapení.
Nesplnění a chyby jsou zde nepříjemné, ale nebrání základnímu provozu – jako příklad poslouží šálek s uraženým ouškem – uspokojí potřebu, ale nenadchne.
Testování těchto požadavků odpovídá normální
pozornosti a pečlivosti. Pokud je nutné z časových
důvodů některé testy z této oblasti vynechávat,
musí vedoucí počítat s riziky, která neotestování
způsobí a podle toho se odpovědně rozhodnout.
WQ znamená Welcomed Quality, tedy vítanou,
nadstandardní kvalitu, něco, co přinese příjemné
překvapení pro zákazníka. Tady je místo pro přidanou hodnotu, tady se vyrábí to, co přesvědčí zákazníka, aby si koupil právě tento výrobek. Nyní se pohybujeme v kategorii „ručně šitý potah na volant
z pravé kůže“.
Chyby a nedostatky v této kategorii rozhodně ne-
4
Transformace závažností požadavků na formalizaci testovacích případů
Koncept závažností požadavků a z nich vyplývající pozornost a péči, věnovanou příslušným testovacím případům, můžete dále použít několika způsoby. Jednou z možností je určení stupně formalizace
testovacích případů.
Formalizované testy podrobně popisují každý
krok, jdou na úroveň názvů polí, vepsaných hodnot
a stisknutých tlačítek. Jsou časově náročné na přípravu, opakovatelné a nejvíce průkazné. Jsou vhodné pro testování požadavků třídy CTQ.
Neformalizované testy stručně popisují testovanou činnost – fungují jako návody pro testery obeznámené s aplikací. Jsou rozumným kompromisem
mezi náročností přípravy, rychlostí a srozumitelností. Často se používají pro požadavky tříd GEQ
a WQ.
Badatelské (free) testy nepopisují nic – vytváří si
je tester průběžně při testování na základě zkušeností, typu a počtu nalezených chyb. Zkušení tes-
teři jejich pomocí mohou najít neobvyklé a nečekané chyby. Slabinou je malá opakovatelnost – každý
běh badatelského testu je originál. Používají se jako
doplňky pro otestování libovolných požadavků.
Z jaké perspektivy se dívat? (Dimenze
kvality, FURPS)
Většina netesterů si pod pojmem testování představuje pouze testování funkcionality, většinou
na úrovni nějakého „oklikání aplikace“, která potom
„dělá to, co se od ní čeká“. Testeři naproti tomu vědí,
že „dělat to, co se čeká“ je jen malá část toho, co aplikace skutečně dělá a hlavně toho, co nedělá, případně by ještě dělat měla.
Testovanou aplikaci je dobré pozorovat z několika
odlišných směrů: Funguje? Je dost rychlá? Je spolehlivá? Dá se udržovat? Pracuje se s ní intuitivně a snadno? Dělá to, co zákazník požadoval? Tyto
směry (známé i jako Dimenze kvality) tvoří koncept
FURPS (Functionality, Usability, Reliability, Performance a Supportability, tedy Funkcionalita, Použitelnost, Spolehlivost, Výkonnost a Podporovatelnost) a přidávají vám další hledisko, podle kterého
můžete porcovat našeho testovacího slona.
Ve většině případů se testování skutečně omezuje
na oblast Funkcionalit, dobrý vedoucí testování ale
určitě nezapomene probrat s vedoucím projektu,
které další dimenze kvality je vhodné testovat a kolik úsilí je na to možné věnovat.
Kdy a jak?
Poslední z principů je vypůjčený z metodiky RUP
a dal by se také nazvat „Ty pravé testy v ten pravý
čas“.
Vývoj SW se v mnohém podobá výrobě auta – nejdříve vyrobíte jednotlivé díly, ty složíte do dílčího
celku a ten se nakonec zakomponuje do celého výrobku. Díly a moduly musíte samozřejmě průběžně
kontrolovat – u hotového auta je už trochu pozdě
na zjištění, že jeden píst se jaksi „zatoulal“ a v motoru vůbec není.
V každé fázi výroby tedy potřebujete jiné testy, které se zaměřují na různé aspekty konečného výrobku – od jednotlivých šroubků, přes součinnost
komponent, až k celkovému smyslu a užitku pro zákazníky.
Stejná situace nastává i při vývoji software a ti z vás,
kteří se již setkali s metodikou RUP, případně s V-modelem, poznají rozdělení testů na fáze Unit, Integration, System a Akceptance.
Co v které fázi testovat? Záleží na konkrétním projektu. Zde uvedu jen několik typových příkladů:
• V UNIT testech je užitečné testovat validace polí,
ukládání položek do databáze, naplnění číselníků
a celkový design aplikace. Je velmi vhodné spolupracovat s vývojáři, kteří se ve svých unit testech mohou soustředit například na vyšší pokrytí kódu, ověření stavových automatů apod.
• V INTEGRACI se většinou testují průchody přes
případy použití (základní i alternativní), chybové
scénáře, datové varianty a celková aplikační logika. Jako bonus vzniká řada doporučení k ovládání, přehlednosti a intuitivnosti aplikace od prvních „opravdových uživatelů“ – testerů.
nou strukturou se na papíře špatně pracuje, proto
je ještě vhodné provést tuto sekvenci užitečných
triků:
3. Uvědomte si, že vlastně nepotřebujete tři tabulky a stačí jedna, sloučená. Nahraďte tedy
hodnoty „Ano“ hodnotami C, G a W (pro Critical,
Good enough a Welcomed). Ve sloučené tabulce
mohou být v jednom poli všechny tři hodnoty.
4. Pokud je to vhodné, přiřaďte k závažnostem zvolené stupně formalizace (Badatelské, Neformalizované a Formalizované) a přidejte poznámky.
1. Rozdělte „kostku“ do vrstev, čímž vzniknou tři
tabulky „FURPS × UISA“ pro požadavky nejvyšší, střední a nejnižší závažnosti.
2. Vyplňte příslušná pole, podle toho, které testy
budete provádět – zatím stačí vykřížkovat jako
tikety.
Výstup: Tabulka základní strategie manuálního testování
• V SYSTÉMOVÝCH testech ověřujeme napojení
a komunikaci s okolními systémy.
• V AKCEPTAČNICH testech je správný čas pro ověření byznys scénářů a prokázání toho, že aplikace
plní svůj účel.
Tento třetí „řez slonem“ vyžaduje dohodu s vedoucím projektu a vedoucím vývoje – jen od nich se dozvíte, jak bude projekt organizován, jaký model vývoje se použije a pro které fáze vývoje je potřeba
připravit testy. V této fázi je velmi užitečné společně vyhladit třecí plochy a nastavit vývoj a testování tak, aby spolupracovaly hladce, správně a účinně.
Sloučení tří pilířů do strategie
V předchozím textu jsme definovali tři roviny, podle
kterých slona naporcujeme a vznikne tak třírozměrná skládačka, složená z 60 dílků (3 stupně závažnosti × 5 dimenzí kvality × 4 fáze vývoje). S trojrozměr-
Legenda:
B – Badatelské manuální testy (Pro část GEQ a WQ), N – Neformalizované manuální testy (Pro GEQ a WQ),
F – Formalizované manuální testy (pro CTQ)
Unit
Integrační
Systémové
Akceptační
F
F
-
-
F
-
U
Validace – B
Design – N
F/N/B
dle závažností
Uživatelská
odolnost – B
R
-
-
-
-
P
-
-
-
-
S
-
-
-
-
Pomocí tohoto nebo podobného postupu je možné na většině fungujících projektů rozdělit problém testování na uchopitelné části, vybrat zvládnutelné množství potřebných oblastí a nastavit základní předpoklady k řízenému, systematickému a úspěšnému provedení dalších fází testování.
Pavel Hönigschmied
RETROSPEKTIVY – nic složitého
Co je retrospektiva? Retrospektiva je týmová schůzka, při které členové projektového týmu hodnotí
fungování a činnost svého týmu v uplynulém období. Snaží se identifikovat důležité události, úspěchy, ale hlavně problémy, se kterými se při své činnosti potýkají. Retrospektiva je zejména ve světě
agilního přístupu k vedení projektů považována za jednu z nejdůležitějších technik řízení týmu.
Agilní vedení projektů klade obecně velký důraz
na průběžné ověřování a zdokonalování. To platí
nejen z hlediska produktu, který vzniká a má být co
nejčastěji ověřován uživatelem či zákazníkem, zda
plní jeho potřeby, ale rovněž z pohledu neustálého
zvyšování kvality práce řešitelského týmu. Na rozdíl od klasického projektového řízení, které doporučuje zhodnocení a poučení se z projektu až v jeho
samém závěru, v moderním pojetí by měla takováto ohlednutí probíhat v pravidelných intervalech
v průběhu celého projektu. Cílem je, aby se zlepšení dala zavést ihned a nekončila v šuplících projektových manažerů. I vzhledem k tomu, že každý
projekt je unikátní (z pohledu řešeného problému,
implementačního prostředí, složení týmu atd.), je
přenositelnost zkušeností mezi projekty, o kterou
usiluje klasické projektové řízení, dosti omezená.
ložit s náměty ke změnám, které vzešly z předchozí retrospektivy.
1. Připomenutí předchozího období;
2. vyzdvihnutí toho, co se povedlo;
3. sběr námětů na zlepšení;
4. výběr prioritních témat k řešení;
5.závěr.
V návaznosti na předchozí krok, resp. jako jeho součást, je užitečné se zamyslet nad tím, co se týmu
za uplynulé období podařilo, jakého úspěchu dosáhl či z čeho měli členové týmu radost. Lze postupovat dokolečka, kdy každý řekne jednu pozitivní věc
týkající se týmu, jaká ho zrovna napadne. Toto společné hlasité deklarování třeba i drobných úspěchů
má smysl zejména v době, kdy se týmu na projektu příliš nedaří a většina členů týmu má evidentně
špatnou náladu kvůli množství existujících problémů, se kterými se musí potýkat.
V prvních pár minutách si tým stručně připomene, co se v posledním období na projektu událo
významného. Většinou s tím začíná vedoucí týmu,
ostatní doplní, na co si vzpomenou. Může být užitečné si na tabuli nakreslit časovou osu a na ni lepit
lístečky, které reprezentují důležité události. V této
fázi je rovněž vhodné zhodnotit, jak se podařilo na-
Třetí část retrospektivy, kdy se hledají náměty na zlepšení práce týmu, je časově nejnáročnější. Může být rozdělena do dvou kroků. V prvním
si každý individuálně rozmyslí, co nefunguje dobře, co by se mohlo zlepšit, dělat jinak či vůbec nedělat. Své nápady si zapisujeme na lístečky – každý námět na samostatný lísteček. Toto pohroužení
Jak může taková retrospektiva probíhat? Zkusím
stručně popsat metodu, kterou jsme již několikrát
použili na projektech. Základní osnova je následující:
5
se do vlastních myšlenek je časově omezeno na 5-7
minut. Následně se probírají jednotlivé zapsané náměty – autor stručně vysvětlí svou myšlenku, ostatní se mohou ptát, doplnit, diskutovat. Mohou nesouhlasit, nesmí to však být kritika autora za to, co
napsal. V této fázi je nadmíru důležitá role moderátora retrospektivy, který musí včas ukončit rozvláčnou diskuzi či dlouhé monology členů týmu. Tato
část retrospektivy by neměla přesáhnout 20-30 minut.
Po té, co byly náměty vysvětleny, může proběhnout výběr těch, které mají pro tým skutečný význam, a je vhodné se jimi dále zabývat. Lze to udělat zábavnou formou „dostihů“. Všechny lístečky
s náměty se vedle sebe nalepí ke spodnímu okraji tabule. Jednotliví členové týmu postupně přistupují k tabuli a dávají svůj hlas: posunou o jednu pozici výše lísteček, který považují za důležitý. Takto
se udělají 3 kola, tj. každý má tedy celkově 3 hlasy.
Náměty, které získaly nejvíce hlasů, je potřeba začít
řešit. O tom, kde se udělá oddělující čára mezi lístečky, které jsou hodné řešení a které lze pro nedostatek podpory zahodit, je vhodné se dohodnout
předem. Každému námětu je přidělen řešitel, který
se bude starat o to, aby daná věc byla zrealizována.
Na příští retrospektivě se pak zhodnotí, zda a jak se
podařilo problém řešit.
V poslední části retrospektivy je vhodné zjistit, jak
byli s jejím průběhem spokojeni účastníci a zda jim
něco důležitého přinesla. Trochu netradiční, ale
dle praxe dobře hodnocenou činností, může být
také závěrečné chválení. Buď formou zcela dobrovolnou, kdy každý může dle vlastních pocitů ocenit za cokoliv jiného člena týmu. Lze to však udělat
i tak, že jména všech se napíší na papírek a každý
si jeden náhodně vytáhne. Koho si takto vylosoval,
toho se pokusí za něco pochválit.
zené. Celková doba trvání závisí na tom, s jakou
frekvencí se retrospektivy dělají, nicméně obecně
lze u retrospektiv opakujících se po cca 1 měsíci doporučit jako časový limit 1 hodinu.
Retrospektiva, jako ostatně každá pracovní schůzka, musí mít svého moderátora. Typicky jím bývá
vedoucí týmu, ale může být pozván i externí moderátor, který s týmem standardně nepracuje. Jeho
úkolem je pouze dohlížet na správný průběh retrospektivy. Výhodou tohoto přístupu je, že vedoucí týmu by se v tu chvíli měl stát rovnocenným komunikačním partnerem pro ostatní členy týmu, což
může pomoci jak jemu, tak jeho kolegům.
Při opakovaných retrospektivách je vhodné občas
trochu pozměnit jejich průběh, aby byly pro účastníky zábavnější. Mnohá doporučení, jak vést retrospektivu a čím ji oživit, lze najít na internetu.
Na závěr ještě pár doporučení. Důležité je, aby celá
retrospektiva i její jednotlivé části byly časově ome-
Petr Sobotka
ZAJÍMAVÉ VLASTNOSTI PHP aneb OO v PHP 5 nejsou
dvě nuly
Shrnutí vývoje
Když PHP přišlo v roce 1995 na svět jako „Personal
Home Page Tools (PHP Tools)“ a následně PHP/FI,
tvůrcům webu přibyl nástroj pro vývoj dynamických stránek. PHP se ujalo a jeho další vývoj pokračoval relativně rychle – v hlavních (major) verzích
to byly 2.0.0 – 1996, 3.0.0 – 1998, 4.0.0 – 2000. Poté
se vývoj poněkud zpomalil a „mezníky“ ve vývoji se
staly „minor“ verze, např. 4.3.0 – 2002, 4.4.0 – 2005.
Poslední verzí PHP 4 bylo PHP 4.4.9 z roku 2008.
Paralelně s PHP 4 se vyvíjelo PHP 5, a to již od roku
2004. V roce 2010 byl ukončen vývoj minor verze 5.2 (5.2.15) a v roce 2011 vývoj minor verze 5.3
(5.3.6). Nyní se pracuje na vydání verze 5.4.0. Vývoj
verze PHP 6 byl před časem pozastaven. Tolik pro
základní orientaci.
Skriptovací jazyk PHP 2 a 3 umožnil vývojářům vytvářet rychle a relativně snadno server-side aplikace určené pro web. Programování probíhá procedurálně. Teprve od roku 1998 byla syntaxe rozšířena
o objektový přístup, nicméně ten postrádal některé
základní vlastnosti objektového programování, například modifikátory přístupu, a tím byla jeho použitelnost z hlediska objektů diskutabilní. V PHP 4 se
situace nijak nezlepšila, teprve s příchodem PHP 5
se stav razantně změnil.
Vlastnosti
Když se řekne objektové programování (webových
aplikací), tak nás asi nejprve napadne Java, která se
stala standardem. A tak, když dále mluvíme o PHP,
6
začneme tyto dva nástroje srovnávat a hodnotit,
který z nich je lepší, výkonnější, bezpečnější a „víc
košer“. Tím se ovšem dostaneme prakticky pokaždé
do slepé uličky. V PHP objektový přístup NENÍ totéž,
co objektový přístup v Javě. PHP je například typově volný jazyk – není nutné deklarovat typ proměnné. To na jednu stranu nevyvolá chyby při přepsání
např. čísla řetězcem, na druhou stranu není potřeba
přetypovávat datum. Funkce akceptují proměnný
počet parametrů, ale nelze využít přetěžování metod. Každopádně pro běh OO PHP aplikace je potřeba alespoň malý kousek procedurálního kódu:
#index.php
<?php
require _ once _ _ DIR _ _ .“../
class/myObject.class.php“;
$start = new myObject();
?>
Takže se programátor PHP bez objektů obejde?
Knihovny rozšíření – příklady
Neobejde!
PHP skripty mohou využívat, a také využívají, celou
řadu knihoven a rozšíření, které dovolují programátorovi vyřešit téměř každou úlohu. Například:
• SPL – Standard PHP Library – kolekce rozhraní
a tříd řešící standardní úlohy – práce se seznamy,
iterace, ošetření výjimek, autoload tříd apod.;
• Práce s databázemi
- MySQLi – MySQL Improved Extension, rozšíře-
ní pro práci s MySQL,
- PDO – PHP Data Objects Extension, abstraktní
vrstva pro práci s databázemi,
- SQLite3 – rozšíření pro práci s SQLite, verze 3,
- NotORM – knihovna používající rozšíření PDO,
ve stylu SimpleXML;
• Práce s XML
- rozšíření SimpleXML,
- rozšíření XMLReader – XML Pull parser,
- rozšíření XMLWriter – zapojuje libxml
xmlWriter API,
- rozšíření XSL,
- rozšíření DOM;
• Web services
- rozšíření SOAP slouží k vytvoření SOAP klientů
i serverů.
Současná verze jazyka dovoluje manipulovat s http
požadavky, vytvářet, modifikovat a zpracovávat
obrázky, generovat dokumenty (text, pdf, openDocument), využívat kryptování DES, MD5, Blowfish,
SHA256, SHA512, pracovat s knihovnou OpenSSL
a používat rozšíření PEAR a PECL.
Velká část těchto knihoven a rozšíření neumožňuje
jiný přístup než prostřednictvím objektového programování.
Frameworky
Přirozeným završením vývoje v PHP je vytvoření,
používání a rozvoj frameworků pro práci v tom-
to prostředí. Některé z nich jsou s PHP svázány již
dlouhou dobu (např. ZEND), další jsou vybudovány až pro současné verze PHP, např. Nette pro PHP
5.3.3. Vývojář si může vybrat z celé škály, například:
• CakePHP,
• Nette,
• Symfony,
• Yii,
• Zend,
atd.
Error Reporting), řeší nedostatky objektového modelu PHP zavedením omezení a kontrol, které samotný jazyk neobsahuje.
Frameworky svým způsobem řeší „nedostatky“
a doplňují funkčnost samotného PHP – poskytují
MVC, respektive MVP architekturu, různé šablonovací systémy (Smarty, Latte), nabízejí řešení typických úloh (práce s databázovou vrstvou, autentizace, Ajax, SEO), řeší cachování a výjimky (Exceptions,
Závěrem
PHP není jen triviální skriptovací jazyk pro „lamy“,
zatímco „guru“ používají výhradně Javu anebo .Net. Díky svému uspořádání (skript je zpracován interpreterem na serveru a výstup předán http
serveru, anebo je zpracován v prostředí příkazového řádku) a podporou v různých operačních systémech je možné jednoduše a relativně snadno vytvořit funkční prostředí pro běh aplikací.
Navíc rozvoj samotného jazyka, knihoven a rozšíření dovoluje řešit čím dál složitější úlohy. Objektový
přístup (zapouzdření, dědičnost, polymorfismus)
poskytuje vyšší efektivitu programování.
Navíc široká komunita vývojářů poskytuje rozvoji
PHP velkou dynamičnost.
Pavel Körner
NOVINKY V APLIKACI SONEF
Pokud jste se ještě nesetkali s aplikací SONEF, která
slouží ke schvalování dokumentů, myslím, že tento
fakt pro vás nebude při čtení tohoto článku handicapem. Aplikace doznala od poslední verze mnoho
změn, se kterými bychom vás chtěli blíže seznámit,
a to nejen v části grafického rozhraní, ale i v rozsahu poskytovaných funkcí. Prostor určitě dáme
také nejbližšímu výhledu rozvoje tohoto produktu
a dotkneme se i jeho směřování v delším horizontu v návaznosti na stále více zmiňovanou technologii Cloudu.
SONEF – schvalovadlo
Aplikace SONEF je v naší společnosti užívána již
řádu let. Pro ty, kteří tuto aplikaci neznají, jde koncepčně o schvalovadlo čehokoli – v našem případě smluv, nabídek, zadávací dokumentace, směrnic
a také v poslední době dokumentů pro marketing.
Z pestré nabídky typů dokumentů je patrné, že se
může jednat jak o jednoduché, tak složitější dokumenty, jejichž schvalovací proces se řídí různými
pravidly.
Základním principem schvalovadla je, že ten, kdo
dává dokument ke schválení, ho spolu s dalšími informacemi a pokyny ke schválení do procesu schvalování vystaví a dále definuje, kdo je povinným schvalovatelem. Další schvalovatelé nebo
osoby, kterým bude tento dokument zpřístupněn,
jsou nagenerováni automaticky, na základě pravidel – jako např. vedoucí odboru, kterého se dokument týká, je generován automaticky. V závislosti
na ceně a míře rizik jsou generováni členové vedení
nebo dozorčí rady atd.
Zásadní změna v principu schvalovala nastala až v nedávné době, kdy se připravoval proces
ke schválení interní spotřeby zboží pro jednoho
zákazníka. Tento proces nevyžaduje až na výjimky
žádný dokument. Pokud si jej v kostce přiblížíme,
jedná se o vyplňování formuláře žádosti o pořízení určitého typu zboží žadatelem. Do procesu dále
vstupuje svojí úpravou nákupčí, který doplní pro
něj stanovená povinná pole, jako jsou cena objednávky a dodavatel. Žádost uloží a systém zabezpečí
přiřazení dalšího schvalovatele (nadřízeného žadatele). Ten může žádost schválit, nebo ji zamítnout.
Po zadání kladného stanoviska (demonstrujeme si
jenom tuto větev procesu schvalování) je žádost
zaslána ke konečnému schválení poslední definované roli, vstupující do tohoto procesu, a to finančnímu řediteli. Jak je vidět z popisu (pro přehlednost
jenom v základních rysech), vše se odehrává bez
přiložení dokumentu k schválení a navíc v jednom
formuláři, ve kterém jsou pro jednotlivé aktéry procesu postupně zpřístupňována/znepřístupňována
jednotlivá pole. Jak vypadá takovýto formulář máte
množnost vidět na přiloženém obrázku.
jiné úlohy a samozřejmě jej lze kombinovat i s dokumenty.
Další změny se týkají ovládání, automatických přesunů uzavřených dokumentů nebo dokumentů
na vědomí z hlavní nástěnky do archivu po uplynutí uživatelem nastavené doby nebo třeba synchronizace uživatelů s Active Directory.
Co připravujeme do budoucna?
Budoucnost lze rozdělit na tu bližší a tu vzdálenější. V době, kdy budete tento článek číst, již ta bližší bude realitou.
V současnosti realizujeme některé další procesy,
jako je žádanka nebo referátník. Přidáváme nové
funkce tak, aby nástroj sloužil nejen ke schvalování dokumentů, ale také podporoval již proces jejich
vytváření. Do značné míry je rozsah implementovaných funkcí podřízen potřebám stávajících zákazníků a zájemců o toto řešení.
SONEF – software jako služba
Obrázek 1: Interní spotřeba
Tímto jsme funkčnost SONEFu rozšířili o formulář,
který se v čase mění, a v každém kroku se mohou
objevovat jiná pole. Vzhledem k tomu, že SONEF je
„stavebnice“, je tento typ formuláře k dispozici i pro
V delším horizontu nás však čeká zásadní rozhodnutí – zdali přejít na způsob poskytování tohoto software jako službu
(SaaS). Jedná se o řešení bezpečné, spolehlivé a také cenově dostupné. Jedinou
podmínkou je přístup k internetu. Můžete namítnout, že česká společnost je v současné době ve vztahu k držení vlastních
dat hodně konzervativní. Někteří poskytovatelé však mají vyřešené zabezpečení dat
na serverech mnohem lépe než zákazníci samotní
a dle mého názoru je jen otázkou času, kdy si zákazníci na to, že nemají data ve svém objektu, zvyknou.
Budeme-li vycházet ze známých, limitujících, faktorů SaaS řešení, jako je například možnost plné cus-
7
tomizace zákazníkem, tak ta již v SONEFu existuje.
Limitujícím faktorem tedy prozatím zůstává implementace propojení s ostatními aplikacemi provozovanými u zákazníka, což bude třeba do budoucna vyřešit.
Závěrem lze říci, že tento způsob řešení schvalovacích procesů je možno implementovat v řádu několika týdnů. Vzhledem k tomu, že řešení je postaveno
na bázi stavebnice, zákazník není odkázán na dodavatele v případech, kdy například potřebuje změnit
vzhled aplikace či workflow schvalovacích procesů.
Vše může provést jeho vlastní zaškolený pracovník.
Ten může sám implementovat i další procesy. Dokonalé samoobsluhy lze dosáhnout poskytnutím
SONEFu v Cloudu.
Martin Janček
KOVÁŘOVA KOBYLA
Jednou z produktových oblastí, na kterou se společnost KOMIX specializuje, jsou systémy pro Business Intelligence, tedy řešení pro komplexní korporátní reporting. V této oblasti již působí řadu let
a její portofolio za tu dobu zahrnovalo a zahrnuje
celou řadu produktů. Že je KOMIX v této oblasti již
zavedenou společností, dokládá mnoho referencí od zákazníků z veřejného i soukromého sektoru,
kterým jsme pomohli získat přehled o dění ve vlastním podniku a sjednotit interní reportingové procesy do transparentního systému s výstupy pro
všechny úrovně řízení.
Navzdory všemu výše zmíněnému se pro KOMIX
donedávna hodilo okřídlené přísloví o tzv. kovářově kobyle, která chodí bosa, protože firmě samotné
chybělo komplexní reportingové řešení. To se však
letos změnilo a tento článek se zabývá způsobem,
kterým k tomu došlo.
Prostředí interních informačních systémů v KOMIXu je velmi heterogenní. Firma používá pro řízení
jednotlivých segmentů, jako je účetnictví, projektový management nebo CRM, různý software a stejným způsobem probíhal i reporting. Při získávání
výstupů pro řídící pracovníky bylo nutné se spolehnout na často nedostatečné reportovací služby používaných transakčních systémů. Tyto výstupy jsou zpravidla tabulkové, neflexibilní a hlavně
se drží vlastní logiky, což ve výsledku vede k nejednoznačnosti terminologie v rámci celé firmy, k neporovnatelnosti jednotlivých výstupů, a tedy až
k více verzím firemního pojetí pravdy. Detailnější
a parametrizovatelnější reporty byly získávány ad-hoc na základě konkrétní potřeby přímými dotazy
do databází transakčních systémů, což pouze přispívalo k neprůhlednosti a nesystémovosti firemního reportingu.
Z těchto důvodů bylo rozhodnuto, že je nutné vybudovat reportovací řešení, které by odstranilo,
případně minimalizovalo všechny zmíněné problémy. Současně s tím bylo rozhodnuto, že projekt
bude realizován vlastními silami a pomocí nástroje QlikView. QlikView je business intelligence software firmy QlikTech, který naše firma distribuuje již
několik let a který si zákazníci vybírají kvůli rychlosti implementace, flexibilitě a intuitivnosti výstupů
a použití a především kvůli její samotné technolo-
8
gické platformě. QlikView totiž provádí všechny své
operace v paměti počítače, díky čemuž poskytuje
velmi krátké doby odezvy i při zpracování velkého
množství dat.
Cílem projektu bylo vybudovat datový sklad jako
soubor několika menších datových tržišť, které by
poskytovaly výstupy pro konkrétní oblasti podnikového řízení. V další fázi potom vyřešit bližší integraci jednotlivých tržišť do robustního datového skladu.
Projekt však téměř od prvních chvil narážel na tradiční problémy interních projektů. Alokace času
pracovníků na interní projekty má většinou až nejnižší prioritu, vztah řešitelů a zadavatelů je určen
organizační strukturou a zpravidla nejsou plně dodržovány standardní formální postupy pro řízení
projektu, jako je např. akceptační řízení.
Hned úvodní fáze celého projektu – zajištění dostupnosti a kvality primárních dat – byla jedna
z časově nejnáročnějších. Primární datové zdroje byly velmi heterogenní jak z hlediska umístění,
tak i druhu a klíčová znalost jejich struktury a obsahu byla často mimo firmu, což proces velmi prodloužilo. Proto bylo klíčové rozhodnutí, který údaj
bude použit jako vazební pro jednotlivá datová tržiště. Z důvodu nízké granularity, vyhovujícího formátu i jednoznačnosti bylo pro tento účel zvole-
no číslo projektu i přesto, že v některých případech
bylo nutné tomu přizpůsobit metodiku pořizování
záznamů v transakčních systémech. Především ale
projekty korespondují s firemní metodikou hodnocení výkonnosti. Číslo projektu je společné pro
všechny firemní systémy, ne všude však má stejnou
váhu.
Problémem souvisejícím s různorodostí firemních
systémů byla kvalita a dostupnost dat. Např. pro
účetnictví používá firma již dva roky systém Abra
G3, starší data jsou však v souborech původního
účetního systému, přičemž došlo i ke změně číselníků. Bylo tedy nutné zajistit správný formát těchto
souborů i sjednocení číselníků, aby nemohlo dojít
k desinterpretaci dat, kromě toho Abra G3 má silně nedostatečnou dokumentaci ohledně vlastních
datových struktur. Řešitelský tým navíc neustále
narážel na bezpečnostní bariéry plynoucí z faktu,
že v případě účetnictví jde o nahlížení do nejcitlivějších firemních dat a s tím související neochotou
managementu tato data zpřístupňovat. Z výše
zmíněných důvodů byla část konstrukce modelu
datového tržiště, transformačních operací a zejména testování správnosti výstupů časově velmi náročná.
KOMIX pro řízení projektů Business Intelligence používá metodiku, která klade velký důraz na úvodní
analytickou fázi, kde jsou definovány všechny cíle,
Obrázek 1: Trendové křivky
mezistupně řešení, dimenze a fakta a často až velmi
detailně obsah jednotlivých výstupních sestav. Je
to z důvodu optimalizace datového skladu – vytvoření takové architektury datového skladu, která by
zamezila redundanci dat, optimalizovala jeho rychlost a byla transparentní a flexibilní. Pro tuto fázi je
potřebná důkladná spolupráce se zákazníkem, protože přestože zde není žádný „hmatatelný“ výsledek, správné a co nejúplnější zadání je pro úspěch
projektu klíčové. Je nutné přiznat, že v případě našeho interního projektu se nám tento krok ne zcela
vydařil. Během úvodních fází nebylo úplně zřejmé,
k jakému cílovému stavu z hlediska obsahu směřujeme, zadavatel zodpovědný za požadavky nebyl z okruhu cílových uživatelů a požadavky často
nebyly formalizované. To později vyústilo k čas-
tým strukturálním změnám v architektuře datového skladu a prodloužilo trvání projektu a znesnadnilo testování výstupů.
Přes všechny zmíněné problémy, které provázely
řešení, se povedlo vytvořit sadu výstupů nad čtyřmi
datovými tržišti, které již v ostrém provozu používá
nejvyšší management firmy. V několika případech
došlo díky architektuře datového tržiště k velmi
podstatnému zpřehlednění struktury, ke sjednocení názvosloví a tím i zjednodušení a zrychlení celého procesu reportingu. Navíc se doba potřebná pro
provedení obnovy dat celého datového skladu pohybuje v řádu jednotek minut, takže na důležité firemní ukazatele lze nahlížet takřka v reálném čase.
Klíčové indikátory výkonnosti (KPI) se nemusí omezovat na statické reporty z jednotlivých transakčních systémů, díky provázanosti datových zdrojů
na nízké úrovni granularity je možné detailně srovnávat jednotlivé ukazatele a vytvářet trendové křivky, což zpřesňuje klíčová rozhodnutí.
Jedním z důležitých požadavků na řešení byla bezpečnost, tedy zabezpečení a konzistence dat v každém okamžiku. Prakticky je tento požadavek řešen automatickým šifrováním, které QlikView
poskytuje. V rámci dvoustupňového autentizační-
Obrázek 2: Přehledová řídící obrazovka
ho mechanismu je pak uživateli zpřístupněna pouze ta datová část, ke které má oprávnění. Např. pro
CRM je možné využít operativní reporting, kdy každý z obchodníků může zobrazit výsledky své, svých
zákazníků a podřízených ve stejné struktuře jako
jeho nadřízený.
V nejbližší budoucnosti je pak plánována bližší integrace jednotlivých tržišť, nahrazení některých standardizovaných reportů, např. pro banky, které jsou
zatím vytvářeny manuálně, automatickým zpracováním a výhledově i začlenění mzdového výkaznictví do datového skladu a umožnění detailního přiřazení nákladů procesům metodou Activity based
costing.
Tomáš Janošek
i pro controlling ve finančnictví?
Problematika datových skladů, manažerských informačních systémů (dále jen MIS) a business intelligence (dále jen BI) je v KOMIX s.r.o. řešena
od samých počátků existence firmy. Snažení v této
oblasti mělo několik milníků – nejprve se jednalo
o vlastní systém KOMIX DWH, poté v období 2001
až 2007 bylo nosným produktem prostředí Micro
Strategy firmy Insight Strategy a konečně počínaje
rokem 2007 se datují aktivity v prostředí QlikView
firmy QlikTech.
Od roku 2008, kdy se nosným produktem stalo prostředí QlikView, se situace v oblasti BI&MIS&DWH
zásadně změnila – veškeré stávající projekty byly
převedeny do prostředí QlikView a všechny nové
projekty již byly realizovány v tomto prostředí.
V období „před QlikView“ se jednalo téměř výhradně o nasazení v oblasti státní správy (ČSSZ, případně Generální ředitelství cel) a zdravotních pojišťoven (zejména ZPMV), s nástupem QlikView se
podařilo realizovat BI&MIS&DWH projekty pro oblast retailu, finančních institucí či výroby, a významně tak rozšířit portfolio zákazníků.
Proniknout do oblasti, ve které nebyly v minulosti realizovány žádné projekty, je poměrně obtížné
a ještě více toto tvrzení platí pro oblast controllingu. Oblast je kryta jak řadou etablovaných řešení,
tak doplňujícími řešeními v rámci provozních IS či
v prostředí MS Excel a podobně. Prosadit se v oblasti controllingu jsme se snažili od samého počátku práce v prostředí QlikView. Pro tento účel jsme si
připravili několik ukázkových aplikací – jejich předvedení se vždy setkalo s velmi kladnou odezvou,
avšak ke kýženému cíli to stále nevedlo.
První úspěch se podařil až v případě společnosti Global Payments. Pomohly nám zejména tyto
základní vlastnosti nabízeného řešení:
• vysoký uživatelský komfort koncového uživatele,
• načítání dat řízené metadaty v prostředí MS
Excel,
• snadné napojení na zdrojová data,
• snadná integrace různých datových zdrojů.
Vlastnosti nabízeného řešení byly prakticky předvedeny na ukázkové aplikaci. Vhodnou situaci jsme
našli i u zákazníka. Jeho stávající zpracování se potýkalo zejména s těmito nedostatky:
• komplikovaně udržovatelná sada řešení v prostředí MS Excel,
• obtížná kontrola a zavádění potřebných změn
a úprav,
• stávajícím řešením již obtížně zvládané objemy
dat,
• dlouhé doby odezvy na požadované výstupy.
Výsledkem bylo rozhodnutí zákazníka pro řešení
v prostředí QlikView, zakoupení příslušných licencí
a objednávka požadovaného řešení.
Návrh řešení byl zaměřen zejména na vyřešení následujících požadavků:
• co nejvyšší uživatelský komfort,
• rychlé doby odezvy i pro práci s velkými objemy
dat,
• snadné provádění potřebných změn klíčových
ukazatelů pracovníky zákazníka,
• prezentace aktuálních i historických dat,
• integrace dat z heterogenních datových zdrojů,
• rychlá aktualizace dat.
Výsledné řešení bylo vytvořeno na základě ukázkové aplikace v řádu jednotek dnů, nasazení u zákazníka a uvedení do rutinního provozu pak bylo
v řádu jednotek hodin. Výsledné řešení pak přineslo zákazníkovi pokrytí všech zadaných požadavků. Výsledné řešení dosáhlo těchto základních parametrů:
• doby odezvy ihned či v řádu jednotek sekund,
• aktuální objem načtených účetních dat cca 3,5
milionů záznamů s pravidelnými přírůstky,
9
Koncový uživatel tak má k dispozici jak řešení pokrývající všechny definované požadavky, tak i nástroj pro libovolné analytické a další činnosti.
Celá aplikace je řízena ze strany uživatele snadno udržovatelnými řídícími daty, v našem případě
na přání zákazníka v prostředí MS Excel.
• přírůstkové načtení nových údajů v řádu desítek
sekund,
• kompletní načtení všech údajů včetně historických v řádu jednotek minut.
Koncový uživatel pracuje s aplikací zcela intuitivně,
pro zobrazení si může volit jakékoliv období a další údaje. Po zadání zvoleného období a vybraných/
všech dalších parametrů se prakticky ihned zobrazí
odpovídající informace.
Obrázek 4: Přehled tržeb po odborech a obdobích
Samozřejmostí je podpora zobrazení detailu i z grafické prezentace například takto
Obrázek 8: Definice klíčových ukazatelů
Obrázek 1: Základní zobrazení klíčových ukazatelů
Zadaný výběr lze kdykoliv zúžit či rozšířit, zde je
jako možný příklad volba konkrétního odboru.
Obrázek 5: Výběr detailu z grafické prezentace
a okamžité zobrazení vybraného detailu v grafické
prezentaci.
Samozřejmou součástí je vedle výše uvedených
zobrazení klíčových ukazatelů možnost zobrazení
detailních údajů.
Obrázek 6: Zobrazení vybraného detailu graficky
Detailní údaje jsou samozřejmě okamžitě k dispozici též v tabulkové podobě.
Obrázek 3: Detailní údaje
10
Na závěr rádi zmíníme velmi dobrou spolupráci se
zástupci zákazníka, která je pro realizaci projektů
tohoto typu nezbytnou podmínkou. Vynaložená
snaha se zúročila ve spokojenosti zákazníka s dodaným řešením.
Zásadní přínos na straně KOMIX s.r.o. z takto realizované první aplikace z oblasti controllingu se projevil v nasazení tohoto typu aplikace i u dalších
zákazníků, jak z oblasti finančnictví, tak nově i z výrobní oblasti.
Pavel Seibert
Obrázek 2: Upřesněné zobrazení klíčových ukazatelů
Vedle tabulkového zobrazení je nad celým souborem samozřejmě podporováno také grafické zobrazení libovolných klíčových ukazatelů.
V případě potřeby stačí do tabulky v prostředí MS
Excel doplnit či změnit definici požadovaného ukazatele a po reloadu dat je k dispozici v řádu jednotek minut správný výstup samozřejmě opět s plnou
výše naznačenou funkcionalitou.
Obrázek 7: Zobrazení vybraného detailu v tabulkové podobě
TALENTCARE aneb rychlý HR servis vytváří lepší prostředí
pro vaše zaměstnance
Proč si pořídit do společnosti aplikaci, která zefektivní komunikaci ve firmě a HR
procesy? Významně zjednodušíte agendu HR oddělení, získáte lepší přehled
o svých zaměstnancích a zapojíte je aktivně do rozvoje jejich kariéry.
v aplikaci tvoříte plány vzdělání, záznamy osobních
pohovorů, můžete je nominovat na kurzy a následně zjistit, jak je kdo absolvoval.
TalentCare uchovává všechny informace o zaměstnancích přehledně na jednom místě, čímž je zamezeno duplicitnímu vytváření dokumentů. Informace a data o talentech mohou být uchovávány
v nejrůznějších formátech, například v podobě textových souborů, fotek či audio a video nahrávek
ze školení. Vytvořením centrálního místa informací o zaměstnancích si usnadníte vyhledávání, můžete vytvářet libovolné reporty a tiskové sestavy.
Výraznou úsporu času také přináší možnost komunikovat a rozesílat e-mailové zprávy na jednotlivce
nebo vybrané skupiny přímo z prostředí aplikace.
Zajímavým rozšířením aplikace jsou integrované
testy třetích stran. Přímo v aplikaci tak můžete vidět výsledky testů a případně sledovat jejich změny v čase.
Automatizace nebo individualizace
Jistě se zamýšlíte nad tím, jak lze procesy založené
na osobním přístupu zautomatizovat, zda je to prospěšné a co to vlastně přinese? Koncept fungování
HR oddělení je v dnešní době aplikačně podpořen,
proto většina společností necítí potřebu inovovat
vybavení pro HR. Ve velké většině je na HR odděleních aplikací dokonce několik.
V jedné aplikaci zjistíte, kde kdo sedí, v druhé jaké
má vybavení, v třetí jaký má rozpočet na vzdělání a tak dále. Jedná se vždy o konkrétní informace,
chybí však komplexní pohled na zaměstnance.
Co je jeho hlavní výhodou?
TalentCare je pomocník nejen HR oddělení, ale celé
společnosti. Lidský kapitál představuje jeden z nejcennějších majetků společnosti. Aplikace TalentCare umožňuje vytvářet a efektivně spravovat firemní
databázi talentů, a to nejen stávajících zaměstnanců společnosti, ale také uchazečů o zaměstnání.
Pokud potřebujete rychle zjistit, kde je kdo na projektu či kdo v posledních třech měsících absolvoval prezentační školení, jste nuceni procházet další
aplikace nebo lokální evidence. Každý takový dotaz
pak zabere mnoho času a vynaložené úsilí se projeví na vytíženosti HR oddělení.
Kdo nebo co mi pomůže?
Posílit HR tým? Delegovat činnosti jinam? Změnit procesy? Zapojit všechny zaměstnance? Otázek
na toto téma je mnoho. Rozšíření týmu je vždy časově i finančně náročné. Delegovat činnosti se zdá
být snazší cestou, nicméně je třeba zajistit i kontrolu plnění, takže změnit proces. Zapojit všechny zaměstnance lze až po transformaci procesů a tak dále.
V této situaci je vynikajícím řešením právě aplikační podpora. Sjednotí a zjednoduší práci HR oddělení a urychlí komunikaci. V neposlední řadě vám tento přístup zajistí i další benefity pro práci HR. Jaké to
jsou a s čím vším vám TalentCare pomůže, si můžete podrobněji přečíst níže.
Proces 1: Pokrytí HR procesu aplikací TalentCare
TalentCare – vše na jednom místě
TalentCare umožňuje práci jak se skupinami zaměstnanců, tak s jednotlivci. Začněme třeba u náboru. Každý nový uchazeč má s sebou své certifikáty, CV a další důležité dokumenty. S TalentCare
vše uchováte. U stávajících zaměstnanců si přímo
Díky kvalitnímu Candidate Relation Managementu, který aplikace TalentCare poskytuje, mohou firmy ušetřit nemalé finanční prostředky, které jinak
každoročně vynakládají na vypisování stále nových
kol výběrových řízení.
Jakub Houska
Talent Care – v jednoduchosti je krása
TalentCare je multimediální webová aplikace, pro
efektivní podporu práce se zaměstnanci. Centralizuje pohled na ně a uchovává všechny potřebné dokumenty. Pokrývá kompletně celý HR proces
kromě mzdové agendy (aplikace byla záměrně oddělena od citlivých mzdových dat) – viz. proces 1.
TalentCare nemá nikdy dovolenou
Díky webovému rozhraní mají HR pracovníci možnost přistupovat ke své databázi téměř odkudkoliv a kdykoliv, včetně mobilního telefonu či tabletu.
11
MODELOVÁNÍ PROCESŮ A SLUŽEB
aneb ETL procesy v praxi
Vycházíme-li z předpokladu, že proces představuje zobecnění pohledu na činnosti, které vytvářejí zákazníkovi přidanou hodnotu, určitě budeme mít pravdu, že na
trhu existuje mnoho nástrojů, které modelování těchto činností podporují. Jistě
mi dáte za pravdu, že k tomu, aby bylo nutno vytvářet nástroje nové, by musel
existovat pádný důvod.
V následujícím textu bych rád popsal naše zkušenosti, ve kterých jsme se setkali s potřebou našeho dlouholetého zákazníka (Celní správa) nejenom
procesy modelovat, ale dát tomuto zákazníkovi k dispozici nástroj, kterým si tyto procesy bude
schopen nejenom zachytit, ale také udržovat a měnit. Standardním východiskem projektu bylo zachytit tok zpracování dat a dokumentů, se kterými
se v systému pracuje, a dosáhnout očekávaných výsledků na výstupech. Průběh požadovaného procesu tedy odpovídá standardnímu ETL (Extract, Transform, Load) procesu, který bylo potřeba podpořit
modelovacím nástrojem. Podíváme-li se z pohledu
technologického konceptu Microsoftu, na kterém
bylo nutno požadované řešení vytvořit, tak jsme
po krátkém váhání zvolili technologii WF (Windows
Workflow Foundation).
dávání dle stanovených kritérií. Samotné modelování příkazů se provádí skládáním grafických
prvků do základních programovacích konstrukcí,
jako jsou sekvence, podmínka a cyklus. Chování samotného příkazu se upravuje nastavením hodnot
parametrů (vlastností) prvku použitím literálů, výrazů a funkcí. Na následujícím obrázku je vidět náhled na základy modelování a jeho možnosti.
Obrázek 1: Základní možnosti modelování
Volbou vhodné technologie jak známo vyřešíte jenom jednu část problému. Zbývá již „jenom“ dané
řešení v této technologii připravit. Tato část by tedy
měla mít příznačný název „Hledání“, kde výstižnější název bych asi nenašel. Jedna strana mince je mít
technologii, která umí navržený proces provést,
a druhá strana mince je nemít kromě integrovaného vývojového prostředí nástroj, ve kterém by uživatel mohl celý proces nejlépe graficky vytvářet.
S takovou “drobností“ jsme však již dle stanoveného konceptu počítali. Potřeba integrovat návrháře
procesů do nástroje pro zákazníka přerostla v nutnost takového návrháře vytvořit.
Vytvořením grafického nástroje (návrháře), vycházejícího z možností komponentního modelu platformy .NET, a jeho integrací do systému, již bylo možné definovat komplexní příkazy, které příslušnou
operaci vykonají. Spuštění těchto operací lze provést buď ručně přímo z aplikace, nebo automaticky dle předem definovaného plánu. Spuštění (automatické nebo ruční) umožňuje standard zachycení
procesu v jednotném formátu XAML. Pro vytvoření
samotného návrháře jsme využili technologií společnosti Microsoft, jako jsou Windows Forms a Windows Workflow Foundation. Celý grafický návrh
datového toku je vytvořen jako samostatná komponenta, kterou Windows Forms hostují.
Tento formát je vhodný nejen pro opětovnou grafickou úpravu, ale také poskytuje možnosti vyhle-
12
Základními stavebními prvky grafického modelování v našem případě jsou:
• Aktivita – základní předdefinovaná dílčí operace
(např. „Přidat sloupec“), z níž se skládají komplexnější příkazy;
• Kompozice – komplexní, samostatně vykonavatelná operace vázaná na konkrétní číselník, sestavená z aktivit a případně dalších kompozic;
• Workflow – komplexní, samostatně vykonavatelná operace bez vazby na konkrétní číselník, sestavená z aktivit nebo kompozic.
Grafický návrhář pro prohlížení modelovaných příkazů není jediným náhledem, který uživatel vidí, ale
pro zpřehlednění je také k dispozici jeho textová reprezentace, viz následující obrázek.
Tato část pomáhá uživateli s orientací ve vytvořeném toku zpracování s možností přímé vazby mezi
grafickým návrhem a právě touto textovou reprezentací. Tato vazba je vhodná zejména v případě
složitějších procesů, kde uživateli vyhovuje čtení
textové reprezentace. Pokud vyžaduje její vyhledání v grafickém návrhu, postačí pouhé dvojité kliknutí na aktivitu v textové reprezentaci.
Grafické rozhraní představené v předchozí kapitole tvoří jenom jednu část celkového řešení procesů zpracování dat, který má ještě následující části:
Obrázek 2: Textová reprezentace
• Vstupní rozhraní – část systému, která zpracovává příchozí data ve formátu XML. Pro zpracování dat ze vstupního rozhraní jsou definována pravidla, která umožňují tato data zpracovávat. Toto
zpracování je možné nastavit také pro určený čas
s danou periodou opakování;
• Centrální systém – hlavní část systému, která
zodpovídá za samotnou realizaci funkčnosti a je
přístupná jak klientovi, tak externím systémům
(přes definované rozhraní centrálního systému);
• Výstupní rozhraní – část systému, která umožňuje vystavení dat pro odběratele.
Zpracování dat v takto navrženém systému je tedy
průtokové bez zbytečných prostojů, pokud uživatel nedefinuje jinak. Na data, která se vyskytnou
na vstupním rozhraní, se aplikuje pravidlo zpracování, dle kterého se v systému spustí přiřazený
tok, který provede předem specifikované operace,
a data jsou navrženými operacemi transformována na výstup. Tento datový tok (posloupnost navržených operací) a jeho publikace pro automatické
zpracování se navrhuje právě ve zmíněném návrháři. Návrhář umožňuje kromě navržení toku zpracování také jeho vyzkoušení a odladění na datech,
která si uživatel připravil, případně do vstupů tohoto toku zadal.
V této části je vhodné, abych se zmínil o bloku „Řízení zpracování“, podle kterého se zahájí zpracování toku dat (podle nastavených pravidel).
Funkce bloku „Řízení zpracování“ je následující: v bloku jsou uživatelem nastavené podmínky,
za kterých se mají začít zpracovávat určitá data.
Vstupem do tohoto bloku jsou:
• informace o existenci určitých dat ve vstupní
frontě,
• údaje časovače.
Uživatel může nad těmito vstupními údaji nastavit
různé kombinace podmínek, po jejichž splnění řídicí blok provede tyto úkony:
• Přenos a konverze vstupních dat (pokud byly zadány v podmínce) z datové fronty do SQL tabulek
na SQL server aplikace;
• Spuštění zadaných workflow, které zpracovávají
vstupní údaje.
V rámci definice pravidel je nutno definovat samotné úlohy (úloha je činnost, při které se za určitých
splněných podmínek spustí jedno, nebo více workflow za sebou).
Dále bych se ještě stručně zmínil o klientské aplikaci. Pro podporu práce s daty bylo zapotřebí integrovat funkčnosti, jako jsou například import, export,
komentář, modifikace, práce s proměnnými, porovnání tabulek, různé druhy převodů dat, odeslání e-mailu, relace, vytvoření tabulky a další, které vytvářejí společně se základními funkcemi, jako jsou
cyklus, seskupení, podmínka, komplexní nástroj
pro podporu modelování. Tyto aktivity jsou však jenom dílčí části celého systému, které v rámci mode-
lování mohou využít předdefinovaných funkcí. Tyto
funkce se rozdělují na:
• Textové funkce – pracují s textovými řetězci;
• Konverzní funkce – převádí datové typy hodnot;
• Matematické funkce – pracují s čísly;
• Funkce data a času – pracují s kalendářními daty
a časem;
• Ostatní – poskytují doplňkové operace s hodnotami nebo proměnnými.
Formát funkcí vychází z jazyka T-SQL. Funkce, které nebylo možné pomocí tohoto standardu naplnit,
jsme vytvořili ve formátu PowerShell. Právě v části funkcí PowerShell jsou zpřístupněné části z jazyka MS .NET. To, co uživatel v rámci vytváření toku
dat určitě ocení, je nejen možnost si celý tok zpracování vstupních dat graficky připravit, ale také to,
že každá z částí, kterou do tohoto toku vkládá, má
v sobě integrované validace. Ty uživatele upozorní
na chybu v zápisu výrazu nebo parametrů. Optimalizace při zápisu znovupoužitelných funkčních bloků sestavených z jednotlivých aktivit, případně celých kompozic, které se vzájemně mezi sebou dají
volat pomocí předávaných parametrů, dávají řešení bonus navíc, který uživatelé ocenili již od počátku práce se systémem. Správnost návrhu řešení
a vhodnost vybraných technologií se nám potvrdily hned při prvních testech v rámci automatického
zpracování dat. Systém bez problémů zpracovává
stovky megabyte dat denně, a to bez zbytečných
prostojů. Takto dostupný systém bylo již na začátku cílem vytvořit, proto bychom měli být spokojeni, ale jak se říká, stále je co zlepšovat.
Martin Janček
BUSINESS PROCESS MANAGEMENT V ACTIVITI
jako soubor poskytovaných komplexních služeb či
obecně jako Enterprise Service Bus.
se stačí pouze doplnit požadovanou funkcionalitu.
Prostřednictvím dodatečných atributů lze tak přímo z procesu adresovat například metody Spring
bean či definovat podmínky větvení ve standardizované JUEL (Java Unified Expression Language)
notaci. Kromě Javy jsou podporovány také skriptovací jazyky Groovy a Javascript. Activiti implicitně
neposkytuje žádné workflow patterny. Typové procesní úlohy je tedy potřeba rozkreslit pomocí standardně dostupných prvků BPMN.
Návrh procesu
Běh procesů
Pro modelování procesů se nejvíce používá standardizovaná BPMN notace. Zatímco verze 1.0 se zaměřuje pouze na grafickou reprezentaci jednotlivých
stavů, přechodů a dalších prvků procesního diagramu, verze 2.0 standardizuje také sémantiku procesu a předepisuje formát (XML). Tím je zajištěna nejen
přenositelnost do různých grafických a syntaktických nástrojů, ale též možnost tento předpis použít
pro interpretaci ve stavovém automatu.
Proces potřebuje ke svému běhu perzistentní datové úložiště. Persistentní vrstva uchovává kromě
samotné definice procesu, verze a dalších metadat
také informace o aktuálním stavu a kontextu (proměnné procesu, zda se jedná o subproces atd.). Zatímco definice procesu (metadata) zůstává v databázi staticky, runtime informace (o běžící instanci)
se neustále mění a po skončení jsou odstraněny
z databáze. Výhodou jsou malé nároky na úložný
prostor runtime tabulek, čímž se podstatně redukuje potřeba partitioningu, popř. jiného specifického řešení nárůstu objemu procesních dat. Malý objem dat je i jedním z předpokladů rychlé odezvy.
Případné kolizní stavy jsou řešeny optimistickým
zamykáním a jsou ohlášeny výjimkou ActivitiOptimisticLockingException.
Na podnikové či zákaznické procesy lze nahlížet různým způsobem. Pokud zůstaneme v rovině vývojářské, existuje v současné době celá řada nástrojů od open
source až po komplexní komerční produkty, které napomáhají tyto procesy automatizovat, spravovat, monitorovat, případně následně optimalizovat. Pojďme se
ve stručnosti podívat, jak se k managementu procesů postavil tým okolo projektu
Activiti.
Jemný úvod do Activiti BPM
Fyzicky je Activiti sada Java knihoven distribuovaná pod Apache licencí verze 2.0. Celý balík je samozřejmě komplexnější a obsahuje kromě dokumentace též zakládací skripty pro různé typy
databází (Oracle, PostgreSQL, MS SQL, atd.), sestavovací skripty a sadu podpůrných nástrojů, z nichž
stojí za zmínku např. procesní návrhář (Activiti Modeler) či modul pro vzdálený přístup přes REST API.
Všechny tyto a další podpůrné nástroje (Activiti
Cycle, Activiti Explorer, Activiti Probe) jsou dodávány v podobě webových modulů, a k běhu tedy stačí
prostý servlet kontejner (Tomcat, Jetty,…).
Každý proces lze chápat též jako orientovaný graf
se soustavou uzlů a přechodů. Hnacím motorem je
tedy stavový automat postavený nad knihovnou
PVM (Process Virtual Machine). Koncepční myšlenkou BPM je oddělit vrstvu služeb a business logiky
od řízení a koordinace volání.
Acitiviti toto oddělení umožňuje jak na úrovni aplikace, tak i na úrovni komplexního systému.
Na aplikační úrovni si lze pod servisní vrstvou představit třídy a metody, jejichž volání proces koordinuje. Vrstva interakce může pak představovat např.
webový modul (sadu formulářů). Na úrovni komplexního systému můžeme servisní vrstvu chápat
BPMN 2.0 notace vzhledem ke standardizaci je stále
v některých ohledech příliš univerzální, a tedy těžkopádná. Snaha týmu Activiti poskytnout vývojářům větší komfort je řešena sadou atributů přesně
definovaných a popsaných v XSD, kterými lze proces efektivně napojit na konkrétní implementace služeb, definovat podmínky větvení či skupiny
uživatelů pro řešení konkrétních úloh vyžadujících
interakci. Atributy mohou být dopsány k procesu ručně nebo s využitím pluginu do Eclipse, který ale k dokonalosti zatím pouze směřuje. Diagram
lze také vytvořit například v Activiti Modeleru nebo
v některém z volně dostupných editorů (Yaoqiang BPMN Editor). Po následném importu do Eclip-
13
Historie procesů je standardně evidována v tabulkách s prefixem ACT_HI. K dispozici jsou čtyři úrovně logování s různou citlivostí, včetně možnosti
bez historie. Přesto tyto úrovně někdy nemusí být
dostatečné. V případě specifických požadavků je
možné využít koncepci listenerů, které lze navěsit na různé uzly procesního diagramu a odchytávat do historie pouze události, které opravdu potřebujeme.
Přístup Activiti k databázové vrstvě zajišťuje perzistentní framework MyBatis. Veškeré SQL dotazy
jsou definovány v tzv. mapovacích souborech, a nejsou tedy dynamicky generovány. Výhodou je větší kontrola nad přístupem k datové vrstvě. Díky této
koncepci je v případě potřeby velmi snadné dotazy analyzovat, eventuelně optimalizovat. Snadné je
i přejmenování tabulek, které procesní engine využívá, což se může hodit v případě, že zákazník vyžaduje určité databázové standardy a jmenné konvence.
Samozřejmostí je podpora transakčního zpracování. Activiti pokračuje v provádění procesu tak
dlouho, dokud nedosáhne čekacího stavu. Teprve
v tomto momentě dochází k potvrzení všech před-
chozích změn a k aktualizaci kontextu – tedy k interakci s databází. Pokud nepoužíváme logování
historie, mezistavy se nezaznamenávají a běh aplikace je velice efektivní. V čekacích stavech proces
nespotřebovává žádné systémové zdroje. Při běhu
je spotřeba systémových prostředků závislá na velikosti kontextu (např. počtu proměnných atd.). Pokud aplikace využívá distribuované transakce, externě řízené aplikačním serverem, je zohlednění
tohoto stavu pro Activiti konfigurační záležitostí.
Vlastností téměř každého BPM nástroje je verzování procesů. Nejinak je tomu i v případě Activiti.
Po nahrání nové verze procesu jsou veškeré nové
instance startovány s novou verzí, pokud není řečeno jinak. Již aktivní procesy dobíhají podle verze staré.
Interakce s procesy
V průběhu procesu mohou být generovány další
dílčí požadavky a úkoly, které dále ovlivňují způsob
zpracování. Některé z těchto úkolů se neobejdou
bez ručního zásahu a vyžadují vstupní data. Pro uživatelské rozhraní může být využita téměř jakákoliv
technologie postavená na platformě Java – od tenkých po tlusté klienty. Obsah formulářů může být
buď statický nebo dynamicky generovaný přímo
z definice procesu s využitím Activiti API. V případě nativních aplikací lze interakci zajistit například
přes rozhraní webových služeb či klientsky nenáročné rozhraní REST.
Testování procesů
Vzhledem k tomu, že Activiti představuje jednoduše zabudovatelnou Java knihovnu, je psaní testů pro procesy stejně snadné jako psaní testů pro
zbytek aplikace. Podporovány jsou JUnit testy verze 3 (rozšíření o ActivitiTestCase) a 4 (anotace plus
ActivitiRule). Defaultně testy používají databázi H2
v in-memory režimu. Pro test tak není potřeba připravovat dedikované datové úložiště. Test se sám
postará o vytvoření schématu, nahrání a spuštění
procesu a následné uklizení.
Activiti se zatím jeví jako velice schopný nástroj.
Jeho tvůrci zužitkovali své bohaté zkušenosti z projektu jBPM a poskytli dostatečně flexibilní prostředek vhodný pro využití i v produkčních systémech.
Zdroje: http://www.activiti.org, http://www.bpmn.org/
Zdeněk Křepela
GENEZE OPEN-SOURCE ESB MIDDLEWARE
- infrastruktura pro novou generaci podnikových systémů
V dnešní podnikové infrastruktuře je systémová a aplikační integrace stále častěji
citlivým a kritickým tématem. Důkazem této skutečnosti je široká škála přístupů
zaměřených na řešení tohoto tématu. Pokud se začínáte zabývat aplikační a datovou integrací, je snadné se ztratit v moři zkratek, názorů a marketingových informací.
Rychlé pokroky v technologiích Enterprise Application Integration (dále EAI) často vedou ke spekulacím, co EAI je a co již není. V tomto příspěvku poskytneme snadno pochopitelný pohled na vývoj
EAI. Od stručné historie původu EAI přejdeme k tradiční „hub and spoke – broker“ architektuře a nakonec k současné agilní, distribuované, na standardech založené Enterprise Service Bus architektuře.
sloužící např. k zajištění logistiky, vztahů se zákazníky, informací o zaměstnancích, zpracování obchodní logiky apod. Tato modularizace je často žádoucí a přirozená.
Rozdělení úloh, zajišťujících chod organizace,
do většího počtu menších funkcí umožňuje snadnější implementaci nových technologií a rychlejší
adaptaci na měnící se obchodní potřeby.
Počátky EAI
Enterprise Application Integration, neboli EAI, existovala jako odborný termín přibližně od roku 2000,
ale hlavní problém, který se snaží řešit, tedy přístupy k zajištění interoperability mezi více různými
podnikovými systémy, je mnohem starší.
Architektura podniku se skládá z řady informačních
systémů a aplikací, které poskytují různé služby pro
každodenní chod společnosti. Organizace používají systémy, ať již vyvinuté interně či dodavatelsky,
14
Aby organizace získala výhody distribuovaného
modulárního systému, musí implementovat technologie, které řeší následující atributy architektury:
• Interoperabilita: různé komponenty infrastruktury mohou používat různé operační systémy,
datové formáty, jazyky, připojení přes standardní rozhraní;
• Integrace dat: má-li být modulární a distribuovaný systém funkční, je třeba uplatňovat standardní metody zacházení s toky dat mezi aplika-
cemi a systémy, zásadní je zajištění konzistence
databází;
• Robustnost, stabilita a škálovatelnost: protože integrační řešení jsou pojivem, které drží pohromadě modulární infrastrukturu, musí být robustní, stabilní a škálovatelná.
Když Point-to-point integrace není dost
dobrá
Před rozvojem EAI byly (a i nadále někdy jsou) problémy integrace do značné míry řešeny pomocí point-to-point propojení. V point-to-point integračním modelu je specifický konektor realizován pro
každý pár aplikací a systémů, které spolu komunikují. Tento konektor se zabývá všemi transformacemi dat a dalšími souvisejícími službami jako zasílání
zpráv, které se musí uskutečnit pouze mezi konkrétní dvojicí integrovaných komponent.
Při použití v malém, kdy je třeba integrovat jen dva
nebo tři systémy, může point-to-point model fungovat docela dobře a poskytuje snadné řešení šité
na míru potřebám infrastruktury. Nicméně po připojení dalších komponent do infrastruktury začne
počet point-to-point spojení exponenciálně růst.
Tři komponenty infrastruktury vyžadují k plné integraci pouze tři pont-to-point spoje. Pro srovnání, jen dvě komponenty navíc zvyšují tento počet na 10 konektorů. To se již blíží nezvládnutelné
úrovni složitosti, a jakmile infrastruktura zahrnuje
8 nebo 9 komponent systému, počet připojení se
blíží ke 30ti a point-to-point integrace už skutečně
není vhodné řešení.
Je třeba mít na mysli, že každý z těchto konektorů musí být samostatně vyvíjen a udržován v rámci
změnových řízení, změn škálovatelnosti apod. Nevhodnost point-to-point integrace pro komplexní
podnikové nasazení je zřejmá.
Přístup EAI k integraci
Aby nedocházelo k výše zmíněným složitostem při
integracích komplexní podnikové infrastruktury
s přístupem point-to-point, používá EAI k centralizaci a standardizaci postupů integrace různé modely middleware.
EAI systémy slučují do jednotného integračního řešení adaptéry pro připojení, datové transformátory pro převod dat do vhodného formátu pro konzumenta, zpracování směrování a další komponenty.
EAI opouští point-to-point připojení „na tvrdo“
(pozn.: distribuované sběrnice jako např. SOPERA
v jistém smyslu stále komunikují point-to-point).
Aplikace může odeslat zprávu bez znalosti umístění
konzumenta, požadavků na formát dat nebo dalšího využití zprávy – všechny tyto informace mohou
být řešeny implementací EAI. To umožňuje pružnější architekturu, kde nové díly budou přidány či odebrány dle potřeby změnou nastavení konfigurace
EAI. Je zjednodušen modulární vývoj, jedinou službu může používat více aplikací.
Mnoho moderních přístupů EAI také využívá možností, které nabízí centrální integrační mechanismus k další konsolidaci zpráv. Vedle integrace dat
může moderní EAI také zahrnovat funkce, jako je
správa sítí, security, akcelerátory a škálovatelnost.
Tradiční EAI
První EAI řešení na trhu vzaly ideu sjednocení integrace doslova a včlenily všechny funkce potřebné pro integraci do centrálního hub nazývaného broker.
přístup k informacím o toku zpráv mezi systémy,
mapování dat mezi složitými úlohami a směrování
mezi systémy a aplikacemi.
Výhody
Podobně jako všechny přístupy k integraci EAI, broker model umožňuje volné spojení mezi aplikacemi. To znamená, že aplikace jsou schopny komunikovat asynchronně, posílat zprávy a pokračovat
v práci, aniž by čekaly na odpověď od konzumenta a přesně věděly, jak se zpráva dostane ke konzumentovi, či dokonce kdo je konečným konzumentem. Tento přístup také umožňuje konfiguraci
všech integrací v centrální repository.
Implementace brokeru také poskytuje monitorovací a auditní nástroje, které umožňují uživatelům
Architektura sběrnice – nový přístup
k EAI
Ve snaze vyhnout se problémům způsobeným EAI
pomocí brokeru, objevil se nový model EAI – sběrnice. I když se v něm stále používá centrální směrování zpráv mezi systémy, sběrnice se snaží o snížení
funkčnosti umístěné v jedné komponentě, a to distribuováním některých integračních funkcí do samostatných komponent.
Nevýhody
Stejně jako jakýkoliv jiný centrální architektonický
model, broker se může stát místem selhání celé sítě.
Jelikož je broker zodpovědný za veškerou výměnu
aplikačních stavů a dat, musí přes něj projít všechny zprávy.
Při velkém zatížení se broker může se stát úzkým
místem zprostředkování zpráv. Jediné centrální
místo pro všechny zprávy dělá také problémy při
použití na velké geografické vzdálenosti.
Implementace broker modelu je poměrně „těžkotonážní“, jedná se o proprietární řešení od konkrétního dodavatele technologie. To může být někdy
problém, pokud integrační scénáře zahrnují produkty od několika dodavatelů, interně vyvinuté
systémy, nebo starší dodávky, které již nejsou podporovány.
Broker model
V tomto modelu centrální integrátor – nazvaný broker – sídlí ve středu pomyslné sítě a provádí veškeré
transformace zpráv, směrování i některé další interní aplikační funkce. Veškerá komunikace mezi aplikacemi prochází přes něj, což umožňuje synchronizovat data pro celou síť.
Tyto problémy byly umocněny tím, že broker model je citlivý z pohledu celkového selhání sítě. Studie uvádí, že až 70 procent počátečních integračních projektů se nezdařilo kvůli chybám na straně
brokeru.
ESB – další krok v EAI
Broker model EAI byl v některých společnostech
úspěšně implementován, ale naprostá většina integračních projektů s využitím tohoto modelu nakonec skončila nezdarem. Nedostatek závazných
standardů pro EAI architektury a skutečnost, že většina řešení byla proprietární, znamenaly, že EAI produkty byly drahé, složité a někdy nefungovaly, jak
měly.
Tyto komponenty mohou být seskupeny v různých
konfiguracích uložených v konfiguračních souborech. Poradí si tak s integračními scénáři efektivněji
a mohou být umístěny kdekoli v rámci infrastruktury, nebo mohou být duplikovány pro zajištění škálovatelnosti.
Vznik Enterprise Service Bus
V souvislosti s tím, jak se vyvíjel EAI na bázi sběrnice, byla identifikována a začleněna řada dalších
nezbytných funkcí: jako security, transaction processing, error handling a další. Spíše než tvrdé zakódování těchto funkcí do centrální integrační logiky, jak tomu bylo u modelu brokeru, architektura
sběrnice umožňuje tyto funkce připojit jako samostatné komponenty.
Konečným výsledkem je lehké integrační řešení
na míru s garantovanou spolehlivostí, které je plně
oddělené od aplikační vrstvy. Řešení může být navrženo a konfigurováno s minimálními dodatečnými úpravami kódu a bez úprav systémů, které musí
být integrovány.
Tato zdokonalená verze EAI modelu na bázi sběrnice nakonec vešla ve známost jako Enterprise Service Bus, neboli ESB.
15
Základní vlastnosti ESB
Na současném trhu existuje celá řada různých produktů ESB. Některé, jako například WebSphere Message Broker nebo TIBCO BusinessWorks, jsou tradiční broker EAI produkty, které byly přepracovány
do podoby nabízející novou ESB funkčnost, ale jsou
stále funkční v broker stylu.
Jiné ESB, jako například komunitní projekt JBoss
ESB ze SOA Platform či Mule ESB od MuleSoft, SOPERA, Open ESB, WSO2, Apache ServiceMix jsou navrženy od základu s použitím otevřených integračních standardů a implementují ESB model.
Přes rozdíly mezi nimi navzájem, většina ESB má
všechny nebo většinu z následujících základních
funkcí, neboli „služeb“:
• Transparentnost umístění: způsob, jak centrálně konfigurovat koncové body – konzument
zprávy nevyžaduje informace o přesném umístění producenta zprávy;
• Transformace a Protokol konverze: ESB musí
být schopen přijímat podobně jako transformaci požadavku i zprávy odeslané ve všech standardizovaných protokolech a převést je do formátu konečného konzumenta. Jedná se o konverzi
transportních protokolů. Tj. pokud jeden systém
komunikuje přes HTTP a druhý přes FTP, pak ESB
zajišťuje, že si oba systémy rozumí. Pokud některý konektor není out-of-the-box, mělo by být
možné jej alespoň doprogramovat;
• Směrování: schopnost určit správného konzumenta nebo konzumenty zprávy na základě
předdefinovaných pravidel a dynamicky definovaných požadavků;
• Vylepšení: schopnost odvodit chybějící data
v příchozí zprávě na základě stávající datové
zprávy a připojit je ke zprávě před odesláním
na místo konečného určení;
• Monitoring/ Správa: cílem ESB je integraci maximálně zjednodušit. ESB musí poskytovat snad-
16
ný způsob sledování výkonu systému, toku zpráv
přes ESB a jednoduché prostředky pro správu
systému;
• Bezpečnost: ESB pracuje se zprávami zabezpečeným způsobem a zajišťuje komunikaci bezpečnostním zajištěním každého ze systémů, které
jsou integrovány. ESB umožňuje u některých protokolů provádět autentizaci, autorizaci a šifrování zpráv, ale většinou je nutné to nastavit.
Výhody ESB
Zde je pohled na výhody, které nabízí ESB přístup
k aplikační integraci:
• Jednoduchost: jelikož se ESB skládá z mnoha
spolupracujících služeb, na rozdíl od brokeru,
který obsahuje všechny možné služby, může být
ESB jednoduchý či složitý, dle potřeb organizace.
Nabízí nejefektivnější integrační řešení;
• Snadná rozšiřitelnost: jestliže organizace plánuje, že bude potřebovat připojit v budoucnu
další aplikace a systémy, není třeba mít obavy,
zda je ESB umožní integrovat do stávající infrastruktury. Novou aplikaci, připravenou na komunikaci po ESB, stačí připojit ke sběrnici;
• Škálovatelnost a distribuovatelnost: na rozdíl
od brokeru může ESB snadno přenášet funkčnost
na geograficky distribuované sítě. Protože vlastnosti ESB jsou zajišťovány samostatnými komponentami, je mnohem jednodušší a nákladově
efektivní zajistit vysokou dostupnost a škálovatelnost kritických částí architektury;
• Přátelská SOA: ESB jsou budovány s představou Service Oriented Architecture. To znamená,
že organizace směřující k SOA to může učinit postupně. Může pokračovat v používání svých stávajících systémů a zároveň postupně zapojovat
znovupoužitelné služby tak, jak jsou postupně
realizovány;
• Inkrementální přijetí: na první pohled může
počet funkcí, které nabízí ESB, vypadat hrozivě.
Nicméně je nejlepší myslet na ESB jako na inte-
grační „platformu“, kde stačí použít komponenty, které splňují aktuální potřeby integrace. Velký
počet modulárních komponent nabízí flexibilitu,
která umožňuje postupné přijímání integrační
architektury a která zaručí, že aktuálně neočekávané potřeby bude možno v budoucnu řešit bez
dalších větších investicí.
Kdy použít ESB – fundované EAI rozhodnutí
Všechna integrační řešení mají silné a slabé stránky,
které jsou často závislé na prostředí, ve kterém jsou
nasazeny. Z tohoto důvodu je nutno dělat v konkrétních podmínkách kompetentní rozhodnutí
o strategii EAI.
K tomu, aby EAI a SOA úsilí bylo úspěšné, není třeba „nejlepší“ technologie. Jsou třeba reálná fakta
o použitých integračních scénářích – posouzení zátěže a současných i budoucích integračních cílů organizace.
Dříve než se rozhodnete o způsobu EAI, je důležité
mít dobrou představu o tom, jak byste odpověděli
na následující otázky:
• Kolik aplikací potřebujete integrovat?
• Budu muset připojit v budoucnu další aplikace?
• Kolik komunikačních protokolů budu potřebovat?
• Potřebují naše integrační požadavky směrování,
větvení a agregace?
• Jak důležitá je pro naši organizaci škálovatelnost?
• Vyžaduje integrace asynchronní zasílání zpráv,
publish/ consume zasílání zpráv nebo jiné komplexní multi-aplikační scénáře?
Martin Sláma
APLIKAČNÍ PORTÁL Oborové zdravotní pojišťovny
V roce 2009 se Oborová zdravotní pojišťovna (OZP), která patří k našim největším
a historicky nejstarším zákazníkům, rozhodla, že vybuduje svou novou internetovou prezentaci na moderním portálovém řešení. Jako nejvhodnější kandidát byl
vybrán produkt Oracle Portal 11g běžící na aplikačním serveru WebLogic.
Provozování a správa webových stránek je jen jedna z řady funkcí, které produkty typu podnikových
(enterprise) portálů nabízejí, a proto byla koncepce portálu již od počátku navržena tak, aby do něj
byly postupně integrovány jak stávající, tak nové
aplikace.
OZP, celým názvem Oborová zdravotní pojišťovna
zaměstnanců bank, pojišťoven a stavebnictví, z definice uchovává a pracuje s údaji, které souvisejí se
zdravotním stavem jejích klientů – pojištěnců. Jedná se tedy o velice citlivá data, na která se vztahuje zákonná ochrana. OZP navíc ctí profesní úroveň
zabezpečení, která je běžná v bankovním sektoru, a proto byla otázce bezpečného uložení a zpracování dat v portálu OZP věnována zvláštní pozornost.
Dosud byly do portálu OZP integrovány tyto naše
aplikace:
• Bezdlužnost osoby/organizace
Tzv. potvrzení o bezdlužnosti vydávané OZP je
potvrzení o tom, že osoba nebo organizace, pro
niž je potvrzení vydáno, nemá vůči OZP evidovány splatné nedoplatky na pojistném a penále
na veřejné zdravotní pojištění.
• Schránka klienta (ePodatelna)
V rámci této aplikace je klientům portálu dostupná historie jejich požadavků. Zařazené požadavky jsou uspořádány do přehledné tabulky. U každého požadavku je uveden jeho typ (například
Bezdlužnost), datum podání, stav realizace atd.
Požadavky je možné filtrovat podle času, typu
a stavu.
Popis řešení
Základem systému je tzv. Integrační platforma portálu (IPP), která zprostředkovává funkčnost vnitřních systémů pro potřeby jednotlivých aplikací. Integrační platforma poskytuje Java IPP API rozhraní
pro zadavatele i zpracovatele požadavků.
Každou definovanou funkčnost portálu realizuje
samostatná webová aplikace standardu JEE, která
prostřednictvím rozhraní IPP API vytváří požadavky
definovaných typů na vnitřní systémy OZP. Uživatelské rozhraní je standardizováno tak, aby všechny aplikace využívaly stejného vzhledu a funkčnosti definovaných prvků.
Kromě komunikačního rozhraní zajišťuje IPP ještě řadu dalších funkcí. Jedná se zejména o správu
front požadavků, kde umožňuje měnit jednotlivým
požadavkům prioritu, v rámci pravidel aplikační logiky přesun do jiné fronty, sledování průchodu požadavku (a jeho vyřešení) systémem pro potřeby
auditu a podobně. Každý požadavek si totiž s sebou
nese mnoho různých atributů, např. do jaké fronty
má být uložen, jakou má prioritu, zda má být auditován a kdo ho může z fronty vyzvednout.
Hlavním zpracovatelem konkrétních typů aplikačních požadavků je tzv. PIM (Portal Interface Manager), který je umístěn v interní síti OZP. PIM zapouzdřuje funkcionalitu provozních systémů IZOP
a WOIS a zajišťuje obsluhu interních komunikačních rozhraní. S ohledem na bezpečnostní omezení
komunikace mezi DMZ (demilitarizovanou zónou)
a interní sítí je to právě pouze PIM, kdo je iniciátorem komunikace s IPP (umístěné v DMZ), a který se
pomocí IPP API připojuje ke konkrétní frontě požadavků aplikací.
Po jejich zpracování je
výsledek opět PIMem
umístěn do příslušné fronty k vyzvednutí IPP. Tímto způsobem
je zaručena stabilita
interního systému CIS,
který si odebírá požadavky podle svého aktuálního vytížení.
Dalším stavebním kamenem systému je modul pro
jednotné přihlášení. Pro toto konkrétní řešení byl
vybrán produkt JOSSO, neboli Java Open Single
Sign-On. JOSSO tvoří tři základní komponenty:
• SSO Gateway – webová služba držící autentizační
token uživatele, která v procesu funguje jako brána mezi uživatelem a aplikací,
• SSO Agent – klientský software zprostředkující
komunikaci s bránou,
• Partner Application – cílová aplikace, která podporuje SSO systému JOSSO.
JOSSO v podstatě zajišťuje access management uživatelům, jejichž identity jsou uloženy v CISu a spravovány aplikací EID, tj. podle role uživatele umožňuje přístup k definované množině aplikací.
V databázi ASDB v DMZ se nacházejí pouze pravidelně aktualizované číselníky a dočasná data, která
souvisejí s právě prováděnými transakcemi uživatelů. Bezpečnost dat navíc zajišťuje tzv. ASO (Oracle
Advanced Security Option). ASO umožňuje zašifrování citlivých údajů, a to buď přímo v databázi, nebo i při dalším použití – zálohování, posílání
po síti apod.
Pro zvýšení bezpečnosti aktivních operací se používá jednorázová autentizační SMS jako tzv. one-time
password (OTP). Filozofie je podobná, jak je to běžné například při použití internetového bankovnictví. Identita uživatele se tímto způsobem ověřuje
pomocí dalšího distribučního kanálu (mobilního telefonu) a navíc lze tuto SMS vložit do systému pouze jednou, což i v případě teoretického „odposlechu“ SMS výrazně snižuje možnosti jejího zneužití.
Komix převzal Oracle Portal v OZP do správy po původním dodavateli. V rámci tohoto převzetí byla
nutná reinstalace celého systému a re-import
webového obsahu. Vzhledem k rozsáhlosti, komplikovanosti a hlavně mnoha různým nedokumentovaným proprietárním úpravám se během tohoto procesu vyskytla řada problémů, které se nám
i díky podpoře společnosti Oracle dařilo průběžně řešit.
Oracle Portal 11g je rozsáhlá platforma, která nabízí
široké možnosti dalšího rozvoje a rozšiřování portfolia aplikací. V budoucnu budou nepochybně následovat další kroky tímto směrem k přiblížení se
klientům a partnerům Oborové zdravotní pojišťovny, což v neposlední řadě přispívá i k posilování její
pozice na trhu zdravotní péče.
Jan Krejčí
Obrázek 1: Architektura aplikačního portálu OZP
17
IBM Infosphere Guardium
IBM Infosphere Guardium je podniková bezpečnostní platforma pro zajištění bezpečnosti a integrity citlivých dat uložených v databázích, ať už se jedná o čísla kreditních karet, zákaznické či jiné informace.
Tato platforma umožňuje v reálném čase účinně
bránit vaše datová centra proti neoprávněným či
podezřelým aktivitám, ať už ze strany případných
hackerů či ze strany koncových uživatelů aplikací
k vašim datum připojených. Jednou z konfiguračních možností je například i automatické odpojení detekovaného neoprávněného spojení s databází včetně lokálního přístupu. Řešení umožňuje
vyhledat bezpečnostní rizika ve vaší databázi stejně jako identifikovat a klasifikovat citlivá data umístěná uvnitř. Obrana je prováděna na základě jasně definovaných politik a pravidel s přihlédnutím
na separaci uživatelských rolí. Součástí řešení je automatizované workflow pro efektivní nápravu skutečností, které jsou v rozporu s požadavky bezpečnostních standardů.
Pro správu databází a aplikačních prostředí využívá jednoduché a intuitivní webové rozhraní umožňující spravovat většinu současných databázových
platforem (Oracle, SQL Server, Informix, DB2, z/OS,
Sybase a další) a aplikačních prostředí.
Toto řešení je zcela nezávislé na nativním databázovém auditu vašich databázových systémů a umožňuje integraci s existujícími systémy, ať už se jedná
o Directory Services (AD, LDAP,...), SNPM Dashboardy (HP OpenView, Tivoli,...), Change Ticketing systémy (Remedy, Peregrine,...), autentizační prvky
(RSA SecurID, Radius, Kerberos), dlouhodobá úložiště dat (IBM TSM, EMC Centera , FTP, SCP,...), aplikační servery (SAP, Siebel, Cognos, WebSphere, Oracle
EBS, PeopleSoft,...) a další.
Jeho výhodou je rovněž skutečnost, že nevyžaduje žádné změny v konfiguraci vašich databázových
systémů či aplikací a má minimální vliv na výkonnost databází (2-3 %). Umožňuje rovněž sledovat
100 % všech databázových operací, včetně lokálního přístupu, a součástí řešení je i automatický systém varování v reálném čase.
Auditní data jsou k dispozici za 3-6 měsíců s možností zabezpečené archivace. Auditní data jsou
efektivně ukládána a i po archivaci jsou stále dostupná. Rovněž je možné sledovat agregovaná
a korelovaná data z různých systémů v reálném
čase. Sítová komunikace je optimalizována filtrováním dat potřebných pouze pro audit.
Michal Břečka
CyberArk – bezpečné řešení?
Zabezpečit IT prostředí nebývá jednoduchý úkol. Produkty společnosti CyberArk
nabízí flexibilní nástroje, kterými lze IT prostředí efektivně zabezpečit a monitorovat.
Řešení CyberArk nabízí plnou kontrolu nad využíváním privilegovaných účtů. Umožňuje bezpečné
uložení dat šifrovanou cestou a jejich ochranu před
přístupem z internetu, a to i před neoprávněným
přístupem lokálních administrátorů. Nedílnou součástí je podrobné protokolování přístupu k privilegovaným účtům a chráněným datům.
Obrázek 1: Privileged Identity Management Suite
Statistiky ukazují, že privilegované účty spravovaného prostředí jsou často sdíleny vybranou skupinou administrátorů (např. z důvodu zastupitelnosti). Změna hesla není prováděna v doporučeném
intervalu a v některých případech není prováděna vůbec. Ze statistik vyplývá, jaký druh informací,
18
jejichž zneužití může poškodit zájmy společnosti,
velmi často odchází se zaměstnanci v případě personálních změn. Jedná se majoritně o přístupové
údaje spravovaného prostředí, před často zmiňovanou databází zákazníků. Produkty CyberArk nabízí několik možností, jak tyto stavy zcela eliminovat
a privilegované účty efektivně spravovat a monitorovat.
Primární komponentou řešení CyberArk je „Privileged Identity Management (PIM) Suite“, jejímž klíčovým modulem je „Enterprise Password Vault (EPV)“.
Jde o repozitory, která poskytuje kompletní správu entit, účtů a hesel. Umožňuje vytvářet „trezory“, do nichž jsou vkládány chráněné informace
spravovaných systémů, dokumenty a další objekty, které dle nastavené bezpečnostní politiky musí
být uchovány v odděleném prostředí s dedikovaným účtem. Navazující komponentou je „Password
Vault Web Access (PVWA)“ s volitelnou komponentou „Application Identity Manager (AIM)“. PVWA
poskytuje administrátorům rozhraní ke spravovaným serverům. PIM Suite umožňuje vytvářet politiky, kde lze konfigurovat interval pro automatickou změnu hesla a požadavky na složitost hesla
(minimální délku hesla, použití číslic, velkých písmen a speciálních znaků, omezení „jednoduchých
hesel“ – př.: kaktus1), dále lze vymezit dobu používání účtu atd. PIM Suite nabízí administrátorům zabezpečený přístup k serverům. Přístupové údaje
k nim vkládá do otevíraných SSH/RDP session, aniž
by je správce vzdáleného systému znal. PIM Suite
umožňuje automatickou změnu hesla vzdáleného
systému na základě politiky hesel, kterou můžeme
definovat v PVWA. Automatizuje tak procesy vy-
žadované bezpečnostní politikou a kontrolované
bezpečnostním auditem.
Chcete-li dále škálovat správu cílového serveru, lze
nasadit „On-demand Privileges Manager (OPM)“,
který poskytne vrstvu mezi administrátorem a prostředím CyberArk, čímž lze např. povolit/zakázat
příslušnému správci na UNIX systému spouštět vybrané příkazy, popř. si vynutit vyšší oprávnění pro
jejich provedení.
CyberArk lze nasadit i do prostředí, která jsou rozprostřena přes více lokalit. WAN linky, které často
bývají „úzkým místem“ v zajištění vysoké dostupnosti spojení s centrálou, neohrožují schopnost
spravovat infrastrukturu, protože aplikace na vzdálených lokalitách obsahují tzv. „Secure Cache“. Díky
této funkcionalitě není v případě výpadku WAN linky omezena spravovatelnost prostředí. Konfigurace pravidel a funkcionalit PIM Suite je velmi rozsáhlá. Nepřehlédnutelnou výhodou je možnost
konfigurace pravidel z jednoho rozhraní PVWA.
Řešením CyberArk „Privileged Session Management Suite“ lze kontrolovat sestavené session,
chránit kritické komponenty IT prostředí, analyzovat příčiny v chování systémů, zaznamenávat historii příkazů a operací prováděných v rámci sestavené privilegované session. V prostředí Microsoft
Windows lze povolit pořízení video záznamu ze sestavené RDP session.
Nosnou platformou PIM Suite je operační systém
Microsoft Windows Server. Řešení CyberArk lze integrovat s prostředím AIX, Windows, HP-UX, Linux,
Oracle, MS SQL, VMware a dalšími.
Miroslav Linda
19
INFORMIX WAREHOUSE ACCELERATOR
Jednou z novinek roku 2011 je rozšíření funkcionality databázového serveru Informix o prostředek
zlepšující výkonnost aplikací na bázi datových skladů. Jedná se o doplněk nejvyšší řady serverů
Informix (Ultimate Warehouse Edition), lze ho provozovat s verzí 11.70.xC2 a vyšší a je určen výhradně pro operační systém Linux na bázi procesorů Intel. Základní myšlenka je extrémní využití
dat komprimovaných v paměti a eliminace V/V diskových operací. Informix Warehouse Accelerator
(IWA) nevyžaduje manuální ladění výkonnosti, lze jej použít s již vytvořenými aplikacemi a existující databázovou strukturou. Nevyžaduje zásahy do indexových struktur ani nová fragmentační
schémata. Na obrázku 1. je zobrazena typická struktura datového skladu. Střední část schématu je
plně v režii databázového serveru a tuto část úlohy má v nové konfiguraci na starosti IWA.
Obrázek 3: Data Mart prodeje
Obrázek 1: Struktura datového skladu
Zapojení IWA předpokládá, že databázový server
Informix v požadované verzi (11.70.xC2) je nainstalován, nakonfigurován a spuštěn. V další fázi je instalován, konfigurován a spuštěn IWA. Součástí IWA
je Smart Analytics Optimizer Studio (SAOS, dále jen
„studio“), což je grafický prostředek pro konfiguraci a správu IWA a databázového serveru. Dostupné je ve dvou verzích – Linux a Windows. Vlastní
konfigurace vyžaduje prostor v systému souborů
pro zálohu dat, alokaci potřebné paměti a procesorovou kapacitu. Po připojení studia k databázovému serveru nastává fáze designu, vyhodnocení a nasazení data marts připraveného na načtení
dat do akcelerátoru. Obrázek 2. ukazuje jednotlivé
složky akcelerátoru, jimiž jsou Coordinator a Worker. Proces Coordinator je vždy jeden a komunikuje s několika procesy. Worker Akcelerátor se k databázovému serveru připojuje vždy přes TCP/IP.
Pokud jsou akcelerátor a server na stejném počítači, komunikují přes loopback rozhraní. Komunikace
se definuje v souboru sqlhosts a je použit nový typ
komunikačního protokolu se zkratkou dw.
Koordinátor plní tři důležité funkce:
1. Komunikace s databázovým serverem. Server se
připojuje ke koordinátoru, zasílá mu data a dotazy a dostává výsledky.
2. V průběhu načítání dat koordinátor distribuuje
každému procesu Worker úplný kompresní slovník a připojuje respektive a redistribuuje slovník
dle potřeby.
3. Během zpracování dotazu koordinátor přijímá
dotazy od serveru, každému procesu Worker dotaz zašle, přijímá mezivýsledky, spojuje je, resp.
20
Obrázek 2: Komponenty IWA
třídí, je-li to potřeba, a nekomprimované výsledky zasílá databázovému serveru.
Procesy Worker plní dvě funkce:
1. V průběhu načítání dat každý Worker analyzuje
vstupní data a určuje jejich frekvenční charakteristiku, dělí data vertikálně i horizontálně do buněk a komprimuje data použitím tzv. Deep Columnar techniky. Po kompresi jsou data zapsána
na disk kvůli potenciální obnově. O technice
Deep Columnar bude pojednáno v tomto článku později.
2. Druhou funkcí je zpracování dotazu nad komprimovanými daty. Každý Worker udržuje komprimovanou kopii tabulek dimenzí a části tabulek
faktů. Všechny procesy Worker vrací mezivýsledky koordinátoru. Dotaz je 100% zpracován
v paměti.
Encyklopedie definují Data Mart jako podsoubor
datového skladu, obvykle specificky orientovaný.
Typická jsou schémata sněhové vločky a Data Mart
obsahuje alespoň jedno takové schéma. Na obrázku 3. je velmi zjednodušené schéma prodejů, kde
tabulka faktů je DAILY_SALES a ostatní tabulky jsou
jednotlivé dimenze. Je běžné, že tabulky dimenzí obsahují podstatně méně řádků než tabulky faktů. Studio umožňuje grafický návrh a vývoj Data
Marts a definici vztahů mezi jednotlivými tabulkami. Ve fázi použití zašle studio definici Data Marts
akcelerátoru v XML formátu a ten zašle zpět definici
příkazu SQL. Definice je uložena jako VIEW v systémovém katalogu se speciálním příznakem.
Při načítání dat z tabulek je vzorek dat zaslán akcelerátoru a ten vzorky distribuuje všem procesům
Worker. Worker provádí frekvenční analýzu hodnot a vazeb ve směru sloupců i řádků. Po rozdělení
dat na fragmenty jsou data zkomprimována využitím techniky deep columnar a existují jednak v paměti a jednak v kopii na disku. Nevytváří se žádné indexy ani žádné tabulky agregací. Jakmile jsou
data načtena, je data mart v akcelerátoru připraven
k použití. Dotazy obsahují propojení tabulky faktů s jednou nebo více dimenzemi a výsledky jsou
zpět zasílány databázovému serveru. Na obrázku 2.
je konfigurace IWA s jedním procesem Koordinátor
a 4 procesy Worker. Tabulky dimenzí jsou zkomprimovány a uloženy v paměti pro každý proces Worker. Řádky tabulky faktů jsou rovnoměrně rozděleny na čtvrtiny. Rychlost přenosu dat logicky narůstá
s počtem procesů Worker, ale nemusí vést k urychlení dotazu. Množství paměti pro proces Worker
lze rámcově odhadnout z velikosti tabulek dimenzí v poměru 1:3 (komprimovaná data v paměti/nekomprimovaná data v databázi). Dále je třeba mít
na paměti, že každý Worker potřebuje prostor pro
mezivýsledky a bývá obvyklé, že 1/5 až 1/3 nad velikost dat je postačující. Konečné stadium zpracování dotazu je na procesu Koordinátor, který spojuje jednotlivé výsledky, dekomprimuje, třídí a zasílá
serveru.
Pro zlepšení výkonnosti vyvinula společnost IBM
novou technologii použitou v akcelerátoru, nazývanou Deep Columnar Technology. Extrémní komprese dat eliminuje I/O diskové operace a paměťové operace jsou založeny na využití architektury
více procesorových jader a SIMD technologie (Single Instruction Multiple Data). Prvním krokem je
vždy analýza frekvence výskytu dat ve sloupcích
a rozčlenění dat do buněk. Pro kompresi je použit Huffmanův algoritmus, který nejfrekventovanějším datům přiděluje nejkratší kód. Tradiční databáze ukládají data v kompletních řádcích jeden
za druhým. Design řádkového ukládání je optimalizován na I/O operace s předpokladem, že dotaz
pracuje s většinou sloupců. Pokud jsou v úložišti
data komprimována, řádek musí být dekomprimován pro každý fetch. To je účinné pro transakční úlohy, ale pro analytické úlohy, kdy každý dotaz analyzuje vztah mezi podsouborem sloupců v tabulce
faktů, je tento postup málo efektivní. Sloupcová databáze, s níž pracuje IWA, ukládá společně všechny
hodnoty daného sloupce. Vždy když jsou data vkládána, je řádek rozčleněn na jednotlivé hodnoty daného sloupce a kdykoli je řádek načítán, jsou hodnoty zpětně spojovány.
Společným uložením hodnot daného sloupce lze
dosáhnout lepší komprese a pro analytické dotazy není nutno načítat celé řádky, ale pouze vazební sloupce. IWA ukládá data ve sloupcových
skupinách nazývaných „banks“. Přiřazení sloupců
do „banks“ je specifické pro každou buňku, protože
délka sloupce je pro každou buňku odlišná.
Přiřazování dat do buněk je založeno na binárním
komprimovacím mechanismu a při skenování dat
se přistupuje pouze k těm sloupcům, na které se
dotaz odkazuje.
Významné zlepšení rychlosti zpracování přináší využití SIMD paralelismu. Mějme dotaz:
SELECT SUM (s.amount) FROM SALES AS s WHERE s.
prid = 100 GROUP BY s.zip
Pokud jsou sloupce amount (A), prid (P) a zip (Z)
z téhož banku, může byt načteno do 128 bitového
registru procesoru několik hodnot. Při délce banku
32 bitů lze současně načíst 4 trojice, tj. 12 sloupců.
Instrukce SIMD na procesorech Intel operují se 128
bitovými registry a kompresní technika akcelerátoru vyžaduje pro každý sloupec několik bitů a tak lze
do každého registru simultánně mnoho hodnot.
Během zpracování dotazu lze zatížit všechna jádra
a dosáhnout vysokého paralelismu. V uvedeném
příkladu je paralelně zpracováno 12 hodnot pomocí jediné procesorové instrukce.
Efektivní skenování je základem pro zpracování dotazu. Z hlediska skenování je základní jednotkou
buňka. Akcelerátor dynamicky generuje potřebné
procesy a přiřazuje jednotlivé buňky jádrům procesoru. Sken probíhá na komprimovaných datech
s využitím SIMD instrukcí a Huffmanova algoritmu. Klauzule GROUP BY se provádí na komprimovaných datech, ale agregace až na dekomprimovaných. Díky použité kódovací technice lze do L2
cache procesoru umístit celou hash table. Může se
stát, že propojení dvou hustě kódovaných tabulek vede k velkému prořídnutí dat, ale akcelerátor
umí takový případ detekovat a automaticky změnit
techniku zpracování.
vým serverem Informix lze rozdělit celkovou zátěž
mezi akcelerátor a server. O rychlosti odezev svědčí
následující tabulka porovnávající délku dotazu při
použití samotného serveru a s pomocí akcelerátoru. Dotazy byly prováděny nad cca 1 miliardou řádků v tabulce faktů.
Dotaz č.
IDS 11.5
IDS 11.7 IWA
1
22 min.
4s
2
01 min 3 s
2s
3
03 min 40 s
2s
4
30 min
4s
5
02 min
2s
6
30 min
2s
7
45 min
2s
Tento článek chce pouze stručně upozornit na nový
produkt v oboru databázových produktů a zvídavého čtenáře odkazuji na podrobnější literaturu.
Literatura:
IBM Informix Warehouse Accelerator, Keshava Murthy,
March 2011
Informix Warehouse & Informix Warehouse Accelerator, Jan Musil, 2011
Petr Paul
IWA výrazně zlepšuje produktivitu Business Inteliteligence dotazů. Díky těsné integraci s databázo-
INFORMIX GENERO
Nový prostředek pro převod stávajících 4GL aplikací do 3vrstvé architektury umožňuje vývojovým
pracovníkům v grafickém prostředí rychle a efektivně vyvinout programy, které splňují požadavky
současných uživatelů. Efekt je nejen v úsporách času oproti vývoji zcela nové aplikace, ale i v tom,
že výsledek převodu je přímo přenositelný na jakoukoli platformu. Informix Genero má širokou zásobu vestavěných prvků, které zlepšují i výkonnost aplikace.
K dispozici jsou (verze 2.32) prostředky:
1. Vývojová sestava:
- Desktop Client,
-Studio,
- Business Development Language (zkratka BDL)
with web services,
- Report writer,
-SDK;
2. Runtime sestava:
- Desktop Client,
- Application Server,
- Informix Connect runtime.
Samotný jazyk je z 99 % kompatibilní s Informix
4GL a správa aplikací je jednoduchá. K dispozici
jsou běžné grafické prvky (pull-down menu, push-button, radio-button, listbox, multibox, viewer
aj.) a jsou integrovány webové služby. Java interface zajišťuje kompatibilitu s Java API a knihovnami. Ovládání grafických prostředků je intuitivní, výsledný pseudokód je nezávislý na platformě a může
být až o 1/3 kratší a 2x rychlejší.
Obrázek 1: Zdrojový text
Při programování v prostředí Genero je možné pomocí techniky drag & drop využívat předpřipravené grafické prvky svázané s automatickým generováním kódu. Graficky lze vytvářet pohledy
master-detail i složité příkazy SELECT. Na obr. 1 je
příklad zdrojového kódu jazyka Genero Business
Development Language.
Základním prostředkem, který integruje vývojové
prostředí je tzv. Genero Studio a jeho součástí jsou
všechny prostředky potřebné pro vývoj aplikace
a správu projektů, jak je ukázáno na obr. 2
Na obrázku 3 je uvedeno schéma propojení jednotlivých částí více vrstvé architektury s využitím služeb Genero Application Server (GAS)
21
mů s maximální účinností. Takový přístup většinou vyžaduje několikaměsíční práci. Základem
je přehodnocení ergonomiky stávající aplikace a návrh nových oken s využitím široké palety
grafických prvků. Často je potřeba změn v databázovém schématu, aby se dalo efektivně využít možností business grafiky bez nutnosti zasahovat do zdrojového kódu. Vhodnou úpravou
formulářů a využitím bezpečnostních šablon lze
dosáhnout značného snížení jejich počtu. Výsledkem by měla být plně grafická aplikace.
Obrázek 2: Prvky Genero Studia
Obrázek 3: Zapojení GAS
Nejcennější investicí do vývoje aplikace je lidská síla. Pro vývoj jsou potřeba lidé důvěrně znalí chodu podniku a jeho priorit, kteří jsou schopni
přenést informace do softwarových procesů. Pro
transformaci aplikace je potřeba uvážit, jaké množství času a jaké náklady migrace 4GL kódu do Genera vyžaduje a jaké jsou možnosti lidských zdrojů.
V podstatě jsou možné dvě metody konverze:
1. Krátkodobá spočívající v jednoduché rekompilaci stávající aplikace s Informix Genero s minimem změn uživatelského rozhraní. Takový
přístup umožňuje migraci řádově v týdnech.
Vzhled aplikace bude poplatný znakovým obrazovkám 25 řádků a 80 sloupců a bude odpovídat
původním formulářům 4GL (viz obr. 4). S poměrně nevelkým úsilím lze vzhled oken přikrášlit,
ale původní struktura se nezmění. Použití myši
je implicitní vlastnost a není potřeba žádných
změn v programu.
Obrázek 4: Vzhled obrazovky 4GL a Genero
2. Středně-dlouhodobá využívající plnou sílu
prostředku Genero – vyžití ovládání drag &
drop, webových služeb, business grafiky a stylů prohlížeče k zajištění minimálních problé-
22
Několik poznámek ke konverzi 4GL do Informix
Genero
Genero zavádí nový způsob zobrazení obrazovkových formulářů ve formátu XML. Metoda umožňuje
abstrahovat logiku aplikace od fyzické implementace klientské technologie. Výsledkem je možnost
spouštět aplikaci na různých klientských technologiích – Windows, Linux HTML nebo Java.
Skoro všechna klíčová slova jazyka se shodují se
4GL a ve většině případů prostá rekompilace povede k funkční aplikaci, ale většinou za cenu ztráty elegantního vzhledu. Proto se doporučuje určité
části kódu modifikovat, aby se využilo možností Genera. Jak už bylo uvedeno, revize designu a ergonomie aplikace často vede k dramatickému zmenšení
počtu formulářů a délky kódu. Před vlastní konverzí
se doporučuje provést revizi některých funkcí.
1. C funkce – pokud používáte funkce v jazyku C,
je nutné je před konverzí zkontrolovat. Většina
bude použitelná v daném stavu, některé bude
nutné přepsat do Business Development Language (dále jen BDL). Takovými funkcemi jsou
ty, které komunikují s uživatelem. Použití funkcí v jazyce C obecně zhoršuje přenositelnost
do Genera a doporučuje se je přepsat do BDL.
2. Funkce FGL_LASTKEY, FGL_GETKEY, FGL_KEYVAL jsou kvůli kompatibilitě podporovány, ale
doporučuje se revize zdrojového kódu, kde jsou
volány.
3. Použití INPUT_ARRAY k zobrazení polí. Vývojáři
s oblibou používají příkaz INPUT ARRAY se skrytými poli k zakrytí nedostatků obsluhy příkazu.
Tyto „obchůzky“ vedou ke tvorbě neproduktivního kódu emulujícího permutace možných akcí
koncového uživatele, skrývající vlastnosti příkazu INPUT ARRAY a emulující příkaz DISPLAY
ARRAY. V BDL je tento problém snadno řešitelný
a doporučuje se revize příslušných částí kódu.
4. Menu v ASCII znakové sadě většinou vypadají dobře, ale v grafice je jejich vzhled většinou
nehezký. Z estetických důvodů se doporučuje
přepsat menu, aby byla uživatelsky příjemnější. Není to nutně jeden z prvních kroků migrace,
menu lze později postupně upravovat.
5. Definice FUNCTION a argumentů – kompilátor
4GL (v závislosti na verzi) umožňuje opakova-
nou definici funkce se stejným názvem a nekontroluje počet jejich argumentů. Genero je v tomto směru striktní, vyžaduje unikátní názvy funkcí
a kontroluje počet argumentů funkce.
6. Ve 4GL se pro práci s externími soubory používá
funkcí jazyka C, jazyk BDL obsahuje vlastní příkazy pro manipulaci s externími soubory.
7. P-kód versus binární C – Genero vytváří pouze P-kód a tvrdí se, že je výkonově srovnatelný s binárními soubory.
8.Soubory *.per se doporučuje zrevidovat. Tento formát 4GL je sice stále podporován, ale má
omezené grafické možnosti. Pravděpodobně
přepisem formulářů by měla začít revize ergonometrie aplikace.
9. Příkaz „DISPLAY … AT …“ je sice podporován,
ale vzhledem k odlišnému způsobu určení pozice není zaručeno, kde se nápis zobrazí. Doporučuje se náhrada příkazem „DISPLAY TO…“.
10.Důležité kontroly před instalací Informix Genero
– kontrola verze operačního systému, volného
diskového prostoru, přičemž jen dočasné soubory vyžadují okolo 15 MB. Kontrola síťového
zapojení a velikosti operační paměti. Jedna uživatelská seance vyžaduje 2-6 MB paměti. Instalace grafického prostředí je nezbytná, ať se jedná o X11 nebo Windows. Dále potřebný webový
prohlížeč v podporované verzi a spojení na internet.
11.Databázový server, který komunikoval se 4GL
aplikací bude komunikovat i s Informix Genero.
Doporučuje se mít instalovánu nejnovější verzi
CSDK obsahující ESQL/XC.
Migrace 4GL aplikace do grafického prostředí je bezesporu náročná akce a jak plyne z předchozích poznámek, má i řadu úskalí. Jak již bylo na začátku naznačeno, záleží na množství lidských zdrojů, touze
uživatele po „zlidštění“ znakové aplikace a ochotě nést náklady konverze. Podrobnější informace
lze najít na stránkách IBM „Publications for IBM Informix Genero: http:/www.ibm.com/support/docview.wss?uid=swg270209967
Literatura:
Informix Genero, Jan Musil, 2011
IBM Informix Genero, IBM Information Management,
March 2011
Converting Informix 4GL Applications to Informix Genero, IBM Information Management, March 2011
Petr Paul
SUDOKU
ČLOVĚK NENÍ ŽIV JEN PRACÍ, aneb i v práci se zasmějete
Baví se dva programátoři.
“Tak, co jak jsi spokojený se svou nastávající?
„Ale, já nevím, zatím jsem k ní nedostal manuál a ani
on-line help nefunguje, ať mačkám, co mačkám. Navíc nevím, jestli je to no name nebo nějaká značka.“
„To nic, hlavně aby byla easy to install a user friendly.“
Volá uživatel na technickou podporu, že mu nejde
vložit do mechaniky třetí instalační disketa.
Technik po delším přemýšlení: „Poslyšte, a vyndal
jste vůbec tu druhou?“
„Ne, a to mi připomíná, ta už tam šla taky nějak špatně.“
Manželka pošle programátora do obchodu: „Dojdi
pro rohlíky, a když budou mít vejce, vem jich deset.“
Programátor přijde do obchodu a ptá se: „Máte vejce?“
Prodavačka: „Ano“
A programátor: „Tak mi dejte 10 rohlíků.“
----------------------------------------------------------------
----------------------------------------------------------------
----------------------------------------------------------------
Výstava nejmodernější americké výpočetní techniky v Praze.
Prodavač hrdě vysvětluje: „Toto je nejmodernější
model amerického počítače. Dokáže porozumět hovorové lidské řeči. Splní jakékoli přání, které vyslovíte.“
„Smím to vyzkoušet?“, ptá se Franta.
„Samozřejmě pane. Pojďte blíž a mluvte.“
„Formát cé, dvojtečka, enter…“
----------------------------------------------------------------
Uživatel: „Proč bych měl platit nějakej poplatek za
vypalovačku a média, když nebudu nic krást?“
Zákonodárce: „Protože máte nástroj.“
Uživatel: „Tak to mě zavřete za znásilnění sousedky!“
Zákonodárce: „Vy jste znásilnil sousedku?“
Uživatel: „Ne, ale mám nástroj!“
Víte, kolik je potřeba programátorů k výměně žárovky? Ani jeden, problém se týká hardwaru.
----------------------------------------------------------------
23
DĚKUJEME VŠEM NAŠIM
KLIENTŮM ZA PŘÍZEŇ
A DŮVĚRU
KOMIX s.r.o.
Avenir Business Park, Radlická 751/113e, 158 00 Praha 5, Tel.: +420 257 288 211, [email protected], www.komix.cz. Redakční zpracování: kolektiv pracovníků KOMIX s.r.o.
DTP a produkce: SDP V.I.P. Servis, s.r.o.
© KOMIX s.r.o. 2011