V minulém čísle jsme si představili systém K2 společnosti SourceCode pro automatizaci obchodních procesů, zmínili se o jeho verzích BlackPoint (ten malej) a BlackPearl (ten velkej) a podrobně popsali, jak nám tento systém může rozšířit možnosti a výrazně ulehčit tvorbu workflows v systému Microsoft SharePoint.

externí autořiexterní autoři
SoftwareSoftware
16.05.2011 13:12:0016.05.2011 13:12:00

externí autoři

externí přispěvatelé magazínu softwarový QUAS

ALSO Czech Republic s.r.o.
+420 222 512 201
+420 603 442 434
daquas@daquas.cz
Anny Letenské 7, Praha 2

Chytré objekty v K2

V minulém čísle jsme si představili systém K2 společnosti SourceCode pro automatizaci obchodních procesů, zmínili se o jeho verzích BlackPoint (ten malej) a BlackPearl (ten velkej) a podrobně popsali, jak nám tento systém může rozšířit možnosti a výrazně ulehčit tvorbu workflows v systému Microsoft SharePoint.

Dnes se zaměříme na jeden důležitý aspekt systémů K2, který zdánlivě s procesy a systémem SharePoint nesouvisí. Podíváme se na K2 jako na integrační platformu, nebo spíše na to, jak technologie K2 SmartObjects překonává vžité představy o integračních platformách jako systémech pro pár vyvolených, kde schopnost hovořit celý večer o SOAP a XSD je nutnou podmínkou pro členství v tomto exkluzivním klubu.
O integraci hovoříme vždy, pokud potřebujeme, aby o sobě různé systémy používané organizací „věděly“. Ať už vědět znamená mít pouze možnost číst data z jiných systémů, nebo do nich i aktivně vstupovat a měnit data v nich uložená. Obvykle máme na mysli propojení dvou specifických systémů a řešíme, jak to zařídit, aby se data z jednoho systému nějakým způsobem dostala do systému jiného. Pomineme-li tradiční způsob propojení systémů, tedy v lepším případě export (v horším případě tiskárnu nebo obrazovku) dat na straně jedné a import, načtení dávky, či ruční naklepání dat na straně druhé, existuje řada sofistikovaných systémů, jako je například Microsoft BizTalk Server, a samozřejmě vždy máme možnost si propojení naprogramovat (jsou-li propojované systémy dostatečně otevřené).

Systémy a entity

Všechny tyto systémy mají samozřejmě svůj nezanedbatelný význam a opodstatnění, ale ve většině případů mají jedno společné. Příliš se zaměřují na samotné systémy, na protokoly, na API a podobné otázky, které jsou pro většinu pracovníků rozumějících business stránce příliš technické. Naopak tyto systémy se mnohem méně zaobírají vlastními daty, jejich strukturou, logikou a významem z pohledu jejich business využití.
Několik chytrých hlav, a není náhoda, že se tyto hlavy sešly zrovna ve společnosti SourceCode, na to šlo poněkud jinak a výsledkem jejich snažení je technologie K2 SmartObjects. Tato technologie, jak již název napovídá, klade na první místo data. Každá společnost pracuje každodenně s řadou obchodních entit, jako je například Zákazník, Objednávka nebo Zaměstnanec. V obecné rovině je význam každé z těchto entit chápán v celé společnosti víceméně shodně. Lišit se většinou bude pouze to, jaké informace tato entita zahrnuje, a to podle způsobu, jak který pracovník s touto entitou přichází do styku. Entita zaměstnanec bude například pro IT administrátora zahrnovat malinko jiné atributy (uživatelské jméno, e-mailová adresa…) než pro manažera osobního oddělení (datum nástupu, pracovní zařazení…) a než například pro pracovníka mzdové účtárny (plat, vybraná dovolená…). S největší pravděpodobností však nebude v organizaci existovat jeden systém, který by obsahoval veškeré informace o jedné entitě. V případě zaměstnance bude část v HR systému, část v AD a další část v úplně jiném systému, nebo dokonce můžou existovat informace, které nejsou vůbec v žádném systému (například existují pouze ve formě papírového dokumentu v šanonu některého oddělení).
Netvrdíme, že v organizaci nejsou jednotlivé systémy propojeny, že například CRM systém není schopen z ERP systému pro daného dodavatele přečíst obrat za minulý rok, nebo naopak do ERP systému zaznamenat zvýšení kreditního rámce daného odběratele. To se však jedná o integraci mezi systémem A a B, aniž by z toho například profitoval systém C. Pro zajímavost otázka pro kroužek mladých matematiků: Kolik „propojení“ bychom museli naprogramovat, abychom propojili všechny systémy v dané organizaci? Ano, je to n * (n - 1) propojení, což už jen při počtu 6 systémů není úplně málo propojení (pro ty, kteří se nemohou dopočítat – nestačí napojit systém A na systém B, musíme i opačně napojit B na A, což není jedno a to samé).

Jak chytré objekty fungují aneb atributy a metody

Jak jsme již zmiňovali, filozofie SmartObject je malinko jiná. Nejprve identifikujeme entity, které jsou pro nás v rámci organizace zajímavé, a následně modelujeme, jaké veškeré informace nebo atributy můžeme každé entitě přiřadit. Teprve potom budeme u každého atributu zjišťovat, který že to systém by měl tuto informaci v sobě obsahovat. U většiny atributů budeme schopní takovýto systém nalézt, u některých atributů dokonce můžeme nalézt více než jeden systém. A u některých atributů nenalezneme systém žádný. Ještě než si ukážeme, jak takovýto objekt vytvoříme v K2, musíme se zmínit o dvou důležitých aspektech chytrých objektů.
Nejprve jak to zařídíme, aby objekty „něco dělaly“, abychom do nich dostali data a následně data po změnách uložili. Při definici chytrých objektů kromě jejich atributů musíme definovat i jejich chování, tedy metody. Tyto metody většinou (ale nemusí tomu tak být) pokrývají obligátní CRUD operace, tedy 5 metod (R dvakrát). Definujeme metodu pro vytváření objektů, čtení jednoho objektu, čtení kolekce objektů, ukládání existujících objektů a jejich mazání. Způsob, jak to zařídíme, aby si objekt správně načetl data z několika různých systémů a následně do nich data uložil zpět, naznačíme v kostce později. Nicméně na podrobný výklad bychom potřebovali několik Quasů čistě pro tento účel, takže nezbyde než uvěřit, že to chytré objekty mají nějak vymyšlené.
Druhým, neméně zajímavým aspektem je pak pochopitelně to, k čemu je nám takový chytrý objekt dobrý. Jelikož se jedná o K2 technologii, pak samozřejmě systémy BlackPearl a BlackPoint (zde v poněkud omezenější míře) jsou s chytrými objekty „jedna ruka“. V procesech můžeme objekty používat pro čtení či zápis, pro rozhodovací logiku a podobně. Pokud by nám to nestačilo, můžeme chytré objekty publikovat ve formě webových služeb a následně je pak použít prakticky v jakékoliv aplikaci. Smyslem tedy je vytvořit jednotný, standardní pohled na entity používané v organizaci a nabídnout tím všem systémům jednoduchý způsob, jak s těmito entitami pracovat. Aplikace jsou pak jednak zbaveny nutnosti integrace se všemi ostatními aplikacemi, ale i zodpovědnosti za to, že data budou čtena z toho správného datového zdroje.
Nyní se v krátkosti podíváme na to, jak se chytré objekty vytvářejí v systému K2 BlackPearl. Nejprve je nutné vytvořit nový objekt a nadefinovat příslušné atributy:

Jak jsme již zmiňovali, musíme též definovat metody, které budou plnit objekt daty, a metody pro zápis či mazání. K tomu potřebujeme jednak chytrou službu (Smart Service), která je schopná načíst data (a samozřejmě též zapsat) z příslušného systému, a definici, jak se vstupy či výstupy z metod této služby mapují na jednotlivé atributy chytrého objektu. K2 BlackPearl v sobě standardně obsahuje chytré služby pro čtení a zápis dat z SQL databází, Active Directory, SharePointu, Microsoft CRM a spoustu dalších. Pokud by nám dodané služby nevyhovovaly nebo nedostačovaly, vždy si můžeme vytvořit vlastní, specifické pro systém, ze kterého potřebujeme číst nebo do kterého potřebujeme zapisovat data.
Pro náš ukázkový objekt Zaměstnanec jsme si nadefinovali metodu Load. Tato metoda je typu Read, což znamená, že jejím cílem je vrátit právě jeden chytrý objekt představující specifického zaměstnance:



Při každém volání metody musíme specifikovat číslo zaměstnance, které bude použito jako klíč pro vyhledání zaměstnance v příslušném systému. Toto číslo je definováno jako vstupní parametr metody:

Pro zjednodušení předpokládejme, že k vytvoření kompletního objektu Zaměstnanec potřebujeme data ze dvou systémů – HR systému a Active Directory. Nejprve provedeme volání do HR systému, který od nás vyžaduje číslo zaměstnance. To máme k dispozici, neboť bylo specifikováno při volání metody. Data vrácená ze služby pro HR systém mapujeme na příslušné atributy objektu:



Jednou z těchto hodnot je i uživatelské jméno zaměstnance, což se nám hodí, neboť ho hned použijeme jako vstupní parametr pro službu Active Directory:



V tomto případě jsme si vystačili pouze se dvěma službami, ale samozřejmě ve složitějších případech jich může být mnohem více. Důležité je volat tyto služby ve správném pořadí, pokud se výstupy z jedné služby stávají vstupy jiných služeb:

Nakonec tedy máme objekt s příslušnými atributy a metodami:

Cílem článku bylo v krátkosti naznačit způsob integrace aplikací pomocí technologie K2 SmartObjects. Na rozdíl od tradičních, techničtěji orientovaných systémů se chytré objekty mnohem více zaměřují na obchodní entity, tak, jak jsou organizací používány při každodenních činnostech.

Aleš Klenka | Marap