Řídící nástroj s maximalizovaným paralelním zpracováním navržený do heterogenního prostředí datových skladů. Pracuje nad Java aplikačním serverem. Řízení procesů v aplikaci založeno na definici závislostí mezi úlohami a zdroji (např. zámek, soubor, tabulka apod.). Úlohy jsou spouštěny, když jsou splněny jejich závislosti na jiných úlohách nebo jiných objektech. Konkrétní řazení a velikost paralelizace je ponechána přímo na nástroji, který procesy řídí. Jde o nejefetivnější způsob řízení vlkého množství na sobě závislých úloh. Uživatelské rozhraní je webová aplikace, která, prostřednictvím předdefinovaných uživatelských rolí, umožňuje efektivně monitorovat a administrovat každodenní zpracování.

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.