Archiv pro štítek: CzechIdM

CzechIdM na Windows? Není problém!

Windows-supportPři příležitosti vydání nového releasu CzechIdM a jeho zveřejnění jsme řešili, jak udělat instalaci CzechIdM co nejjednodušší a tím nejvíce dostupnou.

Vznikl instalační návod a několik instalačních skriptů, které automaticky konfigurovaly potřebné aplikační prostředí. Protože ale vývoj CzechIdM probíhá na Linuxu a zároveň všechny dosavadní instalace jsou na Linuxu, vznikly tyto skripty právě jen pro Linux. Jak CzechIdM, tak i aplikační server na kterém CzechIdM běží jsou napsané v Javě, proto není problém ho spustit na všech systémech.

Jako cíl jsme si tedy dali zprovoznění CzechIdM i pro Windows o kterém budu právě pojednávat v tomto článku. Celkově se instalace na Windows liší pouze v odlišné konfiguraci specifické pro Windows. Pokud by vás zajímalo více obecně o instalaci a jejích detailech, přečtěte si článek Zjednodušení instalace CzechIdM.

Stažení balíčku CzechIdM

Nejprve si stáhneme distribuční balíček CzechIdM z http://www.czechidm.com/getstarted/. Ten obsahuje aplikační server, potřebné sql skripty na úvodní naplnění dat a uploader. Nejprve si zkopírujeme složku jboss-5.1.0.GA tam, kde chceme mít CzechIdM nainstalované. Zde je třeba dát pozor na příslušná oprávnění – je dobré zkopírovat tuto složku do nějaké uživatelem vlastněné složky. Kdybychom ji zkopírovali například do Program files, je možné, že by CzechIdM nenaběhlo z důvodu výších nároků na práva.

Zprovoznění aplikačního prostředí

Nejprve je třeba stáhnout a nainstalovat MySQL server a databázi. Najdeme ho na adrese http://dev.mysql.com/downloads/. Podporované jsou verze 5 a vyšší. Spustíme MySQL server (nachází se ve složce bin/mysqld.exe). Nyní je třeba založit databázi a nakonfigurovat uživatele, přes kterého se CzechIdM do MySQL připojuje. Na to naštěstí máme skripty, které vše udělají za nás. Překopírujeme všechny sql skripty do lokace, kam jsme nainstalovali MySQL do složky bin. Přesměrujeme skript initial_import.sql na standartní vstup mysql přes CMD.

mysql -u root < create_repository.sql

Dále stáhneme MySQL JDBC connector z http://search.maven.org/remotecontent?filepath=mysql/mysql-connector-java/5.1.8/mysql-connector-java-5.1.8.jar. To je konektor, který umožnuje CzechIdM se připojit právě do MySQL databáze kam si ukládá svoje vlastní data. Tento konektor musíme nakopírovat do složky, kde máme překopírovaný jboss do server/default/lib/ a server/default/deploy/CzechIdM-ear.ear/lib/. Zároveň ho musíme zkopírovat do složky, kam jsme stáhli distribuci CzechIdM do IdmUploader/IdmUploader_lib/.

Jako poslední bude třeba stáhnout a nainstalovat aplikační prostředí Javy. Najdeme ho na http://www.oracle.com/technetwork/java/javase/downloads a stáhneme JDK 1.7. Úspěšnou instalaci můžeme zkontrolovat v CMD zadáním

java -version

Instalace CzechIdM

V této fázi máme již vše potřebné připravené. Zbývá již jen spustit aplikační server JBoss a nahrát počáteční import dat do databáze. Server spustíme tak, že půjdeme na umístění, kam jsme ho zkopírovali do složky bin, kde spustíme run.bat. Tím by se měl začít server spouštět. Počkáme, než kompletně naběhne. To poznáme, že poslední věta v konzoli bude vypadat jako JNDI InitialContext properties:{}

Teď potřebujeme importovat počáteční data do databáze. Ty nám vytvoří výchozí uživatele v CzechIdM. Jdeme do složky MySQL/bin a zde zadáme do CMD

mysql -u root < initial_import.sql

Jako poslední úkol je nahrání aplikační logiky do CzechIdM. K tomu slouží program IdmUploader, který je ve složce distribuce, kterou jsme stáhli na začátku článku. Zde je třeba spustit runIdmUploader.bat. Import dat trvá obecně okolo 30 sekund.

Dokončení instalace

Jakmile máme AS JBoss spuštěný, MySQL máme připojený do CzechIdM a zároveň jsme provedli počáteční import, můžeme se přihlásit do administrátorského rozhraní. To se typicky nachází na adrese http://localhost:8080/idm. Pro přihlášení použijeme účet superadministrátora, která má login „admin“ a počáteční heslo je stejné. Nezapomeňte si toto heslo v konfiguraci změnit jako první!

Závěr

Tímto by měla být instalace CzechIdM hotová a můžete se k němu připojit přes http://localhost:8080/idm, kde se příhlásíte jako admin s heslem admin. Kdyby jste měli nějaké otázky či problémy s instalací CzechIdM na Windows, neváhejte se obrátit na filip.mestanek@bcvsolutions.eu.

CzechIdM je nyní dostupný pod svobodnou licencí a zdarma!

V současné době jsou hlavním tématem v mnoha společnostech úspory. Není vůbec snadné prosadit jakýkoliv nový projekt. Na druhou stranu ICT prostředí je vystavováno stále větším nárokům a rozrůstají a zvyšují se i požadavky na jeho bezpečnost. Pomocníkem v této situaci je Identity management, který spravuje uživatelské účty, role, skupiny, organizační zařazení a jejich vztah k jednotlivým aplikacím a datům. Jak tedy nasadit centrální správu identit, bez velkých výdajů za licence a s využitím vlastních pracovníků?

bcv

Společnost BCV solutions s.r.o., leader v oblasti Identity a Access Managementu, nabízí pomocnou ruku. Po dlouhých letech vývoje a vylepšování svého identity manageru CzechIdM, který spravuje již více než 2 000 000 účtů, přibližuje na českém trhu řešení IDM každému. CzechIdM je nyní dostupné pod svobodnou licencí a zdarma! Proč se k tomuto kroku naše společnost přiklonila?

„Již od založení společnosti v roce 2008 bylo naším cílem především pomáhat firmám se správou identit. Poptávka po CzechIdM dlouhodobě překračuje naše možnosti. Protože chceme držet kvalitu implementací projektů, kontrolujeme náš růst.  Rozhodli jsme se dát CzechIdM k dispozici zdarma pod svobodnou licencí všem, kdo potřebují kvalitní a prověřené řešení IDM,” říká Lukáš Cirkva, ředitel společnosti BCV solutions s.r.o.

 

czechidm

 

Může CzechIdM pomoci právě Vám?

CzechIdM zajišťuje kompletní řešení správy uživatelských účtů pro malé a střední společnosti, instituce státní správy a zdravotnická zařízení. Toto řešení se tak stává dostupnější alternativou k již existujícím produktům společností Oracle, IBM či Novell.

Kdokoliv si produkt CzechIdM stáhne, je schopen jej nainstalovat, snadno připojit systémy a především jej používat,“ doplňuje Lukáš Cirkva.

Pokud vás řešení CzechIdM zaujalo a máte zájem o více informací či instalační soubory, navštivte nás na www.czechidm.com.

O BCV solutions

BCV solutions s.r.o., česká společnost se sídlem v Praze se zaměřením na poskytování IT řešení a služeb. Pomáháme zlepšit Identity a Access Management. Aktuálně zákazníkům pomáháme spravovat přes 2.000.000 účtů!

Kontakt

Lukáš CIRKVA, CEO
tel.: +420 724 111 809
email: lukas.cirkva@bcvsolutions.eu
http://www.bcvsolutions.eu

9 důvodů, proč dát přednost CzechIdM před Oracle Waveset

V poslední době se mě na prezentacích a školeních čím dál častěji ptají, v čem je náš Identity Management CzechIdM lepší než dosluhující Oracle Waveset, dříve nazývaný též Sun Identity Manager. Jako projektový manažer i vývojář jsem se na vlastní kůži setkal s oběma; nedávno jsem tu psal o úspěšné migraci z Oracle Waveset na CzechIdM ve Všeobecné fakultní nemocnici. Můžu tedy srovnávat, důvodů k migraci je celá řada.

  1. Podpora – CzechIdM je svým tvůrcem stále rozvíjeno.
    Zatímco Oracle Waveset je jako produkt mrtvý, CzechIdM se vyvíjí podle požadavků zákazníků, reaguje na technologické trendy a přizpůsobuje se novým verzím napojovaných systémů.
  2. Otevřené zdrojové kódy – Pokud máte Waveset, máte černou skříňku.
    S Wavesetem jste si nainstalovali předkompilované binární soubory, které si nepřečtete ani nepřizpůsobíte. Zákazníci CzechIdM naproti tomu dostanou kompletní zdrojové kódy a je na nich, zda budou chtít něco upravit.
  3. Příjemnější rozhraní – uživatelé mají raději CzechIdM.
    Rozdíl je v detailech: jednodušší menu, větší tlačítka, smysluplnější popisky, méně klikání v obvyklých situacích, přehlednější nápověda…
  4. Méně práce pro vývojáře – přizpůsobit CzechIdM je rychlejší a stojí to méně peněz.
    Kdo někdy programoval pro Oracle Waveset, dá mi za pravdu: napsat jednoduchý proces pro Waveset znamená naučit se podivný jazyk XPress a napsat v něm tisíc řádků kódu. CzechIdM používá standardní Javu, pokud jste se s ní potkali aspoň na gymnáziu, nejspíš byste zvládli napsat svůj první proces pro CzechIdM ještě dnes. Zákazník tak ušetří přes 30% nákladů.
  5. Výkon – CzechIdM zvládne za stejný čas více práce.
    Waveset drží všechny své objekty v XML struktuře. CzechIdM má datový model chytřejší: využívá všech výhod moderních relačních databází. Díky tomu pracuje s uživateli, účty a rolemi rychleji a efektivněji.
  6. Bezpečnost – tvůrci CzechIdM reagují na rizika.
    Ve světě informačních systémů se každý rok objevují nová bezpečnostní rizika – v databázích, aplikačních serverech, programovacích jazycích… Zatímco programátoři CzechIdM novým slabinám v technologiích čelí (viz nedávno odhalená bezpečnostní chyba v MySQL, na kterou museli reagovat, http://blog.sucuri.net/2012/06/security-vulnerability-in-mysql.html), Waveset už jen stojí na místě: bezpečnostní díra u něj zůstane dírou navždy..
  7. Jednodušší pro administrátory – s CzechIdM se administrátor rychleji naučí pracovat
    CzechIdM má jen ty funkce, které jsou skutečně potřeba. Administrátor tak může hned dělat svou práci a netráví dlouhý čas studiem nového produktu. Kompletní dokumentace v češtině taky není k zahození.
  8. Lokální tvůrce – tým vývojářů v Česku
    Na rozdíl od Wavesetu je CzechIdM stoprocentně český produkt vyvinutý lokální společností. Když zákazník potřebuje pomoc, dorazí k němu expert, který CzechIdM sám vytvářel a zná produkt do posledního řádku kódu.
  9. Prezentační vrstva na míru – JSF vs. XPress
    Složitější formulář pro Waveset jsou 3 dny práce v jazyce XPress a výsledek pravděpodobně nebude úplně podle vašich představ. CzechIdM stejně jako většina dnešních aplikací používá JSF, formulář bude za odpoledne a po stránce vzhledu je realizovatelné prakticky cokoli.

Ano, mít důvodů deset, vypadalo by to lépe. Máte podobnou zkušenost jako já? Pomůžete nám vymyslet desátý důvod? Kontaktovat nás můžete na adrese info@bcvsolutions.eu.

Seznámení s Hibernate ORM

V tomto článku si popíšeme základy technologie Hibernate ORM pro komunikaci Javy s relačními databázemi. Osvěžíme si znalosti o tom, co je to ORM a jak se popisují vztahy mezi jednotlivými entitami v datovém modelu. Letmo se zmíníme, jaký vztah je mezi Java Persistence API (JPA) a Hibernate. Na závěr se ve stručnosti seznámíte s použitím Hibernate v Identity Manageru CzechIdM.

Hibernate ORM

Hibernate ORM je framework v jazyce Java, umožňující objektově-relační mapování (ORM).

ORM je programovací technika, která umožňuje ukládat data objektově orientovaných jazyků do relační databáze. Vybraným Java třídám pak přísluší databázové tabulky, přičemž javovské datové typy se konvertují na SQL datové typy. ORM zpracovává také vztahy mezi objekty, které do relačních databází ukládáme. V databázi jsou pak vztahy objektů reprezentovány spojováním tabulek a cizími klíči.

Hibernate implementuje Java Persistence API. Můžeme ho tedy používat buď specificky – tak, že voláme přímo jeho metody -, nebo obecně přes rozhraní definované JPA.

Hibernate podporuje mnoho databázových dialektů. Umožňuje pracovat například s MySQL (přičemž můžeme odlišit, zda používá engine InnoDB či MyISSAM), PostgreSQL, Oracle, Microsoft SQL Server aj.

Hibernate dále vyvíjí speciální jazyk pro psaní dotazů do databáze přímo z kódu, tzv. Hibernate Query Language (HQL). HQL je inspirován syntaxí SQL, takže je dobře použitelný pro každého, kdo zná základy SQL dotazů.

Entita v Javě

Entita je samostatný typ objektu, který má své specifické vlastnosti a jehož instance jsou jednoznačně identifikovatelné.

Pro Hibernate je entita jedna Java třída, jejíž instance se ukládají jako záznamy do jedné databázové tabulky. Každá instance entity má svůj identifikátor, který se obvykle použije jako primární klíč do tabulky.

Entitní třída musí mít konstruktor bez parametrů, protože pomocí něj Hibernate vytváří objekty při načítání z databáze. Členské proměnné třídy jsou zpravidla private, používají se pro ně standardně konstruované gettery a settery. Načítání hodnot členských proměnných z databáze se může provádět pomocí lazy-loading, proto se doporučuje přistupovat k proměnným pomocí getterů (které vynutí načtení celé hodnoty).

Persistence entit

Ukládání instancí entit do databáze se provádí dvojím způsobem, v závislosti na tom, zda používáme způsob specifický pro Hibernate, nebo jeho implementaci JPA.

V prvním případě si pomocí org.hibernate.SessionFactory (objekt, který se vyskytuje v jedné instanci pro celou aplikaci) vytvoříme objekt typu org.hibernate.Session, v rámci kterého provedeme „jednotku práce“ – jednu operaci v databázi:

org.hibernate.Session session = sessionFactory.openSession();
session.beginTransaction();
session.save(nejakaEntita);
session.getTransaction().commit();
session.close();

V druhém případě použijeme javax.persistence.EntityManagerFactory, kterou dodává JPA v závislosti na konfiguraci naší aplikace, a pomocí ní vytvoříme objekt typu javax.persistence.EntityManager. Ten provádí jednotku práce podobně jako v předchozím způsobu:

javax.persistence.EntityManager entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
entityManager.persist(nejakaEntita);
entityManager.getTransaction().commit();
entityManager.close();

Konfigurace

Základní konfigurační soubor pro Hibernate se nazývá hibernate.cfg.xml.

V tomto souboru definujeme na prvním místě dialekt databáze, aby Hibernate používal správné datové typy a správnou syntaxi SQL:

<hibernate-configuration>
  <session-factory>
    <property name=“dialect“>org.hibernate.dialect.MySQL5InnoDBDialect</property>

V konfiguračním souboru nesmí chybět identifikace spojení do databáze. Pokud zadáme všechny potřebné údaje pro navázání JDBC spojení, Hibernate si vytvoří JDBC connection pool, který mu bude poskytovat spojení tak, jak bude třeba. Místo toho můžeme zadat existující javax.sql.DataSource registrovaný v JNDI, tedy spojení, které je spravováno naším aplikačním serverem.

<property name=“connection.datasource“>java:/CzechIdMDatasource</property>

(Komunita Hibernate doporučuje používat pro produkční prostředí spíše tento způsob. Upozorňují, že správu vlastního JDBC connection pool ještě Hibernate nezvládá úplně bez chyb).

Další důležitou vlastností je hbm2ddl.auto. Tato vlastnost určuje, co se děje s databázovým schématem ve chvíli vzniku a zániku SessionFactory, tj. při startu a skončení aplikace. Možné hodnoty jsou „update“ (při startu aktualizuje schéma na základě aktuálního nastavení), „validate“ (při startu ověří schéma, ale změny nedělá), „create“ (při startu vytvoří nové schéma, čímž přepíše původní data), „create-drop“ (při skončení smaže schéma, při startu ho znovu vytvoří).

V konfiguračním souboru jsou dále uvedeny odkazy na mapovací soubory.

Pokud používáme obecné rozhraní JPA, konfigurační soubor je META-INF/persistence.xml. Zde definujeme poskytovatele persistence, spojení do databáze a další konfigurační vlastnosti. Ty vlastnosti, které jsou určeny pro Hibernate, uvedeme s předponou „hibernate.“.

<persistence-unit name=“CzechIdM“>
  <provider>org.hibernate.ejb.HibernatePersistence</provider>
  <jta-data-source>java:/CzechIdMDatasource</jta-data-source>
  <properties>
    <property name=“hibernate.dialect“ value=“org.hibernate.dialect.MySQL5InnoDBDialect“/>
    ...

Mapovací soubory (Hibernate)

V mapovacích souborech definujeme mapování entit na databázové tabulky. Nejlépe to ukážeme na příkladu:

<hibernate-mapping>
  <class name="org.jbpm.graph.def.Node" table="JBPM_NODE">
    <id name="id" column="ID_"><generator class="native" /></id>
    <property name="name" column="NAME_"/>
    <property name="description" column="DESCRIPTION_" type="longstring" length="4000"/>
    ...

Atribut „name“ u elementu „class“ obsahuje FQN (Fully qualified name) třídy, která je entitou. Atribut „table“ obsahuje název tabulky, kam se její instance budou ukládat.
Následuje výčet sloupců.

Element „id“ definuje sloupec, který unikátně identifikuje řádek v tabulce. Nemusí to být primární klíč, ale je to obvyklé. Uvnitř elementu „id“ může být ještě definována strategie generování identifikátorů.

Element <property name="description" column="DESCRIPTION_" type="longstring" length="4000"/> definuje proměnnou „description“ mapovanou na sloupec „DESCRIPTION_“, přičemž v atributu „type“ je uveden konvertor (Hibernate mapping type), který má Hibernate použít pro překlad z Java datového typu na databázový typ. Pokud není konvertor uveden, používá se Java reflection a defaultní mapování z javovských typů na databázové typy. Není-li uveden atribut „column“, použije se pro název sloupce přímo název proměnné.

Anotace (JPA)

Místo mapovacích souborů se dají použít anotace přímo u entitních tříd a jejich členských proměnných. Názvy anotací odpovídají názvům vlastností v mapovacích souborech. Entita pak vypadá například takto:

@Entity
@Table(name = "identities", uniqueConstraints = {
  @UniqueConstraint(columnNames = { "name" }) })
public class Identity extends ViewMainEntity {
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "id")
  private int id;

  @SignedField
  @Index(name = "name_index")
  @Column(name = "name", length = NAME_LENGTH)
  private String name;
  ...

Výhodné je, že při použití anotací vidíme ze zdrojového kódu na první pohled, jakým způsobem se entita ukládá.

Anotace jsou součástí standardu JPA. Pokud bychom tedy chtěli změnit způsob persistence dat do databáze, nemusíme při používání anotací měnit nic v kódu.

Vztahy mezi entitami

Silným nástrojem Hiberate ORM je popis vztahů mezi entitami. Každé dvě entity spolu mohou být v nějakém vztahu (relaci), přičemž jedna strana je vlastníkem relace a druhou nazýváme „inverzní strana“.

Vlastník relace je zodpovědný za udržování konzistence v datech na obou stranách relace. Při definici relace určíme pomocí CascadeType, jaké typy operací se mají v rámci relace propagovat. Například CascadeType.REMOVE způsobuje, že smaže-li se jedna strana relace, smaže se i druhá strana.

V databázi se vztah entit realizuje cizími klíči mezi jednotlivými tabulkami, přičemž cizí klíče jsou vydefinované v tabulce vlastníka relace.

Základní typy relací jsou Many-to-one resp. One-to-many, One-to-one a Many-to-many. Každý vztah si nyní ukážeme na příkladu z datového modelu CzechIdM spolu s ukázkami kódu.

Many-to-one & One-to-many

Situace: Každá identita patří právě do jedné organizace, přičemž do každé organizace může patřit více identit.

  • Entita Identity – vlastník relace
    @ManyToOne
    @JoinColumn(name = "home_organisation")
    private Organisation homeOrganisation;
  • Entita Organisation
    @OneToMany(mappedBy = "homeOrganisation", cascade = {CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH })
    private List<Identity> identities;
    

Vazba: V databázové tabulce „identities“ je vytvořen speciální sloupec „home_organisation“, který obsahuje identifikátor (primární klíč) domovské organizace identity.

Pokud bychom na straně organizace nepotřebovali znát seznam identit, které do ní patří, mohli bychom úplně vynechat proměnnou „identities“ a jakýkoliv odkaz na to, že mezi entitami Identity a Organisation je nějaký vztah. Relaci udržuje entita Identity. CascadeType bychom pak samozřejmě museli přidat do kódu k identitě.

One-to-one

Situace: Každá identita má právě jednu konfiguraci.

  • Entita Identity – vlastník relace
    @OneToOne(optional = false, cascade = CascadeType.ALL)
    @JoinColumn(name = "configuration")
    private IdentityConfigurations identityConfigurations;
    
  • Entita IdentityConfigurations
    @OneToOne(mappedBy = "identityConfigurations")
    private Identity identity;
    

Vazba: V databázové tabulce „identities“ je vytvořen speciální sloupec „configuration“, který obsahuje primární klíč konfigurace identity z tabulky „identity_configurations“.

Opět platí to, že kdyby entita IdentityConfigurations nepotřebovala znát referenci na identitu, k níž patří, můžeme celý atribut vynechat.

Při relaci One-to-one je možné definovat mapování speciálně pomocí primárního klíče. K tomu stačí použít anotaci @PrimaryKeyJoinColumn namísto @JoinColumn(name = ...). Pokud instance obou entit mají stejný identifikátor, Hibernate dokáže entity spojovat na základě tohoto identifikátoru. Výhodou je, že v databázové tabulce vlastníka relace není třeba vytvářet navíc žádný sloupec. Nevýhodou naopak to, že identifikátor instancí pak nelze snadno měnit, protože se vyskytuje ve více tabulkách.

Many-to-many

Situace: Jedna role může opravňovat uživatele k účtům na více koncových systémech (schématech). K jednomu schématu může opravňovat více rolí.

  • Entita Role – vlastník relace
    @ManyToMany
    @JoinTable(name = "roles_schemas", 
    		joinColumns = @JoinColumn(name = "role"),
    		inverseJoinColumns = @JoinColumn(name = "resource_schema"))
    private List<Schema> schemas;
  • Entita Schema
    @ManyToMany(mappedBy = "schemas")
    private List<Role> roles;

Vazba: Vytvoří se nová databázová tabulka „roles_schemas“, která udržuje informace o mapování rolí a schémat. Sloupec „role“ zde obsahuje identifikátor role a sloupec „resource_schema“ obsahuje identifikátor schématu (obojí jsou primární klíče).

Hibernate a CzechIdM

Identity Manager CzechIdM používá Hibernate ORM pro persistenci veškerých dat do databáze.

Standardní entity, které jsou součástí zdrojového kódu CzechIdM (identity, organizace, role, systémy,…), používají JPA a anotace. Konfigurační soubor pro persistenci entit je umístěn v CzechIdM-ejb.jar/META-INF/persistence.xml. Pokud bychom se v budoucnu rozhodli přejít na jiný ORM framework, ve zdrojovém kódu by to znamenalo žádné, nebo jen minimální úpravy.

CzechIdM používá jako workflow engine technologii jBPM. Tato technologie ukládá svá data do relační databáze také pomocí Hibernate ORM, přičemž používá přímo specifické metody Hibernate. Konfigurační soubor pro jBPM je umístěn v CzechIdM-ejb.jar/jbpm.hibernate.cfg/hibernate.cfg.mysql.xml a jednotlivé mapovací soubory pro entity jBPM jsou umístěny v knihovně jbpm-jpdl.jar. Výhodou tohoto přístupu je, že jsme mohli provést drobné změny v konfiguraci ukládání entit jBPM do databáze, aniž bychom museli znovu sestavovat celou knihovnu jBPM ze zdrojových kódů.

Spojení CzechIdM s databází udržuje aplikační server JBoss. V obou konfiguračních souborech je tedy uveden odkaz na tentýž datasource (java:/CzechIdMDatasource). Můžeme tedy konfigurovat či optimalizovat spojení s databází pro oba persistentní moduly zároveň.

Závěr

Tento článek obsahuje základy použití technologie Hibernate ORM zejména z pohledu Java vývojáře. Zdaleka jsme nepokryli všechny otázky, které by zvídavého čtenáře napadly, ale nic vám nebrání zaslat je na můj e-mail alena.peterova@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ů :-)

Optimalizace jBPM enginu – uchovávání informací o workflow v databázi

jbpm

V CzechIdM využíváme workflow pro vykonávání aplikační logiky systému. Všechna tato workflow běží na enginu jBPM. O každém běžícím workflow si jBPM v standardně uchovává spousty informací jako jsou proměnné, aktuální stav apod. Tyto informace si ukládá do databáze a zůstávají v ní i poté, co dané workflow skončí, což v určitých případech způsobuje nárůst velikosti databáze. Proto jsme hledali způsob optimalizace jBPM.

Dosud jsme v případě velkého nárůstu databáze řešili ručním promazáním příslušných jBPM tabulek. Nyní jsme ho ale vyřešili sofistikovanějším způsobem, o kterém se právě dozvíte v tomto článku.

Řešení – správce workflow

Vytvořili jsme správce, který eviduje všechna spuštěná workflow a průběžne maže ta nepotřebná.

Každé workflow beží pod uživatelem a každý uživatel má přiděleno svoje unikátní sessionId – to identifikuje relaci jeho připojení k CzechIdM. Když dojde ke spuštění nového workflow, tak se toto workflow zaregistruje u správce pod sessionId uživatele, který ho spustil. Jakmile workflow doběhne, předá zprávu správci a ten ho rovnou smaže.

V CzechIdM používáme ale i workflow, která sama od sebe nikdy neskončí. To jsou zpravidla workflow, která zobrazují nějakou stránku. Takováto workflow jsou mazána poté, co skončí session uživatele (odhlásí se sám, nebo je automaticky odhlášen). Správce probere všechna workflow, která byla pod daným uživatelem spuštěna, a všechny je smaže.

jBPMDiagram komunikace komponent

Jediná výjimka je v případě workflow, která generují schvalovací požadavek. V tomto případě chceme, aby se workflow uchovávala i po skončení session uživatele, který daný požadavek vytvořil.

Abychom rozlišili smazatelná workflow od těch, které smazat nemůžeme, rozšířili jsme jejich definici o nový atribut – killable. Při nastavení killable=false říkáme správci, že takové workflow je potřeba uchovat v databázi i po skončení session uživatele a on ho tím pádem ignoruje.

<!-- definice smazatelneho WF-->
<process-definition  xmlns="urn:jbpm.org:bcv_jpdl-3.2"  name="user.edit" killable="true">

Promazání starých workflow

Výše popsaný správce ale řeší pouze nově spouštěná workflow a ne ta, co již déle leží v databázi. Bylo tedy zapotřebí projít databázi a smazat z ní nepotřebná workflow.

Instance workflow je v jBPM reprezentována objektem ProcessInstance. Ten se ukládá do tabulky databáze JBPM_PROCESSINSTANCE. Co zpravidla zabírá nejvíc místa v databázi, jsou tabulky obsahující proměnné použité ve workflow. Ty jsou uloženy v tabulkách JBPM_BYTEARRAY, JBPM_BYTEBLOCK a JBPM_VARIABLEINSTANCE. JBPM_VARIABLEINSTANCE obsahuje seznam použitých proměnných pro každé workflow a jejich hodnoty. V případě nestandardních typů proměnných jsou jejich hodnoty uloženy až v tabulkách JBPM_BYTEARRAY či JBPM_BYTEBLOCK.

Vytvořili jsme pravidlo clearCompletedProcessInstancesFromRepository, které postupně prochází databázi a maže z ní stará workflow. Každé workflow se načte z databáze do aplikace, kde se z něho zrekonstruuje objekt ProcessInstance, ten se korektně ukončí metodou instance.end() a smaže se z databáze metodou context.getGraphSession().deleteProcessInstance(instance).

Takhle smažeme všechna workflow, která v sobě nenesou nedokončený schvalovací úkol.

// Strucny vytah pravidla mazajici stare WF
public Object execute(JbpmContext context) {
    Session session = context.getSession();	
    List result = session.createSQLQuery("select ID_ as id from JBPM_PROCESSINSTANCE;")
        .addScalar("id", new org.hibernate.type.LongType()).list();

    for (int i = 0; i < result.size(); i++) {
        ProcessInstance instance = context.loadProcessInstance(Long.valueOf(result.get(i)));
        if (!canBeDeleted(instance)) continue;

        instance.end();
        context.save(processInstance);
        context.getGraphSession().deleteProcessInstance(processInstance);
    }
}

V případě, že se vůbec schvalovací workflow nepoužívají, je možné kompletně smazat všechny jBPM tabulky (TRUNCATE), což je ostatně mnohem rychlejší.

Na co jsme narazili

Během testování funkčnosti naší opravy jBPM jsme narazili na několik záludností, u nichž jsme dále zvážili, jaký dopad mohou mít na uživatele a následně se rozhodli pro způsob řešení.

  • Workflow spuštěné samotným CzechIdM, např. naplánovaná úloha, má přiřazené umělé sessionId; neexistuje žádná session, na jejímž konci by se mohlo workflow smazat z databáze. Pokud nedoběhne, zůstane v databázi natrvalo.
    Řešení: Plánované procesy by měly vždy doběhnout bez chyby.
  • Pokud uživateli expiruje session a klikne např. na záložku Uživatelé, spustí se workflow user.list, které neprojde přes kontrolu oprávnění. CzechIdM pak uživatele přesměruje na přihlašovací stránku. Nicméně ProcessInstance se ještě zapsalo do repository (START_=null) a už tam zůstane navždy.
    Řešení: Nevytvářet v tomto případě ProcessInstance vůbec, zkontrolovat ještě před spuštěním workflow, že je uživatel přihlášen.
  • Smazáním rodičovského workflow se vyvolá smazání jeho potomků. Při mazání procesů je tedy vhodné kontrolovat, jestli dané workflow už náhodou nebylo smazáno, aby se zbytečně nevyhazovaly výjimky. Na to lze použít JbpmContext.getProcessInstance (JbpmContext.loadProcessInstance vyhodí rovnou výjimku, když proces neexistuje – snaží se ho načíst).
    Řešení: Vyřešeno obecně. Při skončení session se ve správci projde nejprve celý seznam spuštěných workflow a odeberou se z něj všechny non-killable workflow a jejich předci. Zbylá workflow ze seznamu se mohou smazat z databáze. Přičemž u každého prvku seznamu se nejprve ověří, že pořád ještě v databázi existuje a může být tedy smazán.
  • Pokud rodičovský proces není killable, potomek je killable a nedoběhnul, pak po vypršení session správce vyvolá ukončení procesu potomka. Při ukončení potomka jBPM notifikuje rodiče, že může pokračovat ve výpočtu. Nicméně v té chvíli už neexistuje session, což může vést k výjimce „No application context active“. Potomek se z tedy repository nesmaže, jen mu zůstane příznak „ukončen“. Ovšem toto je velmi nepravděpodné a u nás v praxi nenastane.

Závěr

CzechIdM stále vylepšujeme, doplňujeme a rozšiřujeme jeho možnosti. Úkolů ko zlepšení máme stovky, klíčovým rozhodovacím faktorem je pro nás názor našich zákazníků. Ve stručnosti, pracujeme na těch vylepšení, které chtějí zákazníci.

Optimalizace jBPM byl poměrně hluboký zásah do klíčové části CzechIdM, proto jsme postupovali velmi obezřetně. Po týdnu vývoje jsme vytvořili hot-fix produktu a  vylepšení nasadili i u prvního zákazníka. Samotné nasazení do produkčního provozu u zákazníka i s otestováním zabere kolem 1-2MD dle velikosti zákaznického řešení. Nejvíce je věnováno přetestování.

Tímto jsem zde probral všechna vylepšení, které jsme provedli nad enginem jBPM. Kdybyste řešili podobné záludnosti s jBPM nebo jen měli nějaké dotazy, neváhejte mě kontaktovat na filip.mestanek@bcvsolutions.eu.

Pomáháme spravovat přes 2 000 000 účtů!

Je mi potěšením Vám oznámit, že jsme v lednu 2014 zdolali další magickou hranici v počtu spravovaných účtů na napojených systémech. K dnešnímu dni CzechIdM a Sun IdM u našich zákazníků pracuje s neuvěřitelnými 2 204 122 účty napříč všemi segmenty trhu: pomáhá ve zdravotnictví, ve školství, ve státní správě i v soukromém sektoru.

pocitadlo

Pokračování textu

Nabízíme nemocnicím pomoc s certifikáty – produkt eCert

Aktuálně stojí IT oddělení nemocnic před bezpochyby velkým úkolem a to zavedením elektronických receptů (tzv. eReceptů). Vzhledem k očekávanému termínu zavedení prvního ledna 2015, je již nejvyšší čas danou problematiku řešit. Dají se ovšem procesy se zavedením a používáním eReceptů při stovkách až tisících lékařů či sester nějak automatizovat a tím podstatně zjednodušit a zrychlit?

Logo-eCerT

Na základě desítek osobních schůzek a rozhovorů s odpovědnými osobami v nemocnicích jsme vyvinuli specifický produkt eCert, který významnou měrou usnadní a ulehčí zavedení a správu elektronické zdravotní dokumentace.
Produkt pomáhá ve Všeobecné fakultní nemocnici v Praze.

Automatizace životního cyklu certifikátu nemocnicím ulehčí a zrychlí celý proces žádosti, vydání, používání a případně i revokace certifikátu. Již není nutné aby lékaři stáli opakovaně fronty na poště a čekali ve frontách. Pomocí eCert si podají žádost o certifikát jediným kliknutím. Potom je nutné osobně ověřit svou totožnost (toto je ze zákona povinné) na pracovišti certifikační autority.  Po vydání certifikátu si lékař již jen vyzvedne privátní část klíče na tzv. tokenu a může okamžitě podepisovat zdravotnickou dokumentaci. O všechny ostatní procesy se postará eCert spolu s certifikační autoritou.

Chcete-li i Vy ulehčit a zrychlit procesy spojené s elektronickou zdravotní dokumentací, neváhejte nás kontaktovat na info@bcvsolutions.eu a navštívit web www.ecert.cz. Uděláme maximum abychom Vám pomohli.

Nový monitoring systému CzechIdM

Od chvíle, kdy jste si tu mohli přečíst článek o nástroji pro monitoring našeho Identity Managementu CzechIdM, už uplynula pěkná řádka měsíců a dnes jsme zase o něco dál. V nové verzi CzechIdM, která je právě testována a brzy bude představena veřejnosti, je aktivní monitoring prostředí propracovanější a nabízí administrátorům spoustu dalších možností a hlavně jednoduchou konfiguraci. Pojďme se společně podívat, co všechno můžeme v nové verzi CzechIdM monitorovat a jak si monitoring přizpůsobit podle svých představ.

Monitoring Pokračování textu