Reprezentace úloh jako graf závislostí

Pro zajištění maximální flexibility jsou úlohy organizovány na jednoduchém zato mocném principu definice závislostí a objektů. Objektem může být úloha (job), zámek, nebo konektor. Úlohy lze mezi sebou synchronizovat pomocí závislostí typu předchůdce-následník. pokud tento typ závislosti nestačí, lze pro dodatečnou synchronizaci použít zámek. Typicky lze zámek použít jako abstrakci pro tabulku, či soubor, který úloha používá a tak lze omezit sdílený, nebo vynutit exkluzivní přístup úloh k objektu. Objekt typu konektor slouží jednak k definici připojení k cílovému prostředí a jednak, podobně jako u zámku, pro nastavení sdíleného, či exkluzivního přístupu k cílovému prostředí.

Graf závislostí má mnoho výhod oproti stromové reprezentaci, nebo workflow. Především zajišťuje:

• Maximální přehlednost – úlohy jsou si rovnocenné a netvoří hierarchii, lze tedy snadno dohledat přímé i nepřímé závislosti a neexistují zde nejasné či zbytečné závislosti, které jsou vynuceny stromovým uspořádáním, nebo workflow.
• Snadnou spravovatelnost – při změně závislostí u úlohy je třeba pouze přesměrovat závislosti na správné objekty a není nutné rozdělovat strom, nebo workflow na více částí a měnit jejich nové zařazení do hierarchie, což je pracné a často náchylné k chybám (díky nejasné dohledatelnosti závislostí).
• Maximální možnou autonomitu úloh – jelikož jsou definovány pouze nutné závislosti, může scheduler efektivněji řadit úlohy pro spuštění, operátor může snadněji a efektivněji restartovat, či přeskočit množiny úloh, tj. není nutné spustit celé (pod)workflow, či (pod)strom, ale pouze vybrané úlohy včetně následujících úloh, které (reálně) závisí na výstupu předchůdců.

Scheduling úloh

Řízení zpracování úloh pomocí závislostí dovoluje maximální paralelizovatelnost, čehož lze využít pro různé metody schedulingu. Nejjednodušší typ řízení v globtech scheduleru je pomocí priorit. Dalším typem řízení je řízení na základě statistik předchozích běhů úloh, jehož cílem je upřednostnění „kritických cest“ v diagramu závislostí.
Jiným kritériem řízení procesů nezávislým na předchozích dvou je load-balancing, tj. řízení na základě zatížení systémů. Toto kritérium umožňuje spuštění procesu pouze v případě, že není cílový systém aktuálně přetížen. Pro lepší odhad vytížení serveru po spuštění procesu lze využít sběr statistik. Takto lze balancovat vytížení operačního systému, databáze, nebo např. etl serveru. Load-balancing může být výhodný z toho důvodu, že i mírné přetížení serveru může výrazně prodloužit běh úloh, což je zapříčiněno zvýšením i/o diskových operací z důvodu memory swapingu v operačním systému, častých výpadků data cache databáze, nebo velkého množství paralelního čtení a zápisu vyvolávajícího velké množství i/o seeků.

Architektura scheduleru

Scheduler je členěn na podmoduly: repository databázi, runtime databázi, runtime server a uživatelskou consoli.

Schema

• Repository databáze obsahuje definice objektů. definice může být parametrizována, je tak možné popsat např. Množinu souborů stejného typu lišících se pouze datem vygenerování. K repository lze přistupovat pomocí databázového api (pohledy a procedury), je tedy možné definice objektů generovat automaticky z jiných metadat.
• Runtime databáze obsahuje aktuální stav objektů a další data, např. event log, statistiky, nastavení runtime serverů apod.
• Runtime server je service (démon) proces, který vykonává naplánované úlohy. Runtime server je zodpovědný za výběr úlohy ke spuštění (load-balancing), její spuštění, monitoring a sběr statistik. Server takto může spustit více úloh současně (počet paralelního spuštění lze konfigurovat za běhu serveru). Je možné spustit více runtime serverů, jež mohou být rovnocenné, nebo běžet v záložním módu.
• Webová console je intranetové grafické uživatelské rozhraní pro správu metadat, řízení a monitoring úloh a celého prostředí scheduleru. Detailněji je popsána níže.

Funkcionalita

Repository a runtime databáze

• Scheduler je silně orientován na databázové aplikace, proto podporuje databázové api. Databáze obsahuje vždy aktuální, transakčně aktualizovaná data.
• Proměnné definované pro runtime databázi je možné využít pro parametrizaci úloh, např. podle business date, nebo jména prostředí (test, produkce), nebo jména statistiky apod.

Konektor

• Jednotný způsob připojení k cílovému prostředí – abstrakce od konkrétního připojení, např. konektor shodného jména může být namapován v testovacím prostředí na jiné cílové prostředí, než v produkčním prostředí. Lze mapovat více konektorů na jedno cílové prostředí.
• Použití jednotných credentials (viz server).
• Možnost řízení zatížení nastavením max. počtu paralelních přístupů.
• Možnost exkluzivního přístupu úlohy ke konektoru.
• Dočasné zablokování konektoru operátorem, nebo programově přes databázové api.

Zámek (lock)

• Slouží jako dodatečná synchronizace mezi joby. Může sloužit jako abstrakce souboru, tabulky, databáze, procesoru, či jakéhokoliv zdroje, ke kterému je třeba omezit paralelní přístup úloh.
• Zámek může fungovat jako spoušť, resp. závora a může tak na povel operátora, nebo programově pomocí databázového api odstartovat zpracování skupiny úloh.

Úloha (job)

• Systémové úlohy – je možné spustit libovolný spustitelný soubor operačního systému.
• Enabled/disabled – možnost ručního, nebo automatického zablokování spuštění úlohy.
• Abort – možnost násilného ukončení úlohy.
• Skip – možnost nastavení úlohy k přeskočení. K přeskočení dojde až v době, kdy je možné job spustit.
• Timeout – možnost nastavení vypršení čekání na dokončení a ošetření akcí, nebo alertem.
• Deadline – nastavení očekávané doby dokončení. Použito při řazení úloh ke spuštění.
• Priority – možnost nastavit prioritu zpracování. Immediate priorita pro okamžité spuštění.
• Statistiky – možnost sběru více druhů statistik, např. denní etl, měsíční ultima, kvartální, apod.
• Restart count, restart delay – možnost nastavení automatického opakování úlohy v případě selhání.
• Ošetření událostí – možnost spuštění servisní akce v případě některé z události spuštění jobu: on start, on finish, on end, on success, on error, on abort, on expire, on skip.
• Recovery plán – komplexní ošetření dokončení zpracování úlohy.
• Historie běhů – o úloze je vedena historie běhu. Historii lze dohledat buď pro runtime identifikaci úlohy, nebo repository identifikaci. Historie obsahuje kromě základních údajů i obsah výstupních atributů (např. informace o počtu zpracovaných řádcích).

Runtime server

• Lze spustit jako samostatný server (nativní službu os), nebo jako součást aplikačního serveru.
• Fail-over — časová značka aktivity, ošetření výpadku spojení s databází, možnost instalace záložních serverů.
• Možnost nastavení idle stavu, po který nejsou zpracovávány nové úlohy.
• Možnost nastavení parametrů vyhledávání úloh ke zpracování a maximálního počtu paralelně zpracovávaných úloh.
• System logs – lze nastavit formát a jméno log souborů, max velikost a dělení do více částí. Úroveň logování lze nastavit pro různé části serveru zvlášť. Záznamy logované pro každý proces serveru (např. worker zpracovávající úlohu) jsou snadno a rozpoznatelně identifikované. Možnost logovat do windows system logu, nebo do produktů třetích stran, které mají konektor pro knihovnu log4j.
• Event log – významné události ve scheduleru jsou logovány jako události do runtime databáze (zároveň též do systémového logu). Uživatelskou událost lze zalogovat i v servisní úloze, nebo pomocí databázového api.
• Alerts – události lze identifikovat pomocí pravidel a v případě nalezení pravidla odeslat emailový alert.
• Credentials – uložené buď v runtime databázi (ve správě operátora), nebo v konfiguraci serveru (ve správě systémového administrátora), integrace s java keystores (nativní forma, nebo podpora systémového úložiště).
• Mailer – jednoduchá služba kterou lze odeslat emailovou notifikaci. Službu lze využít v service úloze.
• Sběr statistik – automatický sběr statistik o běhu úlohy. Lze vypnout, pokud jsou statistiky generovány externí procedurou.
• Proměnné prostředí – server zpřístupňuje úlohám proměnné prostředí operačního systému, dál zpřístupňuje tzv. properties java prostředí a využívá globální a vlastní proměnné runtime databáze.
• Rozšiřitelnost – do serveru lze jednoduše integrovat libovolnou java knihovnu a exportovat její funkce. Knihovny vyžadující lifecycle a využití služeb serveru lze integrovat jako interní služby.

Cílová prostředí

• Systémové úlohy – je možné spustit libovolný spustitelný soubor operačního systému. Lze ukládat standardní a chybové vystupy a historizovat je.
• RDBMS databáze – přístup pomocí jdbc rozhraní, možné použít vstupní/výstupní parametry skriptu, nebo přímo sestavit dynamicky skript.
• Informatica integration services – přímá podpora dovoluje jednoduše spouštět a kontrolovat workflow v integration serveru. Po dokončení běhu workflow lze stáhnout a uložit informace (log soubory, statistiky) o běhu.
• Kopírování souborů – scheduler přímo podporuje kopírování z/do úložišť typu lokální file systém, http(s), webdav, ftp(s), sftp, scp, samba. Podle typu protokolu lze použít autentizaci typu uživatel a heslo, nebo certifikát a možnost ověření serverového certifikátu.
• Servisní operace – operace v runtime serveru. Lze programovat jednoduché servisní skripty.
• Pomocí odvozených typů úloh lze vytvořit šablony pro jiná cílová prostředí a typy úloh, jako např. pro dtexec utilitu spouštějící ssis packages, pro oracle loader, perl skript, apod.

Uživatelské typy úloh

Silnou vlastností scheduleru je možnost vytvoření odvozených typů úloh (šablon). Odvozenému typu lze předdefinovat hodnoty stávajících atributů, nebo definovat atributy nové. Atributy lze definovat buď hodnotou, nebo jako výraz. např. pro libovolnou command-line utilitu lze definovat odvozený typ jobu od system jobu a tomuto typu přednastavit atributy command, či working directory. Atribut arguments lze potom definovat pomocí výrazu, který sestaví parametry podle speciálních atributů definovaných pro tento typ jobu.

Kalendář, exekuční plán

Kalendář definuje seznam svátků a časovou zónu. Exekuční plán definuje posloupnost časových okamžiků v rámci kalendáře podle definovaných omezení. Požadavkem může být například „denní spuštění ve 2:00 hodiny ráno“, výsledným exekučním plánem je řada 1.1.2010 2:00, 2.1.2010 2:00, 3.1.2010 2:00, … v definici exekučního plánu lze použít omezení na konkrétní, nebo pravidelný (první, druhý) měsíc, týden, den, hodinu, minutu, pracovní/nepracovní den od začátku, či od konce měsíce a podobně. Platnost exekučního plánu je možné omezit na určité období a na určité časové denní okno. Konfigurací exekučního plánu, omezením jeho platnosti a kombinací různých exekučních plánů lze uspokojit prakticky libovolné požadavky na plánování spuštění úloh.

Webová console

Uživatelské rozhraní podporuje přístup ve třech odlišných rolích: administrátor, operátor a běžný uživatel. Administrátor je zodpovědný za správu repository, resp. definic objektů. Runtime data má přístupné pouze pro čtení. Operátor je naopak zodpovědný za runtime databázi a běh runtime serverů. Je schopen modifikovat aktuální stav objektů a reagovat tak na nahodilé události (např. řešení nenadálých chyb, popř. zablokování). Operátor má repository data přístupná pouze pro čtení. Role user je určena pouze pro read-only přístup do repository i runtime databáze a slouží pro ostatní typy uživatelů. Navíc je zavedena role, která spojuje roli administrátor s rolí operátor – role superuživatel. Role jsou definované na úrovni databáze a jsou tedy aplikovány i na úrovni databázového api.

Efektivní zobrazení, navigace, editace, operace

Console je navržena a optimalizována pro prohlížení a editaci grafu o velkém počtu objektů. V základu je tedy použito tabulek pro zobrazení dat. V detailech úlohy lze dohledat přímé závislosti a pomocí provázání hyperlinky lze proklikávat hierarchii. Dále lze také použít stromové zobrazení hierarchie. Objekty lze libovolně filtrovat a řadit. Veškeré odkazy na jiné objekty jsou reprezentovány pomocí hyperlinků (viz odkaz na type na obrázku), což umožňuje rychlou navigaci.

Obrazovka editace objektů v konzole

Pro hromadné operace s joby, jako je např. restart, je třeba mít možnost efektivně vybrat skupinu jobů např. pomocí dialogu pro hromadné operace s joby. Horní tabulka slouží pro zobrazení jobů v hierarchii k předchůdcům, či k následníkům, nebo bez hierarchie. Joby je možné filtrovat, řadit a vybírat – aktuální výběr je zobrazen v dolní tabulce. po dokončení výběru lze provést vybranou operaci (v tomto případě restart) pro všechny joby najednou v jedné transakci.

Obrazovka skupinové editace

Monitoring

Přehledný stav o aktuálním stavu je pravidelně aktualizován v levém panelu. Uživatel má tedy během své práce neustále přehled o aktuálním stavu zpracování úloh. Podrobný monitoring jobů lze provádět pomocí obrazovky jsou zde přehledně zobrazeny joby v důležitých stavech a informace o nich. Operátor může průběžně sledovat běžící úlohy, úlohy k vyřešení (např. při selhání, nebo násilném ukončení), úlohy čekající na spuštění, právě dokončené úlohy apod.

File systém

Pro zobrazení pracovních adresářů, adresářů s logovacími daty, nebo s výstupem úloh (např. standardní a chybový výstup systémové úlohy) lze do console připojit adresáře, jejichž obsah lze prohlížet třídit a filtrovat. Soubory v nich obsažené lze případně zobrazit, či stáhnout na lokální file systém uživatele.

Orazovka připojených adresářů file systému

Přizpůsobení grafického rozhraní

Console má parametrizovatelné grafické rozhraní na třech úrovních:

• Odlišení prostředí (např. test, produkce) pomocí barvy menu a titulku console.
• Jednoduchý konfigurační soubor pro obarvení console podle firemních standardů.
• Detailní customizaci vzhledu pomocí šablon se styly a layoutem obrazovek.

The post Řídící nástroje – GTL Scheduler appeared first on GTL Tools.

Seskupování úloh do skupin – joby, stepy

• Job – skupina logicky souvisejících úloh.
• Step – úloha – jeden krok jobu.
• Job obsahuje několik stepů, pořadí stepů v rámci jobu je pevně dané.
• Závislosti mezi joby – pořadí zpracování nejen v rámci jobu, ale i mezi joby navzájem.

Obrazovka konfigurace Jobu

Paralelismus a prioritizace

• Spouštění více úloh zároveň
• Možnost definovat, které úlohy mohou a které nemohou běžet paralelně.
• Možnost ovlivnit pořadí zpracování úloh pomocí priority.

Pokročilé plánování jobů a stepů

• Možnosti srovnatelné se schedules v sql server agentovi, spouštění úlohy denně, týdně, měsíčně, jen v pracovní dny apod.
• Možnost zkombinovat více exekučních plánů.

Obrazovka plánování jobů

Odolnost vůči chybám

• Oddělení spouštěných úloh od řízení launcheru – pád úlohy neznamená pád launcheru.
• Každá úloha běží jako samostatný proces (sql server agent job).

E-mailové notifikace

• Zasílání zpráv o průběhu zpracování – úspěšné dokončení jobu, chyby v úlohách apod.

Inteligentní nakládání s chybami

• Mechanismus recovery – automatické reakce na výsledek běhu úlohy (poslání emailu, restart úlohy, spuštění opravné úlohy).
• Kritické a nekritické chyby: kritické úlohy – při chybě v úloze dochází k pozastavení dalšího zpracování;nekritické úlohy – neúspěch úlohy zpracování nezastaví.
• Logování chyb v běhu launcheru i v běhu úloh, procházení chybového logu přímo z aplikace.

Editační prostředí

• Ovládání launcheru kompletně z uživatelského rozhraní, přímé zásahy do databáze omezeny na minimum (speciální servisní zásahy).
• Možnost vytvářet joby, stepy, úlohy, exekuční plány.
• Monitorování průběhu zpracování, možnost do průběhu zpracování aktivně zasahovat (pozastavení, restart, zrušení úloh).

Obrazovka zpracování jobů

Přizpůsobení potřebám zákazníka

• Barevné ladění aplikace.
• Typy spouštěných úloh.

The post Řídící nástroje – GTL Launcher appeared first on GTL Tools.

• Zdrojové a cílové objekty pro transformovaná data (Informatica PowerCenter sources and targets).
• Mapování s transformacemi.
• Sessions a workflows pro vygenerovaná mapování.
• Pomocné soubory pro mapování (parametrické soubory a definiční plány pro externí komponenty).
• SQL kód (BTEQ skript, uložené procedury) na základě vstupu z datového modelu.

Výsledkem generování jsou Informatica PowerCenter objekty uložené ve formátu XML, které je možné importovat přímo do Informatica PowerCenter Repository.

Architektura nástroje

GTL Generator tvoří tři základní komponenty:

• Vlastní aplikace GTL Generator (v jazyce java) instalovaná na pracovní stanici.
• Mapping Architect for Visio (součást instalace IPC).
• Úložiště metadat aplikace v databázi Oracle nebo PostgreSQL.

Metadata pro SW nástroj GTL Generator mohou být uložená na některém stávajícím databázovém serveru, není proto potřeba mít vyhrazený speciální databázový server.
Aplikace GTL Generator se provozuje lokálně na PC, na kterém musí být naistalovány klientské nástroje IPC a MS Visio. Aplikace vyžaduje přístup do repozitáře IPC přes klientské nástroje (command line nástroj pmrep.exe).

Hlavní funkce

• IN data – správa dat ve vstupní vrstvě aplikace. Umožňuje načítání, prohlížení a mazání datových struktur v rámci verze datového modelu.
• DS data – správa datových struktur ve vnitřní vrstvě aplikace, opět v rámci verze datového modelu.
• WRK data – správa pracovních datových struktur. Umožňuje připravit jednu plnou verzi datového modelu nebo rozdíl dvou verzí modelu pro následné generování objektů.
• Zdroje a cíle/Source and Target – generování IPC zdrojů a cílů pro konkrétní verzi modelu.
• Transformace/Transformations – správa šablon IPC objektů a jejich generování.
• Textové šablony/Text Templates – správa textových šablon a generování textů/skriptů.

IN data

Načtení dat do vstupní vrstvy je složeno ze dvou kroků:

• Načtení datových struktur pro konkrétní verzi modelu.
• Načtení historizací pro konkrétní verzi modelu.

Datovou strukturou je v tomto případě míněna tabulka a její definice – seznam sloupců, omezení, klíče, indexy atp. S pomocí importovaných definic všech používaných objektů jsou generovány zdroje a cíle. Definice jsou obecně vztaženy k verzi datového modelu, proto je možné provádět porovnání verzí a aktualizovat zdroje a cíle v případě změn modelu.
Načtení datových struktur se provádí z textového souboru pevné struktury. Jako oddělovač se použije středník, znaková sada je volitelná.
Historizace datových entit se provádí při plnění jádra datového skladu – targetu. Import historizací do generátoru vytváří vrstvu metadat, která se využívá v šablonách mapování určených pro plnění jádra skladu.
Nahrání dat se provádí z textového csv souboru pevné struktury. Jako oddělovač se použije středník, znaková sada je volitelná.

Obrazovka s tabulkami načtenými ve vabraném datovém modelu.

DS data

Vstupní vrstva obsahuje vstupní data pořízená uživatelem pro jednotlivé verze modelu. Pro plnou funkčnost aplikace se na záložce DS Data data upraví interními procedurami.

Pracovní (wrk) data

Pracovní data jsou data interně zpracovaná aplikací generátor a slouží jako:

• Podkladová data pro databázové objekty vytvořené v uživatelském schématu – schéma s definičními právy objektů pro uživatele. Databázové objekty jsou potom zdrojem pro hodnoty parametrů šablon.
• Data pro generování zdrojů a cílů.

Prakticky jde o část datových struktur a dalších metadat, která se vytvoří v závislosti na zvoleném pracovním módu. Existují dva druhy pracovního módu:

• FULL- pracovní data obsahují všechna metadata pro jednu konkrétní verzi modelu.
• DIFF- pracovní data obsahují pouze rozdíl mezi dvěma verzemi modelu. Výhodou je, že generování zdrojů, cílů a případně i hodnot parametrů se provádí jen nad novými nebo změněnými objekty.

Obrazovka v pravovním módu FULL se seznamem nových nebo změněných tabulek.

Zdroje a cíle

Přímo generovanými objekty IPC jsou zdroje a cíle. Generátor je na základě vybraného pracovního módu:

• Generuje do xml souboru na zvolené cestě.
• Importuje do repozitáře IPC.

Transformace

Transformace je obecná, logicky seskupená sada šablon. Obsahuje šablony pro workflow, mapping, session nebo i parameter file (včetně parameter section). Šablona se vytváří ze vzorového objektu (mapping, session, workflow) vyexportovaného z IPC. Typ šablony odpovídá typu exportovaného objektu. Schematicky je možné vytvoření šablony definovat jako následující sled kroků:

• Export vzorového objektu z IPC (xml soubory).
• Import objektu do generátoru, v případě mapování do aplikace Mapping Architect for Visio.
• Nastavení proměnných atributů objektu – parametrů (u mapování se provádí v aplikaci Mapping Architect for Visio).
• Ukončení definice šablony.

Obrazovka s výběrem a definicí parametrizovaných atributů šablony.

Import a export hodnot paramterů

Předpokladem pro generování objektů je import hodnot pro parametry příslušné šablony. Existují dva způsoby importu metadat:

• Z textového souboru formátu csv.
• Z databázového view vytvořeného v uživatelském schématu.

Příklad textového souboru s hodnotami parametrů.

Export je operací, kterou je možné s výhodou použít při opravě již jednou importovaného souboru nebo při vytváření souboru pro jinou šablonu, ale s podobnými parametry.

Generování a imporptování IPC objektů

Generování objektů je finální operací po vytvoření všech potřebných šablon a existuje ve variantách

• Generuje se do xml souboru.
• Importuje do repozitáře IPC.

Textové šablony

Textové šablony využívají technologii Apache Velocity a jsou integrované v generátoru. V rámci generátoru se šablony používají například v oblasti SQL dotazů používaných v ETL transformacích. Obvykle se jedná o shodné SQL dotazy/skripty, které se liší pouze v názvech tabulek, seznamu sloupců, spojovacích podmínkách atp. Takové SQL dotazy jsou parametrizovatelné a tedy vhodné pro generování.

Parametry v textové šabloně/skriptu.

The post Generátor kódu pro Informatiku – GTL Generátor appeared first on GTL Tools.

Klíčové vlastnosti

• Platformní nezávislost – GUI Master je na platformě nezávislé řešení. Podporuje webové aplikace, reportovací systémy, B2B, ERP, SAP, Infor, Navision, Oracle, Siebel, atd., a rovněž terminálové aplikace (např. AS400).
• Jednoduchost – jedno řešení pro všechny aplikace. Nejsou zapotřebí žádné dodatečné náklady na software nebo aplikační pluginy.
• Flexibilita – flexibilita GUI nástroje vysoce převyšuje ostatní “krabicové nástroje”. Funkcionalita může být rozšířena podle potřeby projektu. Testovací scénáře jsou přenosné mezi různými PC stejně, jako mezi operačními systémy Windows.
• Rychlá konfigurace testovacích scénářů – Vytváření scénář v nástroji GUI Master je velmi jednoduché a efektivní. Uživatel nepíše “testovací skript”, spíše staví testovací scénáře z prvků pomocí myši. Každá část testovacího scénáře mohou být znovu použita v jiném scénáři s jinými parametry.
• Programovací dovednosti nejsou nutné – nástroj nevyžaduje programovací / skriptovací dovednosti. Testovací scénáře jsou stavěny/spravovány v grafickém prostředí s podporou ladění scénářů.
• Daty řízené testování – v GUI Master jsou testovací data oddělena od scénářů a jsou uložena v souborech (xlsx/txt) nebo SQL databázi. Různé testovací scénáře jsou tak vytvářeny i výměnou dat v souborech/databázi.
• Automatické vyhodnocení výsledků testů – scénáře jsou automaticky vyhodnocovány podle zadaných pokynů. Dosažené výsledky mohou být porovnány s údaji chybové zprávy nebo reportu, nebo s hodnotami v souboru či databázové tabulce.
• Podrobný report – provádění testovacího scénáře (včetně screenshoty) včetně konečného výsledku je reportováno. Podporována je řada formátů včetně možnosti zaznamenání video sekvence z testu.
• Snadná integrace se systémy řízení testů – nástroj je plně integrován s většinou ALM aplikací např. SpiraTest, HP QC, nebo IBM Rational.
• Testovácí scénáře jsou rezistentní vůči změnám v testovaných aplikacích – GUI Master podporuje automatizované testování i v dynamickém prostředí, kde se testované aplikace často mění.

Princip fungování nástroje GUI Master

Při spuštění testovacího scénáře nad testovanou aplikací používá GUI Master rozpoznávání obrazu. Typický testovací scénář testování určuje transakci, která má být provedena, v ní použité parametry a vstupy parametrů. GUI Master na testované obrazovce hledá objekty (tlačítka, přepínače, combo boxy, seznamy, atd.) a postupně provádí požadované
akce (tj. zadání hodnot, výběr položky z menu či seznamu atd.). Přesná poloha objektů je irelevantní. Objekt lze na testované obrazovce nalézt kdekoli, včetně momentálně nezobrazených místech. Bitmapový vzorek může být rovněž dynamicky přizpůsoben novým úpravám (např. barvy, rozlišení obrazovky, nové písmo) testované aplikace. To činí testovací scénáře stabilní a jsou tak minimalizovány náklady na jejich správu i při častých úpravách v testované aplikaci.

GUI Master Editor

Nutným předpokladem pro automatizované GUI testování je rychlá a uživatelsky příjemná příprava testů. Pro tyto účely byla vyvinuta komponenta GUI Master Editor, která umožňuje rychlé a komfortní nastavení “klikacích“ maker testovacích scénářů. Libovolný blok připravených maker (např. přihlášení do testované aplikace) je možné uložit jako samostatný příkaz, který lze následně využít v dalších testovacích scénářích. V každé fázi přípravy lze samostatná či bloková makra spouštět a testovat tak jejich správnou funkčnost. Pomocí komponenty „Smart Action List“ je možné naprostou většinu maker nastavit stisknutím jediného tlačítka. Na základě vybraných vstupních parametrů (výběr se provádí pomocí myši) komponenta „Smart Action List“ nabídne seznam pouze těch maker, která dle vstupních parametrů přicházejí v úvahu a po výběru makra provede sama nastavení vstupních parametrů makra. Testovací scénář je v editoru zobrazován v grafické podobě pomocí stromové struktury.

GUI Master Launcher

Významným faktorem při testování je i otázka organizace testů, jejich vyhodnocení a průkazné reportování výsledků. Při reálném testování, kdy může být definováno až několik desítek testovacích scénářů, je tedy důležité mít mechanismy, které dovedou uživateli efektivně pomáhat. GUI Master Launcher je komponenta, která je určena pro provádění následujících operací:

• Vytvoření struktury testovacích scénářů a začlenění maker do těchto scénářů.
• Přípravu testovacích dat.
• Přípravu verifikací.
• Spouštění a vyhodnocení testů.
• Generování reportů o testování.

GUI Master Batch Runner

Přínos systému GUI Master se projeví především při opakovaném GUI testování. Při změnách lze automaticky provádět komplexní testování, které nespočívá pouze v otestování těch částí systému,které bezprostředně souvisejí s provedenými změnami (regresní testování), nýbrž otestováním systému jako celku a minimalizovat tak riziko případných kolaterálních efektů. V reálných případech se dá předpokládat spuštění (a vyhodnocení) řádově desítek až stovek testů. Pomocí komponenty GUI Master Batch Runner lze organizovat jednotlivé testy do dávek a tyto dávky automaticky spouštět. Při běhu dávky každý test generuje vlastní report, po doběhnutí dávky je generován navíc sumarizační report.

Příprava testovacích dat

Data, která GUI Master využívá v rámci testovacích scénářů lze uložit i do externích datových zdrojů – textových souborů, souboru aplikace MS Excel nebo databázových tabulek. V těchto datových zdrojích lze také připravit variantní sady testovacích dat na které se GUI Master připojí pomocí ovladače ODBC. Jako zdroj dat je možné využít i jiný systém. V takovém případě GUI Master vyvolá příslušnou transakci ze zdrojového systému, data načte a následně použije v testovacím scénáři.

Sběr dat z formulářů a verifikace výsledků

Pokud jsou data z obrazovkových formulářů ukládána do tabulek či souborů, lze provést verifikaci výsledků pomocí SQL příkazů, které systém QAceGen generuje a vyhodnocuje automaticky. V některých případech lze výsledky verifikovat pouze proti výstupním obrazovkám. Jedná se například o testování „front-end“ aplikací komplexních systémů, kde vnitřní struktura a ukládání dat není známa. V takovém případě umí GUI Master stáhnout požadovaná dat přímo z obrazovek, a to buď přímo (tzn. pomocí výběru dané oblasti), ev. pomocí zabudovaného systému OCR, které pak ukládá do textových souborů, které se pak dále používají pro verifikaci výsledků. Vyhodnocení výsledků lze pak provést spuštěním příslušných verifikátorů, které lze napsat v jakémkoli vyšším programovacím jazyce. GUI Master jako výchozí platformu používá jazyk Java. Stisknutím tlačítka se vygeneruje verifikační template, který lze pak dále dopracovat v některém dostupném vývojovém prostředí (NetBeans, Eclipse,…). Vzhledem k tomu, že na daném projektu se při verifikaci výsledků mohou v řadě případů využívat stejné postupy,je možné vytvářet knihovny kódů v jazyce Java,které přípravu verifikačních metod urychlují, případně lze takové připravené knihovny implementovat do systému GUI Master hned na začátku projektu.

Testování vstupních filtrů

V GUI aplikacích se velmi často vyskytuje technika kontroly vstupních dat na úrovni vstupních polí. Cílem je povolit uživateli vstup pouze požadovaných znaků (např. pouze čísla,ev. alfanumerické hodnoty,atd.). Při testování je pak nutno ověřit, že vstupní filtr pracuje správně, což v praxi znamená provést vstup i desítek znaků. Takových polí vstupních filtrů se ovšem ve formuláři může vyskytnout více, takže ruční testování vstupních filtrů se stává jak časově, tak i psychicky poměrně náročnou činností. GUI Master používá pro testování filtrů předdefinované makro, jehož vstupními parametry je seznam testovaných hodnot (tj. „zakázaných“ znaků, eventuálně formátů) a definice chybového stavu, kterým testovaná aplikace reaguje na vstup nepovoleného znaku/formátu. Seznam zakázaných znaků lze nadefinovat pomocí konstant řetězců, které si GUI Master sám „rozparsuje“ do seznamu vstupních parametrů. GUI Master při testování vkládá do příslušného pole všechny položky ze seznamu a očekává chybovou reakci aplikaci. Celý test je samozřejmě zdokumentován. Tímto způsobem lze automatizovat desítky/stovky testů vstupních hodnot a podle potřeby je kdykoliv opakovat.

Reportování výsledků

Nedílnou součástí testování je i reportování testů, které slouží jako o doklad o provedených testech. Systém GUI Master při provádění testů vytváří podrobný report pro každý testovací scénář automaticky. V reportu je zaznamenán nejen proces testování a výsledky, nýbrž odkazy na uložené soubory kopií obrazovek, tak aby bylo zřejmé, jak byly naplněny vstupní obrazovky daty, případně jak vypadaly výstupní obrazovky, ze kterých byla stažena data pro verifikaci výsledků.

Příprava GUI testovacích scénářů

Každá testovaná GUI aplikace ve své podstatě představuje množinu obrazovek,které jsou plněny vstupními daty podle daných business pravidel. Tato pravidla určují tedy i pořadí obrazovek včetně ošetřeních chybových stavů. Například založeni nového klienta do systému “XYZ” znamená naplnit vstupními daty několik formulářů a poté odeslat tyto naplněné formuláře stisknutím příslušného tlačítka dále ke zpracování. Takže dle předepsané logiky může může dojít k následujícímu větvení, a tedy možným testovacím scénářům. Testování pak spočívá v tom, že si připravíme pro každý testovací scénář takovou sadu dat, která musí projít příslušnou sekvencí obrazovek. Tzn., pokud by následující obrazovka byla jiná než očekávaná, systém ukončí test tohoto scénáře a chybu zaznamená do reportu. Samozřejmě součástí testů je i negativní testování, které spočívá v tom, jestli testovaná aplikace dovede reagovat na chyby tak, jak předepisuje daná business logika.

Efektivní GUI testování

Systém GUI Master představuje platformu pro efektivní testování GUI aplikací. Pomoci aplikace GUI Master lze rychle a uživatelsky příjemně připravovat makra pro testování GUI aplikací. Takto připravená makra lze pak jednoduše sestavit do přehledné struktury testovacích scénářů a jednoduchým způsobem pak zajistit spouštění a vyhodnocení testů, včetně důkladného zdokumentování celého procesu testování. Připravené testy lze kdykoliv opakovaně spouštět v plném rozsahu a zajistit tak komplexní provedení testů i při dodatečných změnách v projektu a minimalizovat tak rizika kolaterálních efektů při regresním testování.

The post Testovací nástroje – GTL GUI Master appeared first on GTL Tools.

• O 50% rychlejší příprava testovacích dat v porovnání s konvenčními metodami přípravy testovacích dat.
• 100% pokrytí testované logiky systému.
• Zvýšená transparentnost procesu testování.
• Zajištění komplexních testů (logiky systému, zátěžové testy, testy gui).
• Zvýšená bezpečnost produkčních dat.

Koncept

Efektivity výroby testovacích dat je dosaženo aplikací koncepce „focusing the point“, což v praxi znamená:

• Snadný přístup ke všem požadovaným informacím.
• Odstínění od neproduktivní činnosti.
• Koncentrace na vlastní řešení problému.

Práce s nástrojem je velmi efektivní. V každém okamžiku má tester detailní informace o datových typech, klíčích, omezeních (constraints) a vzájemných vazbách (relations) všech vstupních a výstupních tabulek/souborů. dalším faktorem, který významně urychluje generování dat, je automatické generování klíčů, omezení, filtrů a rekordů do referenčních tabulek. Stejně tak se automaticky generují hodnoty polí, které nejsou součástí „business logiky“. QAceGen tedy nabízí značnou komparativní výhodu zejména oproti situacím, kdy se testovací data vytvářejí „manuálně“. Vazby mezi daty v mnoha případech bývají natolik komplexní, že manuální výroba testovacích dat představuje velmi zdlouhavý a náročný proces, který navíc trpí značnou chybovostí. Oproti tomu systém QAceGen umožňuje testerům soustředit se pouze na „business logiku“ a takřka veškerou „neproduktivní práci“ obstará sám.
Poznámka:„business logika“ definuje pravidla, na základě kterých pracuje daná aplikace. Jedná se tedy o zadání, které se používá jak pro vývoj, tak i pro testování aplikace. QAceGen pracuje jako „business logic driven data generator“. To znamená, že generování dat je řízeno logikou testované aplikace. „Business logic“ aplikace se rozdělí do elementárních testovacích jednotek – scénářů. scénáře jsou pak popsány v nativním jazyce dgl (data generation language). QAceGen na základě takto definovaných scénářů generuje testovací data, popřípadě testy. Pro každý scénář se tedy vygeneruje sada rekordů v souladu s danou logikou. Výsledkem takového přístupu je, že se vygenerují data, která pokrývají každou logickou větev dané business logiky. QAceGen lze označit jako „samo-dokumentovatelný“. Rozdělením „business logiky“ do testovacích scénářů vzniká logická struktura testovacího projektu, která se dokumentuje pomocí komentářů jak na úrovni celého projektu, tak na úrovni jednotlivých testovacích scénářů. Komentáře lze pak v dané logické struktuře kdykoli exportovat do textového formátu a tento dokument může pak být následně distribuován všem kompetentním účastníkům projektu k posouzení. Zmíněný mechanismus tak minimalizuje možnost „nekonzistence“ mezi skutečným stavem a dokumentací. Generování testovacích dat probíhá ve dvou úrovních:

• Data pro logický test.
• Data pro zátěžový test.

Pro logický test systém generuje data, která testují „business logiku“. V tomto případě systém generuje pouze určité minimální množství záznamů (cca tisíce), které je nezbytně nutné pro otestování všech logických větví testované aplikace. Poté, co je aplikace otestována z hlediska logiky, systém může generovat data pro zátěžový test, tzn. určí se počet záznamů, který bude testovaná aplikace za normálních podmínek zpracovávat (stovky tisíc, miliony). Zátěžový test ověřuje reálný chod testované aplikace, eventuálně simuluje extrémní zátěž, která může nastat.
Poznámka: QAcegen vždy generuje komplexní data, která zahrnují celou „business logiku“. Pokud dojde ke změně dané logiky, pak následný test testuje celou logiku, a nikoli pouze změny. Komplexní test tak může odhalit případné kolaterální efekty, které by se v případě inkrementálního testování (tj. Testují se pouze změny) nemusely projevit.
QAcegen umožňuje jednoduchý transport generovaných dat do všech zdrojových souborů a tabulek. Metadata každé tabulky/souboru jsou svázána s konkrétním zdrojovým profilem, který definuje umístění a přístup k danému zdroji (databáze/adresář). Stisknutím tlačítka „transport dat“ jsou data automaticky nasměrována do příslušných zdrojů. Pokud testovací scénář zahrnuje i verifikaci výsledků, QAceGen vytváří podrobný protokol o každém testování. Výsledky jsou vizuálně zobrazeny v grafickém prostředí a poskytují tak okamžitý přehled o výsledcích. Výsledky lze rovněž exportovat do textového formátu v dané logické struktuře projektu, spolu s celkovým vyhodnocením správných/chybových scénářů. Nezanedbatelný je i bezpečností faktor. Při přípravě testovacích dat v prostředí qacegen aplikace nevyužívá produkční data. Zmenšuje se tedy okruh lidí, kteří přichází do styku s citlivými produkčními daty.

Oblasti využití

QAceGen je možno použít pro následující oblasti testování:

• Generování dat (vývoj, školení,…).
• Testování ITO aplikací.
• „Data quality management“.
• Automatické testování gui aplikací a testování terminálových aplikací.
• Testování v prostředí heterogenních systémů.

Poznámka: ITO = input /transformation /output
ITO aplikace je taková aplikace, která bere data ze vstupních tabulek/souborů, transformuje tato data pomoci dané „business logiky“ a výsledky ukládá do výstupních tabulek/souborů. Generování dat probíhá na základě specifikace zadání, která definuje chování aplikace (business logic). Tato business logika je rozčleněna do scénářů (elementárních logických větví). Logika scénáře je popsána v jazyce dglL a QAceGen pak pro každý scénář vygeneruje sadu záznamů, které zaručují průchod touto logickou větví a její otestování. Testování ito aplikací zahrnuje navíc verifikaci výsledků, které vzniknou spuštěním testované aplikace nad generovanými daty. Do scénářů jsou kromě dgl příkazů pro generování dat přidány navíc příslušné verifikační příkazy, které zajistí ověření výsledků. Data quality management (dqm) je řešení, které qacegen nabízí pro kontrolu kvality dat. Kontrola zahrnuje sledování:

• Duplicit.
• Kardinalit.
• SCD2 (slowly changing dimensions type2 – historizace, incidence, apod).

Pomocí jednoduchých příkazů v jazyce dgl, můžeme nastavit požadovanou kontrolu pomocí pouze několika parametrů pro libovolnou tabulku nebo join. Příkazy pak generují sadu kontrolních sql příkazů, které QAceGen automaticky vyhodnocuje a výsledek zaznamená do standardního reportu, který obsahuje všechny použité příkazy včetně výsledků. Dqm testy mohou běžet buď nad celou tabulkou, nebo můžeme nastavit v procentech požadovaný vzorek dat. Testy lze spouštět i automaticky formou „batch“ souborů a jejich běh můžeme naplánovat na požadovanou dobu. Reporty lze pak posílat na určité e-mailové adresy k vyhodnocení. Díky tomuto mechanismu lze snadno a rychlé vytvořit kontroly nad desítkami až stovkami tabulek v různých databázích. V případě potřeby qacegen umožňuje snadnou a rychlou implementaci dalších dqm příkazů.

Výhody použití

• Nízké projektové náklady.
• Časová úspora.
• Dokumentované testování.
• Zvýšená bezpečnost dat.

The post Testovací nástroje – GTL QAceGen appeared first on GTL Tools.

Hlavní oblasti

• Definice extraktů resp. view.
• Definice mapování dat.
• Definice tabulek.
• Generování výstupů.
• Validace a generování skriptů.
• Podpora řízení změn.

Integrace active directory

MDC je navržen jako webová aplikace (tenký klient), což umožňuje spolupráci více uživatelů nebo týmů. Integruje se s Active Directory (AD) a jeho oprávnění jsou namapovány do skupin AD uživatelů. Přístup do oblastí vč. editace, generování výstupů a správy může být omezeno nastavením práv. Základní MDC role jsou: správce aplikace, BI architekt, data modeler, BI analytik a ETL developer.

Extrakt/view definice

Zdrojové systémy plněnící datový sklad jsou definovány buď rozhraním nebo datovými exktrakty. MDC může importovat definice z aplikací Excel a Sybase PowerDesigner nebo z SQL souborů prostřednictvím formulářů či webových služeb API. Definice lze exportovat do Excelu nebo pomocí uživatelsky definovaných skriptů (viz dále).
Další operace zahrnují tvorbu definic (včetně definic polí a technických informací), správu verzí, validaci, vyhledávání, porovnávání, označení změnového řízení a generování výstupu (např. XML kód pro Informatica PowerCenterem, kód SQL – DDL i DML, check plans, parametrické soubory).Stejně tak lze definovat a spravovat indexy.

Definice mapování dat

MDC podporuje definice mapování dat pro tabulky nebo extrakty používané v v DW. Tato mapování obsahují jednoduchá i komplexní transformační pravidla. MDC umožňuje definice importovat z SQL nebo Excelu, nebo je přímo vytvářet. Stejně jako u extraktů, definice mapování zahrnují správu verzí, validaci, porovnávání,označení změnové řízení a generování výstupů. Formulář mapování lze použít rovněž pro definice komplexních view.

Definice tabulek

Definice tabulek v Power Designeru lze importovat přímo nebo voláním webové služby (VBScript). Tyto definice jsou importovány do několika oblastí jen pro čtení, ale mohou se použít jako cílové objekty v mapování dat. Správa verzí, porovnání a generování výstupů jsou opět k dispozici.

Skripty

Validace a generování skriptů se provádí prostřednictvím formuláře pro správu skriptů, který používá vlastní jednoduchý jazyk, podobající se VB skriptu. Kontrola a zvýraznění syntaxe je k dispozici pro textový editor PSPad. To uživateli umožňuje vytvořit skript v textovém editor PSPad a poté jej nahrát..

Validace skriptů

MDC obsahuje skriptovací “engine”, který se používá pro validaci extraktů,tabulek a mapování. Skripty lze plně přizpůsobit. Mimo jiné je možné ověřit logické vztahy mezi entitami nebo, ve složitějších případech, kontrolovat definované vlastnosti proti vzdáleným databázím. Z důvodu optimalizace výkonu jsou skripty zkompilovány. Správu zajišťuje správce aplikace a MDC je aplikuje automaticky..

Generování skriptů

MDC skriptovací “engine” se používá rovněž pro generování výstupů, což je jedna z hlavních výhod aplikace.
Stejně jako u validace lze generování skriptů plně přizpůsobit, předkompilovat a přístup k nim regulovat. Hlavními výstupy jsou:

• Definiční SQL skripty (tabulky, statistiky, indexy, view, atd.).
• SQL historizace.
• SQL dotazy.
• Definice zdrojů/cílů pro Informatica PowerCenter.
• Parametrické soubory a “check plans”pro Informatica PowerCenter.
• Mapování a workflows pro Informatica PowerCenter.

Správa verzí, uzamykání

Všechny hlavní objekty jsou součástí MDC správy verzí.Aplikace umožňuje definovat buď konečné nebo pracovní verze. Každá verze sebou nese auditní informace: autora verze, časovou značku, číslo verze, označení změnového řízení a archivní časovou značku. Upravovaná verze je uzamčena pro ostatní uživatele, kteří ji mají k dispozici pouze pro čtení nebo generování výstupů.

ETL soubory

MDC podporuje definici odvozených ETL souborů. Soubory jsou založeny na definicích extraktů, tabulek nebo jejich kombinací. Obvykle jsou používány pro obohacení extraktů o cílové primární klíče.

Release management

Prostřednictvím dynamicky definovaných formulářů MDC podporuje procesní řízení. Poskytují podporu pro SLA, rozšíření systému nebo řízení změn. Funkčnost zahrnuje správu verzí, porovávání, seznam odpovědných osob, dynamické formuláře, pohledy, generování výstupů atd.
Všechny významné objekty mohou nést označení změnového řízením a podporovat tak “release management”. Mapování lze “zamknout”do vývojového stavu, a efektivně je tak sdílet mezi analytiky a vývojáři.

API

MDC API pokrývá dvě hlavní oblasti: import definic tabulek a generování skriptů.

The post Správa metadat – GTL MetaData Center appeared first on GTL Tools.

Vstupní skupiny komponenty

• Vstupní skupina working obsahuje data ke zkonsolidování s historickými daty, tedy snímky stavu dat za určité období – skupina může obsahovat jenom změny dat nebo celý časový snímek.
• Skupina target obsahuje historická data, to znamená historii každého záznamu/objektu. Data jsou konsolidována s daty ze vstupu working.

Výstupní skupiny komponenty

• Skupina output – nové záznamy, které je potřeba přidat k historickým datům, aby zachycovaly zkonsolidované změny.
• Skupina original – na tento výstup jsou posílány target záznamy, kterým má být zkrácena platnost, protože na vstup přišel working záznam se změněnými atributy nebo záznamy, které se v novém snímku vůbec nevyskytují a platnost má být ukončena.

Vstupní a výstupní skupiny komponenty.

Konsolidační plán – přehled hodnot typu portu