Dávkové zpracování využijí i koncoví uživatelé

Snad každá implementace ERP s sebou přináší potřebu plánovat a vykonávat operace v dávkovém režimu. Příkladem je pravidelná rezervace zboží nebo fakturace uskutečněných prodejů. Dávkové zpracování však využijí i koncoví uživatelé pro jednorázové spuštění operací, které jsou náročné na výpočetní výkon – např. vytvoření reportu nebo spuštění uzávěrky na konci fiskálních období.

Microsoft Dynamics AX dávkové zpracování podporuje už od svých raných verzí. S každým novým vydáním vždy přichází řada důležitých změn – zatímco Axapta 3.0 zpracovávala dávkové úlohy pomocí vyhrazeného klienta, AX 2009 přišla s konceptem serverového zpracování. AX 2012 pak přinesla další výrazné zvýšení výkonu díky přesunu dávkového zpracování do světa .NET frameworku.

V Blue Dynamic máme s provozováním dávkových úloh na různých prostředích u různých zákazníků bohaté zkušenosti. V následujícím textu se chceme formou pěti tipů podělit o některé cenné poznatky a zkušenosti, které jsme při tom získali. V dalším textu se budeme odvolávat na balíček Blue Dynamic Batch s aplikačními úpravami, které jsme při řešení problémů spojených s provozem dávek vyvinuli.

Tip 0: Trocha teorie nikoho nezabije?

Každá dávková úloha sestává z hlavičky (Dávková úloha) a jednoho či více řádků.

Aneb toto ještě žádný tip není. Pro snadnější psaní je však potřeba udělat si trochu jasno v názvosloví. Každá dávková úloha totiž sestává z hlavičky (Dávková úloha) a jednoho či více řádků (Dávkový úkol). Český překlad zde není úplně šťastný, význam slov úloha a úkol v obecné češtině je prakticky shodný.
Anglické texty jsou v tomto ohledu výstižnější – hlavičky se jmenují Batch jobs a řádky Batch tasks – a proto se anglické terminologie v dalším textu přidržím, jazykoví konzervativci snad prominou.

Důležité je vědět, k čemu Batch jobs a Batch tasks slouží a jak k nim přistupuje Microsoft Dynamics AX. Batch jobs definují chování dávky jako celku – aktuální stav, časový rozvrh zpracování včetně opakování, datum a čas příštího běhu. Batch tasks oproti tomu představují konkrétní kroky v dávkovém zpracování – definují, jaké akce se mají vykonat a s jakými parametry (zde se definují např. vstupní filtry). Mezi jednotlivými kroky pak lze definovat závislosti a tím stanovit správné pořadí zpracování, popř. umožnit zpracování paralelní.

Tip 1: Dobré pojmenování jako základ

Provozujeme-li v řešení Dynamics AX pět dávek, pak na jejich názvech příliš nesejde, přehlede nad tím, jaké dávky v systému běhají, si snadno udržíme. Postupem času se však situace většinou začne komplikovat. Některé dávky mají běhat pouze přes den, jiné naopak jedině v noci. Některé dávky chceme pouštět každých pár minut v režimu „zpracovat pouze změny“ a pak pro jistotu jednou za den v režimu „zpracovat vše“ (dobrým příkladem jsou např. přenosy kmenových dat maloobchodu z centrály na jednotlivé obchody). Některé dávky jsou časově tak náročné, že se rozhodneme systému poněkud ulevit a zpracovat vždy jen úsek dat (např. při hledání duplicit v milionovém seznamu zákazníků začneme s těmi, jejichž příjmení začíná od písmene A). A tak dříve či později zjistíme, že seznam aktivních dávek vydá na několik obrazovek.

Je tedy rozumné zavést do zmatku hned od počátku systém. Osvědčilo se nám pro pojmenování dávek používat názvy s různými prefixy. Ty mohou mít i několik úrovní. Jako příklad uvádíme dvouúrovňové názvy podle toho:

• Zda běží ve dne (D) nebo v noci (N)
• Jaké oblasti (modulu) se týká – např. logistika (LOG), finance (FIN), administrace (ADM) atd.

Dávka se pak může jmenovat např. N-FIN-Update balances for dimension set Ucet.

Výhody tohoto systému jsou nasnadě – při seřazení podle názvu dostaneme tematicky příbuzné dávky k sobě. Navíc snadno odlišíme dávky, které jsou řádně zaplánované a nastavené, od dávek, které ad-hoc spustil běžný uživatel. V neposlední řadě se pak z názvu dávky můžeme dozvědět informace o jejím věcném obsahu a rozvrhu běhu.

Tip 2: Administrátor na dovolené

Řekněme, že máme Batch job s třiceti Batch tasks, z nichž každý má nastaven nějaký složitý filtr. Mezi jednotlivými Batch tasks jsou navíc definovány složité závislosti. Po čase přijde požadavek přidat ještě jeden Batch task. Administrátor Petr, který původní Batch job definoval, je na dovolené, a tak je řešením pověřen Pavel. Ten postupně odhaluje, že k dokončení úkolu musí být přihlášen jako administrátor a že stav hlavičky musí být Withold (český překlad Srážka je zcela mimo realitu). Nakonec však zjistí, že úkol stejně není schopen dokončit – při založení nového záznamu v Batch tasks obdrží celkem nic neříkající chybové hlášení Cannot create a record in Batch transactions (Batch). The corresponding AOS validation failed. Se stejnou by pořídil, nebo spíše nepořídil, pokud by chtěl pouze změnit závislosti mezi existujícími Batch tasks. A co teď?

• vlastník dávky, tj. ten, kdo původní definici dávky vytvořil
• systémový administrátor
• ani jeden z výše uvedených

První a třetí případ představují dva extrémy. Vlastník dávky může se svou dávkou nakládat dle libovůle. Naproti tomu obyčejný uživatel bez administrátorských oprávnění nemůže s cizí dávkou provádět nic. Zajímavý je případ druhý – administrátor, který není autorem dávky. Ten může měnit údaje týkající se samotného vykonávání dávky – např. ji pozastavit nebo naplánovat podle nového rozvrhu. Nemůže však měnit dávku po věcné stránce – nemůže vytvářet nové Batch tasks, stávajícím záznamům Batch tasks měnit parametry (např. vstupní filtry), ani měnit samotnou akci (tj. název třídy). Důvodem pro tato omezení je umožnit audit změn – nelze připustit, aby Pavel provedl změny nastavení dávky vedoucí k nežádoucímu chování, a to vše jménem Petra. Pavel má teď tedy dvě možnosti – buďto sehnat Petra nebo vytvořit definici Batch jobu pěkně od začátku, svou vlastní.

Abychom nenarušili principy auditu a současně umožnili administrátorovi Petrovi odjet na dovolenou, vyvinuli jsme v balíčku Blue Dynamic Batch novou funkcionalitu. Namísto hodnoty pole „Vytvořil“ používáme pro potřeby auditu nové pole „Vlastník dávkové úlohy“. Jeho hodnota je po založení dávky stejná jako hodnota v poli Vytvořil, ale je jí možno změnit pomocí funkcionality „Funkce Převzít vlastnictví“.

Po převzetí vlastnictví pak může Pavel provést požadované změny, samozřejmě už svým jménem. Hodnota „Vlastník dávkové úlohy“ se propisuje i do historie dávkového zpracování, takže můžeme snadno zjistit, kdy ke změně vlastnictví došlo.

Tip 3: K čemu jsou a k čemu nejsou skupiny dávek

Začněme tím, k čemu skupiny dávek dobré nejsou – nehodí se k organizaci práce s jednotlivými Batch jobs. Důvod je prostý – skupina dávek je příznak na záznamu Batch task, nikoli Batch job. Pokud nastane nutnost lépe organizovat Batch jobs, je potřeba zavést pořádek v pojmenování dávek, viz Tip 1.

K čemu skupiny dávek tedy dobré jsou? Hlavním smyslem je možnost zpracovávat různé Batch tasks na různých AOS serverech. V instalacích, kde dávkové úlohy zpracovává pouze jeden AOS server, nám postačí i jediná skupina dávek (pro tyto účely se po instalaci AX automaticky vytvoří skupina bez názvu). Jsou však situace, kdy se rozdělení úloh na jednotlivé AOS může hodit. Příkladem mohou být dávky náročné na výpočetní výkon nebo dávky vyžadující nějaký speciální zdroj, který je k dispozici pouze na některých AOS serverech.

V Blue Dynamic jsme přemýšleli, jak by mohly posloužit skupiny dávek ještě lépe. Jedním z problémů, se kterým se při provozování dávek často potýkáme, je vzájemné negativní ovlivňování dvou nebo více současně běžících dávek. Občas se kupříkladu potkají dávky maloobchodu „Zaúčtovat zásoby“ a „Zaúčtovat výkaz“. Běh dávky „Zaúčtovat zásoby“ je naplánován každých 10 minut, zatímco dávka „Zaúčtovat výkaz“ má běžet jednou denně po uzavření pokladen. Přitom dávka „Zaúčtovat zásoby“ běží po uzavření pokladen „naprázdno“ – z logiky věci je jasné, že žádné nové transakce nepřijdou. Kdyby se tedy dalo nastavit, aby dávka „Zaúčtovat zásoby“ běžela jen do určité hodiny a pak zase až druhý den ráno, mohli bychom snadno takovéto kolizi zabránit a ušetřit si tak nelehký úkol zjišťovat, jak se tyto dvě dávky navzájem ovlivňují a jak je přepsat tak, aby s paralelním během počítaly.

Výše uvedený problém lze ve standardní AX řešit pouze použitím více aplikačních serverů. Vytvoříme dvě skupiny dávek – DEN a NOC. Dávku „Zaúčtovat zásoby“ zařadíme do skupiny DEN a dávku „Zaúčtovat výkaz“ do skupiny NOC. První AOS nastavíme tak, aby běžel v době od 8:00 do 22:00 a aby zpracovával pouze skupinu dávek DEN. Druhý AOS pak nastavíme tak, aby běžel v době od 22:15 do 7:45 (necháváme si 15 minutovou rezervu na doběh déle běžících dávek) a zpracovával pouze skupinu dávek NOC.

Co však dělat v případě, kdy použití dalšího AOS serveru není možné? Problém vyřešíme přidáním možnosti zadat rozvrh na úrovni skupin dávek.

Po této úpravě, která je součástí balíčku Blue Dynamic Batch, si vystačíme s jediným AOS serverem, a přesto ke konfliktu nedojde.

Tip 4: Když se dávky začnou „samy množit“ a „bezejmenná“ skupina dávek

V tomto tipu se vrátíme k naší dávce „Zaúčtovat výkaz“ z předchozího tipu. Zákazník provozuje síť prodejen a používá modul AX Retail. Přes den prodává a tržby eviduje v POS. Večer se provedou uzávěrky pokladen a data se přenesou do AX. V AX se pak vytvoří výkaz, který je potřeba zaúčtovat. Protože chceme vše provozovat automaticky, je úloha pro zaúčtování výkazu naplánována jako noční job. Těsně po zaplánování máme tedy Batch job s názvem „Zaúčtovat výkaz“, který má jeden Batch task se stejným názvem a se skupinou dávek NIGHT. Poté, co započne zpracovávání této dávky, se však najednou objeví nové Batch tasks, které tam předtím nebyly. Co jsou zač?

Některé dávkové úlohy jsou totiž napsány tak, že si celkovou práci rozdělí do menších celků a tyto celky se potom zpracují paralelně ve více Batch tasks. Mezi těmito dynamickými Batch tasks mohou být definovány i závislosti – např. lze na konec zařadit finální Batch task, který má na starosti úklidové činnosti, které mohou proběhnout teprve tehdy, až doběhnou všechny Batch tasks.
S touto pěknou funkcionalitou je spojena jedna záludnost. Dynamicky vytvořené Batch tasks totiž nemusí mít stejnou skupinu dávek jako původní Batch task, přesné chování určuje programátor při vývoji dávky. K čemu to může vést je zjevné – pokud mají dynamicky vytvořené Batch tasks přiřazenu skupinu, jejíž vykonávání je pozastaveno, pak nebudou nikdy spuštěny a dávka jako celek zůstane „viset“ ve stavu Zpracování.

Tuto situaci ilustruje následující obrazovka – poslední tři Batch tasks mají přiřazenu skupinu dávek beze jména. Pokud je zpracování skupiny dávek beze jména pozastaveno, nikdy se účtování výkazu nedokončí.

Jde vlastně o typický případ – dynamicky vytvořené Batch tasks budou mít pravděpodobně stejnou skupinu dávek jako hlavní Batch task nebo prázdnou. Protože vnitřní logiku tvorby dynamických Batch tasks nelze vždy ovlivnit, jeví se jako dobrý nápad zpracovávání skupiny dávek bez jména nijak neomezovat. To je důležité i z jiného důvodu – jednorázové dávky spuštěné ad-hoc koncovými uživateli budou mít velmi často právě skupinu dávek beze jména, protože tito méně zkušení uživatelé často skupinu dávek opomenou uvést.

Tip 5: Jak si zajistit klidné spaní

V nočních hodinách často běží dávky, jejichž zdárným dokončením je podmíněno správné fungování firmy příští den – může jít například o hlavní plán generující návrhy objednávek a doplňování prodejen nebo dávku připravující práci pro vyskladňování z centrálního skladu.

Vesměs jde o relativně komplikované úkoly, na které číhá mnoho překážek, kvůli kterým nemusí pokaždé dobře doběhnout. Navíc jde o dávky trvající delší dobu, takže na opravu druhý den ráno nemusí být dostatek času. Proto je velmi důležité rychle reagovat na problémy, které s během těchto dávek souvisejí.

Jedná se vesměs o relativně komplikované úlohy, které nemusí doběhnout. Důležité je rychle reagovat na problémy, které souvisejí s dávkami.

Standardní AX v tomto směru nabízí použití alertů. Pro každou dávku je možno nechat AX vytvořit alert, pokud nastane jedna z událostí:

• dávka je řádně dokončena
• dávka skončí s chybou
• dávka je zrušena

Alerty si může administrátor prohlédnout v aplikaci AX nebo nechat zaslat e-mailem na předem určenou adresu.

Funkcionalita alertů je bezpochyby užitečná, pro zajištění klidného spaní však nepostačí. Problém nastane tehdy, když se dávka vůbec nezačne zpracovávat, nebo její zpracování trvá neobvykle dlouhou dobu. Častou příčinou prodloužené doby trvání může být negativní interakce s jinou výpočetně složitou úlohou.

Často také AX není jediným systémem ve firmě, který se na úspěchu příštího dne podílí. Firmy často provozují samostatně CRM, e-shop, POS systémy atd. V takových případech roste náročnost dohledu nad celým ekosystémem a je vhodné začít monitorovat infrastrukturu z jednoho centrálního místa. Pak se jeví aletry jako nesystémové řešení a je nutno namísto toho napojit AX dávky do centrálního monitoringu.

Blue Dynamic úspěšně používá ve spojení s monitoringem dávek systém Check MK. Vyvinuli jsme skripty, které umožní u kritických dávek sledovat jejich běh – zda započalo zpracování ve stanovenou dobu, jaký je progres a zda do předepsané doby doběhnou – a reagovat na vznik kritických situací zasláním SMS zprávy na telefon podpory. V současné době pracujeme na zobecnění a možnosti zadávat parametry související s monitoringem přímo v prostředí AX.

Naše řešení Batch Jobs Manager

Naše řešení Batch Jobs Manager pro Dynamics AX můžete zakoupit jako Addon pro Dynamics AX na obchodě s Addony a aplikacemi pro Dynamics AX – Addons.Blue.

Ondřej Liberda působí jako Dynamics AX developer/Architekt ve společnosti Blue Dynamic a má zkušenosti s řízením nasazování dávek vývoje.