All posts by Jaromír

Virtuální systémy v CzechIdM

Na projektech u zákazníků se setkáváme se situací, kdy zákazník chce prostřednictvím CzechIdM evidovat účty uživatelů na systémech, které z nějakého důvodu nemohou být připojeny k CzechIdM na přímo (například daný systém neposkytuje žádné rozhraní k jeho napojení). Někdy jen není žádoucí přímé napojení na daný systém. Abychom těmto požadavkům zákazníků vyšli vstříc, máme v CzechIdM implementovaný model tzv. virtuálních systémů, jenž tyto požadavky řeší. V tomto článku se blíže podíváme, jak jsme virtuální systémy implementovali v CzechIdM.

Continue reading

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 info@bcvsolutions.eu.

CzechIdM handle accounts in IS Medea

The General University Hospital in Prague, where user’s accounts are managed by our Identity Manager CzechIdM since spring 2013, uses the hospital information system (HIS) Medea provided by Stapro. In this article I will describe technical details of connection between CzechIdM and Medea HIS, and we will see a whole life cycle of user’s accounts on this information system.

schema-clanek

CzechIdM and Medea HIS

CzechIdM is an Identity Manager, an application that automatically manages user’s accounts through enterprise IT systems. Administrators of these systems that are connected to CzechIdM not have to do basic operation like create user account for a new employee, disable user account when an user employment is finished and so on. All action executed by CzechIdM on connected systems are also registered in audit log, so administrator is allow to find modifications that were executed on given account. CzechIdM is allow to manage a lot of systems via Identity Connectors, libraries mostly written in Java programming language. Identity Connectors use standard communication protocols like JDBC, HTTP, JAX-WS etc.

One of the systems that is handle by CzechIdM at the General University Hospital in Prague is Medea, a hospital information system delivered by Stapro. There is number of instances of Medea over the hospital where are registered electronic health records, a pharmacy, records of hospitalized patients or archivated data. Medea is a key system for the hospital and contains confidential information so connection with CzechIdM has to be realized with maximum emphasis on security and stability.

Details of connection

CzechIdM doesn’t communicate with Medea HIS directly but through the simple database interface in Progress database. CzechIdM through this database interface creates new accounts, disables unused accounts in Medea, provides functionality to password change and sends related information needed for electronical signature of electronic health records. From the technical point of view is connection between CzechIdM an Medea realized by our universal JDBC connector that is ussualy used for communication with a relation database.

schema-clanek2

Electronic health record

The key module of Medea HIS at the General University Hospital in Prague is electronic health records registration. Doctors who works with electronic health records uses electronic signature. To these processes, that are related to electronic signature and digital certificates, is dedicated the recent article of my collegue Jakub Tomek.

Medea HIS is one of the destination systems which receives certificates and signature tokens from CzechIdM. If an user certificate is revocated, CzechIdM downloads the new one and provide the distribution into connected IT systems. If the new token is created for some doctor, CzechIdM automatically writes serial number ot this certificate into Medea HIS.

Lifecycle of user account

Business procesess defined in CzechIdM cover the whole life cycle of user’s accounts in Medea HIS:

  • Creation of user account
  • Certificate and token import into Medea
  • Updating of user account
  • Password change (by user or helpdesk)
  • Disabling of user account

Conclusion

This article follow to the article of my collegue Jakub Tomek which was focus on business processes connected with digital certificates at the General University Hospital in Prague. The hospital information system Medea is one of the most important system which is handle by CzechIdM – CzechIdM creates, updates and deletes user’s account in Medea and so on. If you are interested in this topic I’m fell free for your questions. You can contact us at: info@bcvsolutions.eu

Napojení CzechIdM na IS Matrix aneb jak na agendové systémy

Pro našeho zákazníka jsme napojovali k CzechIdM informační systém Matrix. V tomto článku Vám blíže popíši technickou realizaci tohoto napojení a dále se podíváme, jaké jsou jeho přínosy pro zákazníka.

CzechIdM a Matrix

CzechIdM

CzechIdM je Identity Manager, tedy software umožňující centrální správu uživatelských účtů na koncových systémech. U tohoto konkrétního zákazníka CzechIdM načítá informace o zaměstnancích z personálního systému. Na základě načtených dat spouští příslušné personální procesy, jejichž výsledkem je aktualizace stavu uživatelských účtů na koncových systémech. Příkladem může být nástup nového zaměstnance, kdy CzechIdM načte jeho údaje z personálního systému a automaticky mu založí všechny požadované účty, například na základě jeho organizačního zařazení. Rutinní správa uživatelských účtů je tímto delegována z administrátorů na CzechIdM.

Informační systém Matrix

Matrix je informační systém od společnosti ICT Br@ins. Tento systém slouží k evidenci agend, činnostních rolí a agendových informačních systémů (AISů), které se týkají centrálních registrů.  Matrix eviduje, jaké činnostní role a agendy jsou přiřazeny jednotlivým zaměstnancům, do jakých agendových informačních systémů jim tyto role umožňují přistupovat, jak se tyto vazby měnily v čase atd. Pokryty jsou procesy od přípravy agendy, jejího schvalování, až po schvalování činnostních rolí pro jednotlivé zaměstnance prostřednictvím generovaných XML602 formulářů.

Co přináší napojení IS Matrix pod správu CzechIdM?

Již víme, jak se správou uživatelů pomáhá CzechIdM a k čemu slouží systém Matrix. Pojďme se nyní podívat, co konkrétně přináší napojení IS Matrix pod správu CzechIdM.

  • Automatizovaná správa uživatelů
    • při nástupu zaměstnance CzechIdM automaticky založí zaměstnanci účet v Matrixu
    • při změně popisných údajů uživatele se aktualizují odpovídající atributy v Matrixu
    • při ukončení pracovního poměru zaměstnance CzechIdM zablokuje odpovídající účet v Matrixu
  • Nastavování práv pro uživatele v Matrixu přes CzechIdM
    • uživatelům v Matrixu mohou být navýšena práva, aby mohli v Matrixu vykonávat specifické úkony, např. přidělovat agendy a činnostní role jiným uživatelům. Dříve tyto oprávnění v Matrixu nastavovali administrátoři. Nyní stačí, aby se danému uživateli v CzechIdM přiřadila odpovídající role pro Matrix a CzechIdM samo nastaví požadované oprávnění.
  • Automatizovaná správa organizační struktury
    • zdrojem informací o organizační struktuře je personální systém. CzechIdM ji načítá a propaguje ji do dalších systémů, mezi než patří také Matrix.
  • Schvalování činnostních rolí přes CzechIdM
    • zjednodušení a zautomatizování schvalovacího procesu pro činnostní role, viz kapitola níže

Princip napojení

CzechIdM používá obecně k napojování koncových systémů tzv. konektory. Konektory jsou něco jako knihovny, které poskytují CzechIdM jednotné rozhraní pro komunikaci s koncovými systémy, které CzechIdM spravuje. Pro napojení systému Matrix jsme vyvinuli konektor, který volá webové služby Matrixu. Konektor je implementován v jazyce Java a jako implementaci protokolu SOAP používá Apache Axis framework.

Prostřednictvím tohoto konektoru jsou v CzechIdM vytvořena tři samostatná napojení na Matrix. První dvě slouží ke správě organizačních útvarů a funkčních míst v Matrixu.

Třetí napojení slouží pro správu uživatelů v Matrixu. CzechIdM v Matrixu:

  1. zakládá uživatelské účty,
  2. nastavuje přístupová práva uživatelům a
  3. načítá vazby uživatelů na činnostní role v Matrixu, které se mají prostřednictvím CzechIdM schvalovat.

Princip schvalování práv v Matrixu je následující:

Pověřená osoba nastaví uživateli v Matrixu vazby na činnostní role, které odpovídají jeho pracovnímu zařazení. V CzechIdM běží v pravidelných intervalech proces, který tyto vazby načte, vytvoří vedoucímu daného zaměstnance schvalovací úkol v CzechIdM a emailem ho notifikuje, aby ho v CzechIdM vyřešil, tj. schválil či zamítl. Po jeho vyřešení se výsledek může propagovat do příslušného agendového systému, případně zapisovat do jiného informačního systému, viz obrázek níže.

schema

Závěr

V tomto článku jsme si ukázali, jak je realizováno napojení CzechIdM na systém Matrix a jaké přínosy pro zákazníka to má. Pokud řešíte problém, jak efektivně spravovat zaměstnance a jejich oprávnění v agendových systémech, tak se nám neváhejte ozvat. Kontaktovat mne můžete na emailu jaromir.mlejnek@bcvsolutions.eu a samozřejmě nejen ohledně správy agendových systémů :-)

Emailové notifikace v CzechIdM

Sice to nemusí na první pohled tak vypadat, ale emailové notifikace jsou podstatnou a důležitou součástí každého dobrého Identity manageru. V tomto příspěvku se podíváme, jakým způsobem jsou emailové notifikace implementovány v našem CzechIdM. Ukážeme si, jak jednoduše se dají vytvářet šablony, dle kterých se emaily odesílají a jak je možné přidat novou notifikaci do stávajícího procesu.

Continue reading

Centralizovaná správa souborového systému prostřednictvím CzechIdM – realizace

Popisem způsobu, jakým náš Identity Manager CzechIdM může spravovat oprávnění na souborovém systému, se věnuje článek Centralizovaná správa souborového systému. Zde je názorně ukázáno, jak jednoduše se dají oprávnění prostřednictvím CzechIdM spravovat, jak si mohou jednotliví uživatelé žádat o oprávnění na sdílené adresáře, jak funguje schvalování přístupů z pohledu vedoucích jednotlivých uživatelů, případně z pohledu vlastníka dat atd. V tomto článku se podíváme na správu oprávnění prostřednictvím CzechIdM z pohledu realizace. Tak do toho! Continue reading

Školení Identity Management a Identity Manager CzechIdM

Mít Identity Manager, který člověku může v mnohém pomoci, a neumět ho naplno využít? To přeci není logické! Z toho důvodu pořádáme pro naše zákazníky školení, ať již při nasazování našeho Identity Manageru CzechIdM do provozu, tak i v rámci nezávislých konzultací. Naše školení upravujeme dle požadavků každého ze zákazníků. V tomto článku si projdeme základní kostru takového školení, ve kterém jsou jednak obsaženy obecné principy Identity Managementu, tak i specifické věci, které se týkají našeho systému CzechIdM.

Continue reading

Pravidla v CzechIdM

V tomto článku si povíme něco o pravidlech v našem Identity Management systému CzechIdM. Ukážeme si, co jsou to pravidla, jaké druhy pravidel v CzechIdM používáme a k čemu slouží. Je důležité zmínit, že máme na mysli například pravidla definující politiku hesel (tomu je věnován článek “Pravidla pro vytváření hesel v CzechIdM”) a podobně. Na pravidla zde nahlížíme z programátorského pohledu.

Continue reading

Identity konektor pro Alfresco – SOAP nebo RESTful?

V tomto příspěvku si ukážeme, jakým způsobem lze připojit systém Alfresco k našemu Identity Manageru CzechIdM. Dopředu prozradím, že si k tomuto účelu navrhneme a naimplementujeme speciální Identity connector. Nebudeme si zde podrobně rozebírat implementaci konetoru jako například v případě Universal SSH konektoru, ale podíváme se na tento problém z poněkud jiného pohledu. Ukážeme si, jak postupujeme při zákazníkově požadavku na připojení nějakého nového systému k CzechIdM a jak jsme postupovali v tomto případě.

Continue reading

Časovače, Java a CzechIdM – 1. část

Toto je první část příspěvku zaměřeného na časovače a časové služby v programovacím jazyce Java. V dnešním příspěvku si na úvod uvedeme dva příklady, kde najdou časovače své uplatnění. První je spíše obecného charakteru, druhý je již specifický a popisuje použití časovačů v našem systému CzechIdM. Poté si ukážeme, jak časovat úlohy v Java SE a Java EE 5 a 6 s použitím EJB kontejneru.

Příští příspěvek bude zaměřen více specificky, a to na jBPM časovače a na projekt Quartz. Zároveň si jednotlivé možnosti shrneme a porovnáme. Nezbývá než začít.

Continue reading