Archiv pro štítek: Oracle

Jak zrychlit načítání dat z personálního systému VEMA?

Pří správě uživatelských účtů Identity Managerem je vždy jeden, nebo více systémů, autoritativní zdroj informací o uživatelích. Údaje o uživatelích jsou v pravidelných intervalech načítány a dále se propagují do dalších systémů. Jelikož počet takových uživatelů může být velký, tak je neefektivní je načítat všechny, protože u většiny uživatelů nedojde k žádné změně. Ideální řešení je takové, že Identity Manager načítá z autoritativního systému pouze ty uživatelské záznamy, které byly od posledně modifikovány. To však lze pouze v případě, že daný systém u záznamů uživatele ukládá čas poslední modifikace. Personální systém Vema, který je u našeho zákazníka pro CzechIdM autoritou pro identity, neposkytuje pouze změnové záznamy. Proto jsme si museli poradit sami a to jednoduše. V databázi Oracle, kam se provádí z personalistiky full-export, jsme zajistili evidenci změn a tyto změny poskytujeme do CzechIdM. Tím bylo možné rapidně zrychlit načítání autoritativních dat. Proces, který dříve trval až 13 hodin, byl nahrazen procesem, který trvá řádově minuty! Pojďme se na to podívat blíže.

Počáteční stav

Zdrojem autoritativních dat je personální systém Vema. Z personálního systému se provádí každý den full-export do Oracle DB, ze které si je mohou načítat externí aplikace. Export probíhá tak, že se nejprve smažou všechna data včetně samotných databázových tabulek, opět se vytvoří databázové tabulky a následně se do nich vloží aktuální data personálního systému. CzechIdM načítá data o uživatelích právě z exportní Oracle databáze. Na základě načtených dat inicializuje personální procesy a propaguje změny na další napojené systémy. Například při nástupu nového zaměstnance CzechIdM načte jeho popisné údaje z Oracle databáze, založí mu identitu v CzechIdM a na základě jeho funkčního zařazení mu přidělí role, dle kterých se pro něho automaticky vytvoří účty na dalších systémech zákazníka (založí se mu email, účet v docházkovém systému atd.). S tím, jak se rapidně navyšujel počet načítaných uživatelů a počet napojených koncových systémů, tak se samozřejmě prodlužuje i samotný proces rekonciliace. Bylo tedy potřeba od něho upustit a přejít k synchronizaci. Problémem však bylo, že personální systém neexportuje s uživatelskými daty informace o času jejich poslední modifikace. Dříve, než se podíváme, jak jsme daný problém vyřešili, tak si pro jistotu vysvětlíme co znamenají výše uvedené pojmy rekonciliace a synchronizace. :-)

Synchronizace vs rekonciliace

Pojem rekonciliace v původním významu označuje proces usmíření, uvedení věcí do souladu. Tato definice poměrně přesně popisuje rekonciliaci i z pohledu Identity Managementu. Při rekonciliaci se prochází všechny uživatelské účty na koncovém systému a na základě definovaných akcí se aktualizují identity uživatelů v Identity Manageru. V našem konkrétním případě, kde koncovým systémem je personalistika, se na základě načtených dat aktualizují identity uživatelů, případně se vytváří identity nové pro nově evidované zaměstnance. Jelikož je personální systém v tomto případě systémem autoritativním, tak se popisné atributy automaticky propagují do koncových systémů, na kterých mají uživatelé založeny účty. Zde lze vidět analogii k původnímu významu slova rekonciliace. Identity manager uvede do souladu atributy uživatele na jeho účtech na koncových systémech s atributy, jenž jsou uvedeny dle personálního systému. Synchronizace, na rozdíl od rekonciliace, neprochází všechny uživatelské účty na koncovém systému. Místo toho si zjistí, které účty byly modifikovány od poslední synchronizace a dále pracuje pouze s nimi. V našem případě, kde mluvíme o napojování personálního systému, je hlavní výhodou synchronizace vůči rekonciliaci doba jejího běhu. V personálním systému je evidováno tisíce uživatelů, ale denně se jich aktualizuje pouze několik desítek, maximálně stovek. Doba běhu synchronizace je tedy řádově nižší než u rekonciliace.

Implementace synchronizace

Vraťme se však od strohé teorie k řešení našeho problému. Chceme nahradit proces rekonciliace personálního systému synchronizací. Data načítáme z přechodové Oracle databáze prostřednictvím databázových view, jenž pro nás integrují data z vícero tabulek. A co je hlavní, tak v datech není uvedeno, kdy byl daný záznam naposledy modifikován! První, co potřebujeme, je evidovat u všech tabulek obsahujících záznamy uživatelů informaci, kdy byl daný záznam aktualizován. Jelikož se tabulky při exportu z personálního systému mažou, tak si vytvoříme jejich kopie, které budou navíc obsahovat sloupec s informacemi o poslední modifikaci daného řádku (sloupec „modif_time“). Dále je potřeba realizovat to, že při exportu dat z personalistiky do databáze se nám budou aktualizovat data v našich tabulkách – „kopiích“ s tím, že se nám případně aktualizuje sloupec „modif_time“, pokud se daný řádek v „kopii“ liší od aktuálně exportovaného. Použití databázových triggerů není úplně šťastné, když se databázové tabulky při exportu mažou. Rozhodli jsme se tedy pro implementaci databázové procedury, která se bude volat vždy po skončení exportu. Ve výpisu níže je uvedena část této procedury, která se týká jedné z exportních tabulek, tabulky VEMA_UZIVATEL. Příkazem MERGE vložíme do naší „kopie“ (tabulka CZECHIDM_UZIVATELE) záznamy pro nové uživatele a aktualizujeme atributy u záznamů, které se liší mezi tabulkami VEMA_UZIVATEL a CZECHIDM_UZIVATELE. Zároveň u příslušných záznamů aktualizujeme atribut „modif_time“ v tabulce CZECHIDM_UZIVATELE. Následně zavoláním příkazu DELETE smažeme v tabulce CZECHIDM_UZIVATELE ty záznamy, které se již nevyskytují v tabulce VEMA_UZIVATEL. Obdobně je to realizováno i u ostatních exportních tabulek, které se týkají uživatelů a jejich atributů.

 /* Uzivatel */
 MERGE INTO VEMAEXPORT.CZECHIDM_UZIVATELE IDM
 USING (
 SELECT VEMA.JMENOZD, VEMA.PRIJMZD, VEMA.TITULYP, VEMA.TITULYZ, VEMA.OSCIS, VEMA.IDCIS, VEMA.LOKALITA FROM VEMAEXPORT.VEMA_UZIVATEL VEMA
 LEFT JOIN VEMAEXPORT.CZECHIDM_UZIVATELE IDM
 ON (VEMA.OSCIS = IDM.OSCIS)
 WHERE
 (IDM.OSCIS IS NULL) OR 
 (VEMA.JMENOZD || VEMA.PRIJMZD || VEMA.TITULYP || VEMA.TITULYZ || VEMA.OSCIS || VEMA.IDCIS || VEMA.LOKALITA) <> 
 (IDM.JMENOZD || IDM.PRIJMZD || IDM.TITULYP || IDM.TITULYZ || IDM.OSCIS || IDM.IDCIS || IDM.LOKALITA)) VEMA
 ON (VEMA.OSCIS = IDM.OSCIS)
 WHEN MATCHED THEN 
 UPDATE SET 
 IDM.JMENOZD=VEMA.JMENOZD, 
 IDM.PRIJMZD=VEMA.PRIJMZD, 
 IDM.TITULYP=VEMA.TITULYP, 
 IDM.TITULYZ=VEMA.TITULYZ, 
 IDM.IDCIS=VEMA.IDCIS, 
 IDM.LOKALITA=VEMA.LOKALITA, 
 IDM.MODIF_TIME=sysdate 
 WHEN NOT MATCHED THEN
 INSERT (OSCIS, JMENOZD, PRIJMZD, TITULYP, TITULYZ, IDCIS, LOKALITA, MODIF_TIME)
 VALUES (VEMA.OSCIS, VEMA.JMENOZD, VEMA.PRIJMZD, VEMA.TITULYP, VEMA.TITULYZ, VEMA.IDCIS, VEMA.LOKALITA, sysdate); 

 /* Smazeme data, co byla smazana ve VEMA_* tabulce */
 DELETE FROM VEMAEXPORT.CZECHIDM_UZIVATELE WHERE (OSCIS) IN (
 (SELECT OSCIS FROM VEMAEXPORT.CZECHIDM_UZIVATELE WHERE (JMENOZD, PRIJMZD, TITULYP, TITULYZ, OSCIS, IDCIS, LOKALITA)
 NOT IN
 (SELECT JMENOZD, PRIJMZD, TITULYP, TITULYZ, OSCIS, IDCIS, LOKALITA FROM VEMAEXPORT.VEMA_UZIVATEL))
 );

Nakonec upravíme naše databázová view, aby se data načítala z našich „kopií“ místo původních exportních tabulek a aby navracela u každého uživatele timestamp poslední modifikace přes všechny tabulky, které drží informace o uživateli. Příklad takového view je ve výpisu níže.

CREATE OR REPLACE FORCE VIEW "VEMAEXPORT"."CZECHIDM_UZIVATEL_VIEW" ("JMENO", "PRIJMENI", "TITULY_P", "TITULY_Z", "OSCIS", "IDCIS", "LOKALITA", "BUDOVA", "KANCELAR", "PSC", "LOGIN", "EMAIL", "TELEFON", "TELEFON_WEB", "MOBIL", "MODIF_TIME") AS 
 select distinct
 U.JMENOZD, 
 U.PRIJMZD, 
 U.TITULYP,
 U.TITULYZ,
 U.OSCIS,
 U.IDCIS,
 U.LOKALITA,
 (select L.ULICEN || ' ' || L.CP || ', ' || L.POSTA from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select L.NAZEV from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select L.PSC from CZECHIDM_LOKALITA L where L.LOKALITA=U.LOKALITA),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=1 and C.TYPSP='login')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=2 and C.TYPSP='e-mail')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=3 and C.TYPSP='telefon')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=4 and C.TYPSP='telefonweb')),
 (select C.KOD from CZECHIDM_SPOJENI C where (C.OSCIS=U.OSCIS and C.CISSP=6 and C.TYPSP='mobil')),
 (select MAX(MODIF_TIME) from (
 SELECT U1.OSCIS AS OSCIS, L1.MODIF_TIME FROM CZECHIDM_UZIVATELE U1 LEFT JOIN CZECHIDM_LOKALITA L1 ON U1.LOKALITA=L1.LOKALITA
 UNION
 SELECT U1.OSCIS AS OSCIS, U1.MODIF_TIME AS MODIF_UZIVATEL FROM CZECHIDM_UZIVATELE U1
 UNION
 SELECT V.OSCIS AS OSCIS, V.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_VYNETI V
 UNION
 SELECT Z.OSCIS AS OSCIS, Z.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_ZASTUP Z
 UNION
 SELECT S.OSCIS AS OSCIS, S.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_SPOJENI S
 UNION
 SELECT PS.OSCIS AS OSCIS, PS.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_PRAC_SMLOUVY PS
 UNION
 SELECT PZ.OSCIS AS OSCIS, PZ.MODIF_TIME AS MODIF_VYNETI FROM CZECHIDM_PRAC_ZARAZENI PZ
 ) WHERE OSCIS=U.OSCIS)
 from CZECHIDM_UZIVATELE U;

Tímto máme realizovány všechny požadavky na straně databáze. Nyní již zbývá pouze nakonfigurovat synchronizaci personálního systému v CzechIdM a vypnout zdlouhavou rekonciliaci. :-) Jak toho docílit je hezky popsáno v příspěvku První krůčky s CzechIdM  Kapitola 3: Nastavení synchronizace a rekonciliace systému jednoho z kolegů.

Výsledek

A jaký je výsledek? Proces rekonciliace, který v tomto konkrétním případě trval několik hodin, byl nahrazen synchronizací, jenž běží většinou několik málo minut.

Závěr

V tomto příspěvku jsme si popsali rozdíly mezi synchronizací a rekonciliaci koncového systému. Dále jsme si na praktickém příkladu ukázali, jak je možné implementovat synchronizaci nad systémem, který na první pohled synchronizaci neumožňuje. Pokud byste měli nějaké dotazy, tak mne neváhejte kontaktovat na jaromir.mlejnek@bcvsolutions.eu.

Odložené úkoly – Deffered Tasks v Oracle Waveset

Ve většině společností se účty zaměstnanců spravují k určitému datu. Při nástupu zaměstnance se mu jeho uživatelské účty (email, přístup do informačních systémů dané společnosti atd.) zpřístupní k datu jeho nástupu. Při jeho odchodu se mu naopak účty zablokují, případně smažou, k datu jeho odchodu. Níže Vám nastíním jednu z možností, jak takové řešení implementovat.

Nedávno jsme u jednoho zákazníka řešili následující úkol. Pravidelný proces, který kontroloval a aktualizoval všechny identity uživatelů každý den, se postupně s více napojenými systémy zpomalil a bylo ho potřeba nahradit úspornějším a stejně funkčním řešením. Tento proces prováděl kontrolu platnosti účtů u všech identit a podle toho případně přidával či odebíral role, tj. zakládal či blokoval uživatelské účty. U drtivé většiny identit ale žádná změna neprobíhala. Bylo tedy potřeba vytvořit proces, který se spustí pouze nad identitami, kde má proběhnout nějaká změna, např. nad zaměstnanci, jimž dnes končí pracovní poměr.

Vzhledem k tomu, že u tohoto zákazníka je nasazen Oracle Waveset, bylo možné částečně použít řešení Deffered Tasks (Odložené úkoly).

clocks

Deffered Tasks

O co se tedy vlastně jedná? V Oracle Waveset se vyskytuje standardní funkce Deffered Tasks, která umožňuje u dané identity uložit, kdy a jaký proces se má nad ní spustit. Dále je zde možné nastavit, zda se má daný proces provést pouze jednou, nebo opakovaně. Spouštění těchto tasků zajišťuje další proces – Deffered Task Scanner. Ten je spouštěn v pravidelných intervalech a zpracovává deffered tasks z minulosti. Prochází tedy pouze identity, které u sebe mají nastavené spuštění úkolu s datem v minulosti. U těchto identit spustí specifikovaný proces s parametry, které je také možné uložit u identity. Po skončení vypíše seznam identit, spouštěné procesy a výsledek.

Nasazení v našem případě

V našem konkrétním případě tedy stačí, když při každé změně data konce či začátku daného účtu bude spuštěn proces, který provede potřebné kroky. Toto datum se načítá při synchronizaci. Bylo ji tedy třeba upravit tak, aby případně k uživateli uložila odložený úkol. Příklad uložení můžete vidět níže:

<Property name='tasks'>
  <List>
    <Object name='Deffered Task'>
      <Attribute name='date'>
	<Date>2014-03-02T23:00:00.000Z</Date>
      </Attribute>
      <Attribute name='description' value='2014-03-03'/>
      <Attribute name='executeOnce' value='true'/>
      <Attribute name='accountId' value='100001'/>
    </Object>
  </List>
</Property>

Poté bylo potřeba pouze nastavit pravidelné spouštění Deffered Task Scanneru, který již bude potřebné operace spouštět každý den v pravidelnou dobu.

Tato úprava tedy nahradila zbytečně velký, dlouhý a náročný proces za optimálnější řešení, které funguje přesně na identitách, na kterých má, a neprovádí zbytečné úkony navíc. Bylo potřeba samozřejmě dopsat proces, který se spouští na zadaných identitách v zadanou dobu.

Možnost nasazení jinde

Toto řešení lze samozřejmě implementovat i v jiných podobných systémech. Data, která se ukládají k objektům, navíc nejsou nijak velká, tedy nevznikne ani velký nárok na další paměť. Pravidelný proces pro vykonávání těchto akcí se dá naplánovat na námi požadovanou dobu a tím pádem lze určit, kdy poběží tato akce, která může být v některých případech časově náročná. Navíc máme kontrolu nad tím, kdy a pro jakého uživatele se daná akce spouští. Tím pádem se vždy po doběhnutí pravidelného procesu můžeme podívat na potřebné výsledky a nemusíme je hledat mezi spoustou dalších pro nás nepotřebných záznamů.

Závěr

V tomto článku  je popsáno využití odložených úkolů v konkrétním případě. Toto řešení lze určitě aplikovat i na mnoho dalších problémů. Pokud byste měli nějaké dotazy ohledně našeho řešení, či nějaké další dotazy ohledně Oracle Waveset, neváhejte mě kontaktovat na adam.lenger@bcvsolutions.eu.

Databázové rozhraní personálního systému Vema

Personální systém Vema je v Česku velmi oblíbený a používá ho celá řada státních institucí i komerčních společností. Často se s ním proto setkáváme u zákazníků v rámci našich integračních projektů; Vema je pro náš Identity Manager CzechIdM typický zdroj dat o zaměstnancích. Systém Vema ovšem běžně nenabízí přístup k datům v reálném čase, člověk zpravidla dostane jen pravidelné noční exporty do CSV souborů. Naše zákazníky proto obvykle překvapí, že cesta k datům v reálném čase existuje a je daleko elegantnější než CSV soubory. Společnost Vema totiž vyvinula modul, který umí exportovat personální data v reálném čase do Oracle relační databáze. A právě o něm bude můj dnešní článek.

vema-logo

Pokračování textu

Vytvoření formuláře v Oracle Waveset

Oracle Waveset nám nabízí mnoho standardních formulářů, ale občas je třeba vytvořit jeden specifický, který se mezi nimi nevyskytuje. S takovýmto problémem jsme se setkali i u nás a to v situaci, kdy bylo potřeba vytvořit formulář pro změnu hesla na nově připojeném systému. Je to centrální autentizační systém. Tento nový formulář slouží běžným uživatelům ke změně svého hesla, správcům potom ke změně hesla normálním uživatelům, kteří spadají do jejich oblasti působnosti (tato oblast je určována podle přiřazené role).

Pokračování textu

Připojení finančního informačního systému do IdM

Na podzim tohoto roku jsme připojovali finanční informační systém (dále zde označován pod zkratkou FIS) pro vysokou školu od dodavatele BBM. Na této univerzitě již běží Identity Manager Sun/Oracle Waveset, kde je již několik systémů připojených. V tomto článku vás seznámím s průběhem připojení a také s problémy, které při tom nastaly.

Zadání

Identity Manager má za úkol na FISu spravovat uživatele. Přidává nebo odebírá role a také mění jeho atributy. Role ale nevytváří, needituje ani neodstraňuje.
Pokračování textu

Oracle: paralelní zpracování

Dnešní databáze běžně obsahují miliony záznamů. Kdyby je měl databázový stroj při každé změně či každém dotazu procházet postupně jeden po druhém, trvalo by to několik hodin. Řešením, které vytěží maximum z dostupného hardware a zvládne úkol v mnohem kratším čase, může být paralelizace. Databáze Oracle verze 11 tuto možnost poskytuje. V článku se podíváme, jak si z pozice administrátora paralelní zpracování na některých databázových objektech vynutit, anebo naopak zakázat, a ukážeme si některé zajímavé parametry, které s paralelizací souvisejí.

 

Pokračování textu

Úprava schvalovacího workflow v Oracle Identity Managementu


Tento článek popisuje jakým způsobem je možné upravit standardní schvalovací workflow v systému Sun Identity Manager (Oracle Waveset) tak, aby došlo ke schválení i v případě, kdy jeden ze schvalovatelů tuto akci zamítne. Dále zde bude rozebrána funkčnost, kdy jsou schvalovatelé definováni tím, že mají přiřazenou k tomu určenou roli.

Pokračování textu