KOMIX NOVINY 2011/2012

Transkript

1 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 pilíře strategie testování...3 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 Retrospektivy nic složitého...5 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

2 Č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á. 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. 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 Zkusme si uvést několik základních zásad budování čistých IS. 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 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. 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. 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- 2

3 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. Při návrhu IS vycházíme od požadavků na řízení firmy a jejích procesů. Lepší než čistit data, je zajistit, aby čistá již vstupovala a nekazila se. Reporty musí být přehledné a srozumitelné, všemi chápany stejně. 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. Kvalitní MIS znamená: kvalitní data ve společnosti, tj. primární IT systémy jsou správně navrženy a sbírají relevantní, konzistentní a smysluplná data; nejen nástroj pro analýzu chování organizace a lidí, kteří ji tvoří, ale i vlivů okolí; jistou kulturu komunikace uvnitř organizace, rozhodování na základě věcných a správných podkladů, sdílené hodnoty a cíle. PS. S tím stavěním čistého systému vám samozřejmě pomůžeme. Petr Kučera Shrneme-li výše uvedený text, pak můžeme použít hesla: 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

4 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í. 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ě nebrá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: 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í testeř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ů 4

5 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ů. 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ěrnou strukturou se na papíře špatně pracuje, proto je ještě vhodné provést tuto sekvenci užitečných triků: 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í F - 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. 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) U Unit Integrační Systémové Akceptační Validace B Design N F / N / B dle závažností Uživatelská odolnost B F - - 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 F 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á. 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í: 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 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 naložit s náměty ke změnám, které vzešly z předchozí retrospektivy. 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. 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í 5

6 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 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. Na závěr ještě pár doporučení. Důležité je, aby celá retrospektiva i její jednotlivé části byly časově omezené. 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. 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 , , Poté se vývoj poněkud zpomalil a mezníky ve vývoji se staly minor verze, např , Poslední verzí PHP 4 bylo PHP z roku Paralelně s PHP 4 se vyvíjelo PHP 5, a to již od roku 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 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, 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šíření 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- 6

7 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 Vývojář si může vybrat z celé škály, například: CakePHP, Nette, Symfony, Yii, Zend, atd. 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, Error Reporting), řeší nedostatky objektového modelu PHP zavedením omezení a kontrol, které samotný jazyk neobsahuje. 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. 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 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 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

8 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 KOMI- Xu 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é technologické 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 zvoleno čí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, 8

9 Obrázek 1: Trendové křivky 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é 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 časa 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

10 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 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. 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. 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. 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. Obrázek 2: Upřesněné zobrazení klíčových ukazatelů 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 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 Detailní údaje jsou samozřejmě okamžitě k dispozici též v tabulkové podobě. Obrázek 3: Detailní údaje Vedle tabulkového zobrazení je nad celým souborem samozřejmě podporováno také grafické zobrazení libovolných klíčových ukazatelů. Obrázek 7: Zobrazení vybraného detailu v tabulkové podobě 10

11 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. 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. 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 ové 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. 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. 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 Proces 1: Pokrytí HR procesu aplikací TalentCare 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

12 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). 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 vyhledá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í 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; 12

13 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á 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 Eclipv 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 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 jako soubor poskytovaných komplexních služeb či obecně jako Enterprise Service Bus. Návrh procesu 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. 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. Běh procesů 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. 13

14 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ředchozí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: 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. 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, 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. 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 aplikacemi 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. 14

15 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. 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íť. Implementace brokeru také poskytuje monitorovací a auditní nástroje, které umožňují uživatelům 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. 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. 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 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. 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. 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

16 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, SO- PERA, 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 snadný 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 integrač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 16

17 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

18 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. 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. 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í, 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 18

19 (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

20 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í 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. 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 20