Novinky

Více než 30 IDM realizací v České republice i zahraničí

AMI Praha Paralelizace běhu workflow – Sun Identity Manager
Paralelizace běhu workflow – Sun Identity Manager

Paralelizace běhu workflow – Sun Identity Manager

Ve své praxi jsem se setkal s workflow, která měla za úkol zpracovávat velké množství uživatelů v omezeném čase. Pokud by zmíněný proces byl čistě sekvenční, to znamená, zpracovával uživatele za uživatelem, nebylo možné časové lhůty dodržet. Bylo nutné výpočetní výkon workflow paralelizovat a právě o tom pojednává tento článek.

Trocha teorie na začátek. Spuštěná workflow (WF) Sun Identity Manageru (IdM) jsou typ objektu TaskInstance. Vlastní definice WF je uložena v objektu typu  TaskDefinition či Configuration (sub-WF). Každé spuštěné workflow běží právě na jednom IdM serveru a během svého životního cyklu se může nacházet v některém z těchto stavů:

  • Ready – úloha čeká spuštění procesem Scheduler (typicky tento stav trvá jen několik vteřin)
  • Executing – úloha se právě zpracovává
  • Suspended – úloha se nachází v akci ManualAction (typicky čeká na vstup od uživatele)
  • Finished – úloha byla dokončena

Představme si nyní, že máme 10 000 uživatelů, které je třeba zpracovat zhruba 10x rychleji než je tomu při sekvenčním běhu. Jistě je možné vytvořit 10 samostatných WF (TaskDefinition), každé bude v sobě držet svůj díl seznamu uživatelů. Jednotlivá WF je pak sice třeba zvlášť spustit, ale výsledku je dosaženo. Pokud bude dostatečný výkon hardware a nebudou žádná výrazná úzká hrdla (např. komunikace s IdM DB), zpracování uživatelů se provede 10x rychleji. Reálně je to vždy o něco méně, nepočítaje čas nutný k sestavení 10 různých WF.

Předchozí řešení opravdu může stačit, pokud jde o jednorázové záležitosti jako je např. import dat. V případě, že se jedná o opakovanou úlohu či dokonce o úlohu ovládanou správcem IdM bez možnosti napsat si v XPRESSu vlastní WF, je nezbytné logiku paralelizace zavést přímo do WF.

Takže, jak na to? Je to celkem jednoduché (opravdu :-). Stačí do vašich WF přidat následující logiku XPRESSu:

<block>
<defvar name=’tt‘>
<new class=’com.waveset.object.TaskTemplate‘>
<invoke name=’getObject‘>
<invoke name=’getLighthouseContext‘>
<ref>WF_CONTEXT</ref>
</invoke>
<s>TaskDefinition</s>
<s>AMI ML WF</s>
<map/>
</invoke>
</new>
</defvar>
<invoke name=’setSubject‘>
<ref>tt</ref>
<invoke name=’getSubject‘>
<invoke name=’getLighthouseContext‘>
<ref>WF_CONTEXT</ref>
</invoke>
</invoke>
</invoke>
<invoke name=’setVariable‘>
<ref>tt</ref>
<s>seznamUzivatelu</s>
<ref>seznamUzivatelu</ref>
</invoke>
<invoke name=’runTask‘>
<invoke name=’getLighthouseContext‘>
<ref>WF_CONTEXT</ref>
</invoke>
<ref>tt</ref>
</invoke>
</block>

Tento kód pouští TaskDefinition AMI ML WF. Pouští jej pod právy aktuálního uživatele a předává mu atribut seznamUzivatelu. Kód obalte logikou iterace (např. dolist) tak, aby se spustil vícekrát dle potřeby. Takto spuštěné WF je vidět samostatně v Server Tasks a Scheduler IdM jej pak může pustit i na jiném serveru než „mateřské“ WF.

Aby byl proces dokonale asynchronní, je ještě třeba změnit v TaskDefinition volaného WF (zde AMI ML WF) hlavičku objektu a nastavit atribut execMode=’async‘. Pokud by se Vám stalo, že spuštěné WF přesto v Server Tasks neuvidíte, nastavte ještě atribut resultLimit třeba na hodnotu 3600 – WF zůstane uložené po dobu 3600 vteřin jako finished.

Výhodou tohoto přístupu je možnost programově řídit počet paralelní „vláken“ úlohy. Vlastně, to může být i jeden ze vstupních parametrů celého WF definovaných ve spouštěcím formuláři uživatelem. Nevýhodou je pak kromě vyšších HW nároků i to, že mateřské WF ztrácí kontakt na podřízené úlohy. Je asynchronní a tak už se nedozví výsledek. I to se ovšem dá ošetřit a komunikaci mezi úlohami zajistit například přes databázi, přičemž volající úloha v pravidelných cyklech kontroluje, zda podřízené úlohy už doběhly.