Výběr specifikace business rules pro praktické nasazení v podnikové informatice

Výběr specifikace business rules pro praktické nasazení v podnikové informatice Stanislav Vojíř

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Nám. W. Churchilla 4, 13067 Praha 3 e-mail: [email protected] Abstrakt: Jedním z velmi vhodných konceptů vývoje a správy podnikové informatiky je oddělení obchodní logiky a pravidel od informačních systémů a technologií. Vhodným nástrojem pro toto oddělení je business rule přístup. Na business rule přístupu je postavena řada dílčích specifikací, standardů a implementací. Výběr konkrétní specifikace pro praktické použití business rules tedy není jednoduchou záležitostí. V rámci textu je představen koncept business rules v souvislosti s nejčastěji užívanými standardy a specifikacemi. Následně je definován proces výběru konkrétní specifikace business rules pro konkrétní použití v rámci podnikové informatiky. Klíčová slova: business rules, business pravidla, business rule management system, BRMS, rule engine Abstract: One of the most suitable concepts of development and management of business informatics is the separation of business logic and business rules from information systems and technologies. This separation can be realized using the business rule approach. Business rules are not only one standard or technology. It is rather an ideological concept. There are much standards and software implementations based on this concept. This paper aims to introduce the most used specifications of business rules. Subsequently, there is defined the process of selection of a suitable specification and software tools for practical usage of business rules in the corporate IT. Key words: business rules, business rule management system, BRMS, rule engine

1. Úvod V současném rychle se měnícím světě je nutné, aby se tempu rychlých a častých změn přizpůsobily též obchodní společnosti i nekomerční organizace. Cílem řízení podnikové informatiky je poskytnout podniku, respektive v něm probíhajícím procesům, co možná nejlepší informatickou podporu prováděných činností. V rámci této informatické podpory je poměrně obtížné naplňovat všechny požadavky podniku a zároveň se rychle přizpůsobovat změnám těchto požadavků. V souvislosti se stále častějším využíváním moderních architektur v rámci podnikové informatiky, zejména architektury orientované na služby (SOA) a rozvoji konceptu Model Driven Architecture (MDA), a potřebné orchestraci jednotlivých komponent podnikového informačního systému je čím dál tím více kladen důraz na oddělení rozhodovací (obchodní) logiky od implementačních kódů vytvářených softwarových řešení. V oblasti integrace je využíváno orchestrace dílčích služeb za použití konektorů a univerzálních rozhraní (například Enterprise service bus - ESB). (Chappell, 2004) Zároveň také jednotlivé

36

SYSTÉMOVÁ INTEGRACE 3/2015

Výběr specifikace business rules pro praktické nasazení v podnikové informatice

podnikové procesy mohou být modelovány a řízeny za použití technologií BPEL/BPM. Ve všech těchto přístupech je kladen důraz na unifikaci použité technologie a opět na oddělení obchodní logiky. Výhodou tohoto oddělení je možnost jednoduššího a rychlejšího provádění změn v obchodní logice, přičemž není nutné často procházet fázemi návrhu a implementace aplikací. Vhodným způsobem oddělení obchodní logiky od kódu aplikací je využití business rules. Business rules však nejsou jednotnou technologií, ale spíše myšlenkovým konceptem podporovaným řadou specifikací a nástrojů. Není tedy snadné vybrat vhodnou specifikaci a software pro konkrétní zamýšlenou aplikaci. Cílem tohoto textu je charakteristika a porovnání často užívaných standardů a specifikací business rules za účelem usnadnění výběru konkrétní varianty pro použití při definici podnikových procesů, pro tvorbu rozhodovacích systémů a v rámci ESB. Na základě srovnání dostupných specifikací a souvisejících implementací a výsledků praktického testování je v textu definován proces výběru konkrétní specifikace pro konkrétní praktické nasazení. V podstatě všechny publikace z oblasti business rules jsou věnovány jednotlivým specifikacím, nikoliv však jejich komplexnějšímu srovnání a samotnému problému výběru vhodné varianty business rules. Byť před praktickým využitím business rules je nutné vždy nutné vybrat konkrétní specifikaci.

2. Business rules – od termínů k pravidlům Business rules jsou jedním z možných přístupů k modelování podniku. Nejedná se o konkrétní technologii či metodiku, ale spíše o způsob modelování, na kterém je postavena řada dílčích přístupů. Pro tvorbu business rule modelu je nutné vzít do úvahy tři základní faktory – „proč“ (motivaci, podnikové cíle), „jak“ (činnosti a procesy) a „co“ (datový základ modelování, definice užívaných termínů) má být vykonáváno.

2.1 Co jsou business rules? Ve smyslu dnešního chápání bylo jako „business rule“ již v roce 1995 označeno „tvrzení, které definuje či omezuje některé aspekty podniku za účelem prosazení podnikové struktury či řízení a ovlivnění chování podniku“. Součástí definice je též podmínka, že „business rule nelze rozložit na dílčí pravidla či jej vypustit bez ztráty důležité informace o podnikání“. (Hay, a další, 2000) Z historického hlediska se business rules vyvinuly z expertních systémů. Na rozdíl od nich se však business rules prosadily – zejména z důvodu svého poněkud odlišného zaměření. Šlo o jednoduchá pravidla, která si nekladla za cíl vytvářet komplexní expertní rozhodnutí, ale zachytit již existující, platná podniková pravidla a vynutit jejich dodržování. Teprve v posledních letech směřuje vývoj business rules zpět k původnímu zaměření expertních systémů – např. v oblasti vytváření klasifikačních a doporučovacích systémů. Ačkoliv je tento text napsán v češtině, je v něm vyžíván původní anglický termín „business rules“. Z hlediska překladu by teoreticky bylo možné využívat termín „obchodní pravidla“, tento je však obvykle spojován spíše s obchodními podmínkami. V rámci česky psaných textů obvykle využíván původní anglický termín, či částečně počeštěné termíny „business pravidla“ či „byznys pravidla“.


37

Stanislav Vojíř

2.2 Modelování prostřednictvím business rules Pro modelování fungování podniku prostřednictvím business rules je typické rozšíření tradičního přístupu směrem shora-dolů (tj. od podnikových cílů, přes procesy k jednotlivým činnostem) o směr opačný, tj. zdola-nahoru. Business rules vycházejí z předpokladu, že pro modelování podnikových procesů a jejich vztahů je vhodné vycházet z definice jednotlivých termínů a faktů a následně popsat realitu prostřednictvím sady jednoduchých a srozumitelných pravidel. Tato pravidla je možné definovat nezávisle na aktuálně použitém IS/ICT řešení a mohou tedy být užívána pro komunikaci jak business-business a business-IT, tak v rámci IS/ICT. (Ross, 2003) Základním charakteristikou business rule přístupu je: „Rules build on facts, and facts build on terms.“ (Ross, 2003) Tento princip vystihuje celou základní podstatu a postupnou tvorbu sad pravidel. Základním stavebním kamenem jsou termíny (terms). Termínem by měla být vždy označena konkrétní entita reálného světa (například věc, stav či funkce). Na základě termínů a jejich vztahů jsou následně definována fakta. Tyto definice mohou mít podobu jednoduchých vět, které popisují vztah mezi dvěma termíny – například: „Zákazník zadává objednávku.“ Fakta tedy neoznačují konkrétní entitu, ale jednoduchou základní znalost. Termíny (a v některých přístupech také fakta) je vhodné definovat v rámci terminologického slovníku, jenž je následně využíván pro definici všech samostatných pravidel. Pro tvorbu business rules je vhodné dodržovat celou řadu dílčích principů. Pravidla by měla být vyjádřena explicitně, v prostém jazyce, měla by být řízena a měla by být motivována identifikovatelnými a zároveň důležitými faktory. (Ross, 2003) Dílčí zásady pro vytváření business rules byly deklarovány v Manifestu business rules - (Business Rules Group, 2003). Z hlediska logiky jsou business rules vyjádřeními predikátového kalkulu ve tvaru „antecedent  konsekvent“. Predikáty jsou z pohledu business rules označovány jako fakta. Pravidla mohou obsahovat logické spojky (and, or, not) a kvantifikátory (existenční i univerzální). V rámci business rule přístupu mohou jednotlivé logické formule obsahovat nejen proměnné (obecné specifikace termínů), ale také konkrétní hodnoty, přičemž právě definice pomocí konkrétních hodnot usnadňuje získávání business pravidel od pracovníků managementu. (Ross, 2003) V reprezentaci řady standardů jsou samotná pravidla zaznamenávána v IF-THEN tvaru. Antecedent daného pravidla je označován jako podmínka, konsekvent je jeho tělem. Tělo pravidel v IF-THEN tvaru může obsahovat nejen konkrétní logickou formuli, ale v řadě přístupů také programový kód, který má být vykonán. Z hlediska typu lze rozlišit business rules deklarativní (definující další fakta), represivní (zajišťující konzistenci odvozovací báze), odvozovací a pravidla akční/reakční (vyvolávající konkrétní aktivitu).

2.3 Aplikace business rules v praxi V současné době nejčastějšími aplikacemi business rules je jejich využití v rámci systémové integrace (obvykle na úrovni Enterprise Service Bus), v rámci systémů pro podporu rozhodování a za účelem popisu podnikových procesů. V následujících odstavcích je představeno využití business rules v těchto případech použití.

38



2.3.1 Systémová integrace – směrování v rámci Enterprise Service Bus Jedním z praktických použití business rules je jejich aplikace v rámci integrace dílčích podnikových aplikací a systémů. Motivací pro integraci dílčích systémů lze nalézt celou řadu – automatizace podnikových procesů, zefektivnění práce s daty a snížení jejich duplicit. Potřebu integrace na datově-aplikační úrovni lze vedle již tradičních přístupů (point-to-point propojení aplikací, dávkové aktualizace, dílčí klient-server architektury) s výhodou řešit také prostřednictvím nástrojů message-oriented middlewaru, či pokročileji prostřednictvím rozhraní Enterprise Service Bus (ESB). ESB představuje jednotné rozhraní (sběrnici) pro výměnu dat mezi jednotlivými zapojenými aplikacemi a jejich komponentami, přičemž odstiňuje každou konkrétní aplikaci od potřeby integračních požadavků aplikací ostatních. Jednotlivé aplikace jsou napojeny pouze na tuto sběrnici prostřednictvím ESB Service Containeru, v rámci kterého jsou definována komunikační rozhraní. Kontejnery tedy tvoří abstrakční vrstvu nad rozdílnými typy aplikací – bez ohledu na platformu. ESB zajišťuje funkcionality doručování zpráv mezi aplikacemi, přičemž splňuje požadavky na konverzi dat, zaručení jejich doručení a podporu asynchronní komunikace. Typickým případem aktivního využívání business rules je jejich aplikace v rámci směrování prostřednictvím ESB a v rámci transformace formátu zasílaných zpráv. V rámci směrovače ESB je využívána báze pravidel definujících podmínky pro směrování zpráv vhodným příjemcům. Tato pravidla jsou definována v IF-THEN tvaru, tj. obsahují požadavky (či jejich sadu) na obsah konkrétní zasílané zprávy a podle daného obsahu upravují její směrování. Významnými zástupci tohoto využití business rules jsou IBM WebSphere server, v rámci kterého jsou pravidla užívána ve spojení s modely procesů v notaci BPM. Užívaná pravidla jsou ve formátu ILOG JRules (Ritchie, a další, 2010) Obdobně v řešení Microsoft BizTalk Server jsou business rules užívána pro definici dynamických transformací a pro směrování zpráv. (Microsoft, 2013)

2.3.2

Popis podnikových procesů

Jedním z problémů procesního řízení je využití vhodné podrobnosti popisu jednotlivých podnikových procesů. Podrobně popsané procesy mají standardizované vstupy, výstupy i jednotlivé činnosti prováděné v rámci daného procesu a jsou dobře měřitelné a kontrolovatelné. Zároveň je však podrobný popis vhodný pouze pro procesy, které probíhají v podniku opakovaně za obdobných podmínek. Naopak nepříliš podrobné popisy procesů jsou vhodné pro procesy vyžadující větší míru inovativnosti a dynamičnosti realizace. Podrobnější definice procesu zvyšuje kolektivní znalost podniku a snižuje nároky na znalosti a zkušenosti jednotlivých zaměstnanců a vede k možné automatizaci (zejména při definici procesu pomocí BPEL/BPM), zároveň však omezuje možnost flexibilního přizpůsobování procesů změněným podmínkám trhu. (Voříšek, 2008) Definici procesu v BPEL lze s výhodou užívat v rámci interaktivní aplikace k řízení dílčích činností. Pokud je do rozhodovacích uzlů takto definovaného procesu zapojen business rules enginu, lze dosáhnout větší variability procesu i v situaci, kdy je proces podrobně definován. Sady business pravidel jsou snadno upravitelné, díky čemuž může být průchod celým procesem variabilnější a snadněji konfigurovatelný. Business rules mohou též přímo spouštět dílčí podprocesy, inicializovat jiné procesy atd. (Boyer, 2008) Specifickým případem aplikace business rules je jejich užití ve fázi analýzy informačního systému. Při klasickém přístupu k modelování podnikových procesů je SYSTÉMOVÁ INTEGRACE 3/2015

39

Stanislav Vojíř

obvyklé vycházet z obecné definice procesů, které jsou posléze zpřesňovány a do modelu jsou přidávány dílčí činnosti a větvení metodou shora-dolů. Business rules přístup lze využít způsobem opačným, tj. pro modelování od jednotlivých dílčích entit směrem nahoru, k definici procesů - v praxi obvykle do fáze, kdy se oba směry modelování potkávají. V rámci tohoto přístupu jsou nejprve definovány jednotlivé základní termíny, čímž je vytvořen terminologický slovník. Tento slovník je dále rozšiřován prostřednictvím definičních business rules, která slouží k doplnění dalších termínů na základě jejich odvození od termínů již existující. Například termín „VIP zákazník“ lze odvodit pravidlem „VIP zákazník je zákazník, jehož roční obrat je vyšší než …“ Posléze jsou na základě interview s klíčovými zaměstnanci a manažery společnosti doplněna restrikční, integritní a akční pravidla pro řešení obvyklých obchodních případů včetně existujících výjimek. (Ross, a další, 2011).

2.3.3

Rozhodovací a klasifikační pravidla

Třetím častým použitím business rules je jejich aplikace v oblasti operativního rozhodování a klasifikace objektů. Typickým případem je použití sad pravidel pro určování ceny. Velké společnosti mají desítky různých typických cenových tříd svých produktů, zákazníci jsou segmentovány podle regionů, velikosti zakázky atp. Toto použití business rules nacházíme například u společnosti Microsoft. Klasifikační úlohy řešené za použití business rules nacházíme i v řadě finančních institucí (bank, pojišťoven atp.). Většina těchto institucí užívá nástroje pro podporu rozhodování, jejichž cílem je umožnit pracovníkům snadnější posuzování solventnosti klienta a případného s ním spojeného rizika. Tato rozhodnutí mohou následně činit řadoví zaměstnanci jednající s klienty, bez ohledu na potřebnou zvláštní kvalifikaci. Obdobný problém je řešitelný za použití modelů vytvořených na základě dataminingové analýzy či klasických expertních systémů. Výhodou použití business rules je jejich srozumitelnost, modifikovatelnost ze strany doménových expertů a snadná integrovatelnost do podnikových procesů. V současné době se výzkum v této oblasti využití business rules zaměřuje též na možnost přímého využití rozhodovacích a klasifikačních business pravidel – například v systému Open Rules. (OpenRules, Inc.)

3. Specifikace business rules Jak bylo uvedeno v předchozí kapitole, „business rules“ je označení relativně široké skupiny technologií a specifikací. Porovnání existujících standardů (majících často též více specifikací způsobů záznamu) business rules a souvisejících komponent není jednoduchou záležitostí, neboť jednotlivá pojetí pravidel nejsou vzájemně plně kompatibilní. Respektive lze mezi jednotlivými specifikacemi přecházet (automatizace převodu pravidel z jedné specifikace do jiné jsou též častým cílem výzkumů), ale dílčí standardy se liší typy podporovaných pravidel, svým zaměřením a také existující softwarovou podporou. V rámci této kapitoly jsou porovnány nejužívanější standardy a specifikace zaměřené na business rules. Ve výběru jsou zahrnuty jak obecné standardy, tak také často užívané proprietární specifikace jednotlivých odvozovacích enginů. Nejprve jsou představeny jednotlivé dílčí komponenty potřebné pro integraci business rule přístupu do podnikové informatiky. Následně jsou v rámci této kapitoly porovnány jednotlivé specifikace – nejprve prostřednictvím samostatného popisu, poté též v rámci

40



srovnávacích tabulek. Tyto informace jsou důležité pro realizaci samotného výběru vhodné specifikace dle procesu definovaného v kapitole 4.

3.1 Software pro správu a spouštění business rules Pro úspěšné začlenění business rules do informačního systému podniku je nutné zvolit vhodnou softwarovou podporu pro správu pravidel a jejich spouštění. Ačkoliv je možné implementovat vlastní rule engine, obvykle je vhodnější zvolit již existující řešení. Softwarová podpora business rule přístupu se obvykle skládá ze dvou základních částí – komponenty pro správu pravidel a komponenty pro jejich spouštění (vyhodnocování). Samotné spouštění pravidel zajišťuje business rule engine. Jedná se o komponentu, která přebírá na vstupu sadu pravidel (rule set) a sadu instancí objektů, na základě které má probíhat odvozování. Dle typu systému je při odvozování využíváno dopředné či zpětné řetězení (forward či backward chaining), přičemž častěji je užíváno řetězení dopředné – obvykle založené na Rete algoritmu či jeho modifikacích. Některé business rule enginy umožňují též odvozování hybridní – jako příklad lze jmenovat systémy Drools a Jena. (The JBoss Drools Team, 2015) Rule engine je zpravidla dostupný buď v podobě komponenty, která je přímo začlenitelná do vyvíjené aplikace, nebo je integrace s vyvíjenou aplikací dostupná prostřednictvím webových služeb či API. Možnost přímého zpřístupnění sad pravidel v podobě webových služeb je výhodná pro možnost zapojení např. do definice procesu v BPEL. Druhou, velmi důležitou komponentou je systém pro správu pravidel. Tato komponenta je nazývána Business Rule Management System (BRMS). Pravidel je obvykle velké množství, a pokud mají být vhodně užívána, je nutné umožnit jejich centralizovanou správu a řízení. Mezi základní zásady business rules přístupu patří požadavky na jejich management a také na to, že mají být „single-sourced“ – tj. vycházet z jednotného, centrálně řízeného terminologického slovníku (Ross, 2003) Je vhodné, aby BRMS umožnil správu jednotlivých pravidel, terminologického slovníku a také umožnil sdružování pravidel do sad (rule setů).

3.2 Užívané specifikace business rules V současné době je v praxi využíváno poměrně velké množství business rule specifikací a souvisejících nástrojů. V rámci této kapitoly jsou představeny specifikace, o kterých lze reálně uvažovat pro praktické nasazení v rámci podnikové informatiky, mají dostatečnou podporu (komunitní či komerční) a zároveň je podporuje business rule komunita. Pro porovnání specifikací byla využita nejen rešerše specifikací a praktických případů použití, ale též definování stejných business rules ve všech uvedených specifikacích – za účelem posouzení srozumitelnosti a vyjadřovacích schopností.

3.2.1

Semantics of Business Vocabulary and Business Rules – SBVR

Jazyk SBVR (definovaný skupinou OMG) je založen na práci se slovníkovými termíny, mezi nimiž jsou následně definovány vztahy. Slovníkovým termínem je entita reálného světa identifikovaná názvem a popsaná základními vlastnostmi a vztahy k již dříve definovaným slovníkovým termínům. Celá tato myšlenka vychází z předpokladu, že pro úspěšné sdílení informací je nezbytně nutné ujednotit používanou terminologii tak, aby ji všechny zúčastněné strany chápaly jednotně. (OMG, 2008)


41

Stanislav Vojíř

Cílem specifikace je umožnění zachycení business pravidel jakožto vhodného nástroje komunikace. Specifikace SBVR v sobě zahrnuje řadu dílčích specifikací, které však nejsou vzájemně plně převoditelné. Nejčastěji užívaným způsobem záznamu je forma zjednodušeného přirozeného jazyka (specifikace Structured English či specifikace Rule Speak), alternativou je zachycení vztahů mezi slovníkovými termíny v podobě grafu. Pro uživatele je forma omezeného, formalizovaného přirozeného jazyka nejjednodušším způsobem popisu reality. V rámci obou specifikací je k dispozici řada konstruktů, které umožňují vyjádřit míru vyžadování pravidlo a jeho platnost na některé či všechny entity. I v případě XML či UML záznamu business rule odpovídá zachycená struktura „tvaru“ věty v přirozeném jazyce. Pravidla ve formátu SBVR jsou často užívána jako importní/exportní, nejsou příliš často užívána v rámci produkčních systémů. Součástí specifikace je též vymezení je též vymezení se proti alternativním specifikacím (OWL, SWRL, Topic Maps). Specifikace: http://www.omg.org/spec/SBVR/

3.2.2

Rule Markup Language – RuleML

Hlavním zaměřením jazyka RuleML je zajištění „cross-industry“ standardu pro zajištění komunikace mezi řadou dílčích jazyků pro záznam business a logických pravidel. Jazyk je specifikován vedle textového popisu také popisem struktury ve schématech XSD a RelaxNG. RuleML však není pouze výměnným formátem, byť je k tomuto účelu k dispozici velké množství připravených transformací a nástrojů pro obousměrný převod mezi RuleML a jinými specifikacemi. Jazyk je přímo podporován několika odvozovacími enginy a editory – lze jmenovat například Rule Responder, S2Red či Mandrax. Jazyk RuleML je konstruován modulárně a hierarchicky. Umožňuje zaznamenání faktů, odvozovacích pravidel, pravidel pro zajištění integrity a také pravidel reakčních, přičemž uživatelům je umožněno, aby použily jen potřebné typy pravidel (na základě rozdělení základního XML schématu do 12 podjazyků). Kromě záznamu v XML je možné využívat také záznam v podobě RDF grafu s vazbou na ontologie. Specifikace: http://ruleml.org/spec

3.2.3

REWERSE Rule Markup Language – R2ML

R2ML je koncipován jako komplexní a zároveň uživatelsky přívětivý XML formát pro ukládání pravidel. Formát dodržuje zásady model-driven architecture a je postaven na integraci vyjadřovacích schopností řady jiných jazyků (Prolog, SQL, Jena, Jess, RuleML, SWRL, F-logic, OCL). Lze ho tedy považovat za patrně nejuniverzálnější jazyk pro záznam pravidel ve formě XML Podporuje jmenné prostory, rozlišuje mezi koncepty a hodnotami (obdobně jako ontologie) a práci s datovými prvky přejímá z RDF. Jazyk R2ML lze kromě výměny dat mezi systémy pro správu pravidel užívat také pro definici pravidel v rámci ontologií. Někteří autoři považují tento jazyk za vhodnější, než formát SWRL. (Giurca, 2008) Jazyk lze kromě XML formátu zachycovat také v podobě UML, konkrétně v jazyce URML. Samotný jazyk R2ML má poslední verzi navrženou v roce 2008, od té doby lze najít pouze publikace některých možných rozšíření. Specifikace: http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=R2ML

3.2.4

Semantic Web Rule Language – SWRL

Jazyk SWRL vznikl jako na základě kombinace jazyků OWL (OWL DL a OWL Web Ontology Language) a RuleML (Unary/Binary Datalog RuleML) s primáčním 42



zaměřením na možnost definování business rules v rámci ontologií. Na základě této kombinace vznikla varianta zápisu business rules v celé řadě podob, které jsou zpracovatelné metodami sémantického webu. Zjednodušeně lze říci, že pro popis predikátů využívá možností jazyka OWL a pro zápis jednotlivých pravidel jazyka RuleML. Pravidla v jazyce SWRL mohou být zachycena v celé řadě syntaxí vycházejících ze způsobu záznamu ontologií. Nejčastěji užívanými variantami jsou Human Readable Syntax, pro strojové zpracování následně XML a RDF syntaxe. V současné době by dle doporučení W3C měl převzít úlohu jazyka SWRL jazyk RIF – viz dále. Specifikace: http://www.w3.org/Submission/SWRL/

3.2.5

Rule Interchange Format – RIF

Specifikace RIF je ve své podstatě skupinou dílčích specifikací jazyků pro záznam pravidel pro potřeby sémantického webu. Společně s jazykem OWL má jazyk RIF umožnit odvozování v prostředí sémantického webu a rozšířit tak jeho možnosti v kombinaci se slovníky, dotazovacími technologiemi (SPARQL) a linked daty. Pravidla mohou být v rámci RIF specifikována v jednom z možných dialektů s rozdílnými vyjadřovacími schopnostmi (Basic Logic Dialect, Core Dialect, RIF Datatypes, RIF Framework, RIF Production Rule Dialect; z neoficiálních lze jmenovat například RIF-SYLK). Specifikace: http://www.w3.org/standards/techs/rif

3.2.6

Drools - DRL

DRL (Drools Rule Language) je formát pravidel využívaných systémem JBoss Drools, se kterým je specifikace ukládaných pravidel úzce svázána. Jde o specifikaci zaměřenou na praktickou implementaci business rules v rámci informačního systému. Pravidla jsou ukládána v textové podobě, přičemž každé z pravidel je identifikované svým názvem, následně je uvedena podmínka pravidla a poté vykonávané akce. Pravidla jsou svázána s jazykem Java. Specifikace DRL je zaměřena pouze na definici samotných pravidel, terminologickým slovníkem jsou deklarace Java tříd v aplikaci, která spouští komponentu rule enginu. Samotná pravidla mohou vedle volání externích funkcí obsahovat také komplexní popis prováděných akcí včetně definice cyklů a úpravy odvozovací báze pro zajištění komplexního odvozování na základě většího množství pravidel. Specifikace: https://docs.jboss.org/drools/release/6.2.0.Final/drools-docs

3.2.7

Jess Language

Jess je kombinací rule enginu a zároveň skriptovacího jazyka, který umožňuje využívat kompletní Java API. Pravidla je možné zaznamenávat jak v podobě Jess rule language, tak také v podobě JessML (formát založený na XML). Umožňuje definici IFTHEN pravidel, faktů, funkcí a také tvorbu komplexních skriptů. Výhodou je možnost propojení s jazykem SWRL, přičemž pravidla deklarovaná v SWRL lze transformovat do formátu Jess a následně využívat Jess rule engine. Součástí implementace je pouze odvozovací engine využitelný pro odvozování z báze pravidel a logické programování. Není k dispozici žádný externí systém pro správu samotných pravidel. Systém Jess je v zásadě přímým následovníkem expertního systému CLIPS. Specifikace: http://www.jessrules.com/jess/docs/71/basics.html

3.2.8

Jena Rules

Jena Rules je standard a odvozovací engine určený pro zachycování business rules v podobě tripletů, v nichž jsou na místě subjektu a objektu uváděny vhodné kombinace SYSTÉMOVÁ INTEGRACE 3/2015

43

Stanislav Vojíř

proměnných. Pravidla lze uvádět v podobě zpětné, dopředné či hybridní (v tomto případě jde o deklarační pravidlo specifikované podmínkou – např. „A student is diligent if it has at least 60 credit points.“). Specifikaci pravidel dle standardu Jena je možné používat jak pro ukládání pravidel pro přímé odvozování, tak také pro deklaraci business rules v rámci ontologií. Vytvářená business rules jsou obvykle zachycována ve formě RDF s vazbou na ontologické třídy a instance. Systém Jena je v současné době aktivně vyvíjen, v roce 2012 byl přesunut z Apache inkubátoru mezi top projekty. Specifikace: http://jena.apache.org

3.2.9

ILOG Jrules

ILOG JRules je formát v současné době užívaný řešením IBM Websphere server. Jedná se o jeden z velmi často užívaných komerčních business rules systémů. Využíván je vlastní tvar pravidel v IF-THEN tvaru, která spolupracují s definicí objektů v jazyce Java a lze je v rámci serveru snadno propojit s procesy v BPEL. Systém ILOG JRules je svými schopnostmi srovnatelný se systémem Drools. Specifikace: http://www-01.ibm.com/software/integration/business-rule-management/jrules-family/

3.2.10 Open Rules Systém Open Rules je poměrně specifický svým přístupem k definici business rules. Jedná se o sadu programových komponent, které pracují s tabulkami definovanými v Excelu. V tabulkové struktuře je ukládána definice termínů, rozhodovacích struktur a také celé workflow. Samotní tvůrci systému uvádějí jako hlavní výhodu to, že pro jeho používání není nutné studovat žádný jazyk pro záznam pravidel. (OpenRules, Inc.) Systém Open Rules je určen k podpoře vývoje aplikací postavených na business rules, prediktivní analýzu a řešení optimalizací. Specifikace: http://openrules.com

3.2.11 Rozhodovací tabulky, rozhodovací stromy Jedním z často užívaných druhů business rules jsou pravidla rozhodovací. Za tímto účelem nemusejí být business rules definována v podobě sady jednotlivých pravidel, ale mohou být vyjádřena též v podobě, která je pro business uživatele výrazně srozumitelnější. Pravidla lze implicitně vyjadřovat prostřednictvím rozhodovacích tabulek a rozhodovacích stromů. Rozhodovací tabulky jsou podporovány velkým množství nástrojů a vznikají také samostatné specifikace a metodiky pro jejich tvorbu. Z konceptů publikovaných v poslední době lze jmenovat například DecisionSpeak či TableSpeak pro tvorbu a užívání rozhodovacích tabulek. (Ross, 2013)

3.3 Porovnání specifikací pro proces výběru Pro přehlednější porovnání jednotlivých specifikací business rules v rámci procesu výběru nejvhodnější varianty pro konkrétní aplikaci jsou v rámci této podkapitoly vytvořeny srovnávací tabulky 1 - 3.

44



Tab. 1: Srovnání specifikací business rules - 1. část Zaměření

Typy pravidel všechny typy pravidel

DRL

business komunikace, popis technická komunikace, popis, odvozování technická komunikace, popis, odvozování popis, odvozování, rozšíření ontologií technická komunikace, popis, odvozování, rozšíření ontologií popis, odvozování

Jess

popis, odvozování

všechny typy pravidel

Jena Rules

popis, odvozování

deklarativní, restrikční

JRules

popis, odvozování

restrikční, akční

Open Rules

popis rozhodování, odvozování

rozhodovací

SBVR RuleML R2ML SWRL RIF

všechny typy pravidel deklarativní, restrikční všechny typy pravidel všechny typy pravidel restrikční, akční

Tab. 2: Srovnání specifikací business rules - 2. část

SBVR

textový, grafický, XML

Srozumitelnost pro management velká

RuleML

XML

střední

R2ML

XML

malá

SWRL

textový, strukturovaný, XML, RDF

velká

RIF

strukturovaný, XML

malá

DRL

IF-THEN

střední

Jess

strukturovaný, IF-THEN

malá

Jena Rules

strukturovaný, RDF

střední

JRules

IF-THEN, textový

střední

Open Rules

tabulky

velká

Formát pravidel


45

Stanislav Vojíř

Tab. 3: Srovnání specifikací business rules - 3. část

SBVR

Srozumitelnost pro implementátory střední

Software pro správu pravidel ne

RuleML

střední

ano

Java

R2ML

malá

ne

Java

SWRL

střední

ano

Java, C++

RIF

střední

ne

Java, Python

DRL

velká

ano

Java, .NET

Jess

velká

ne

Java

Jena Rules

střední

ne

Java

JRules

velká

ano

Java, .NET

Open Rules

velká

ano

XLS, Java

Technologie -

4. Proces výběru konkrétní business rule specifikace Výběr standardu pro záznam business rules je závislý na zvoleném cíli jejich využití, existující softwarové podpoře a také na uživatelích, kteří budou s business rules pracovat. V rámci této kapitoly je definován proces výběru z dostupných variant, který je v její poslední části ověřen na reálné aplikaci.

4.1 Proces výběru Pro úspěšné využívání business rule systémů je nezbytné, aby příslušný systém (a konkrétní zvolená specifikace) odpovídala požadavkům podniku, byla dostatečně srozumitelná pro uživatele a zároveň aby byla kompatibilní s jinými informačními technologiemi, které již jsou v daném podniku využívány. Pro úspěšný výběr a nasazení business rule systému je vhodné postupně projít těmito kroky: 1.

2. 3.

4.

46

definice rozsahu a cíle použití business rules  rozsah použití pravidel a jeho účel („popis“, „vyhodnocování“)  typ pravidel („deklarativní“, „restrikční“, „akční“)  specifikace terminologického slovníku specifikace skupin uživatelů, kteří budou s pravidly pracovat  charakteristika uživatelů a požadavků na „tvar“ pravidel výběr konkrétního standardu/specifikace a souvisejícího business rule enginu  množina standardů a softwarové podpory, která splňuje definované požadavky kontrola vybraného standardu business rule ve vazbě na užívané softwarové komponenty/informatické služby  preference technologií, které již jsou v podniku využívány  finalizace výběru konkrétního business rule systému SYSTÉMOVÁ INTEGRACE 3/2015


5.

vytvoření testovací sady pravidel a ověření aplikovatelnosti výběru  testovací instalace/implementace  schválení pro další vývoj a provoz

4.2 Definice rozsahu a cíle použití business rules Prvním velmi důležitým krokem při výběru standardu a posléze konkrétní specifikace pro záznam business rules je definice cíle jejich použití. Cíle vycházejí z plánovaného praktického nasazení a z toho, jakým způsobem budou vytvářená pravidla využívána. Například pokud je cílem aplikace business rules popis rozhodování v rámci modelu podnikového procesu, je nutné zvážit, zda budou pravidla použita pouze v popisném modelu, či zda budou využívána aktivně (tj. zda budou automatizovaně vyhodnocována). Lze tedy říci, že prvním výstupem tohoto výběru je volba použití za účelem „popisu“ či „vyhodnocování“. Druhým dílčím výstupem je vyhodnocení, jaké typy pravidel budou definovány. Pravidla lze dělit na „deklarativní“, „restrikční“ a „akční“. Tento výběr by měl být učiněn na základě definice použití a na základě interview s managementem daného podniku. Analytik vybírající vhodný standard by měl od managementu získat vzorek pravidel a na základě něj charakterizovat typy užívaných pravidel. V případě využití pravidel za účelem integrace jsou obvykle využívána pravidla restrikční i akční. Z akčních pravidel je možné dále vyčlenit skupinu pravidel „rozhodovacích“, která mají striktnější definici svého účelu, než obecná akční pravidla, a je možné je zaznamenávat také v podobě rozhodovacích stromů, tabulek či speciálních rozhodovacích sad pravidel. Třetím dílčím výstupem je specifikace terminologického slovníku, který má být použit pro definici business rules. Terminologický slovník je základním stavebním kamenem pravidel, která jsou nad ním definována – jeho specifikace by tedy neměla být podceněna. Pokud již je v podniku využíván nějaký terminologický či datový slovník, je obvykle vhodné, aby byl využit také k definici business rules. Příkladem varianty již existujícího slovníku je podniková ontologie. Slovníky však lze nalézt také v rámci relačních databází v podobě výčtových tabulek – např. prodávané výrobky, role oprávnění uživatelů, typy slev atd. Pokud není možné přímo využít existující komplexní terminologický slovník, je vhodné, aby byl tento vytvořen v rámci definice business rules, avšak se zaznamenáním vazeb na existující dílčí slovníky (například zmíněné tabulky).

4.3 Specifikace skupin uživatelů Druhým krokem při výběru vhodných specifikací a technologií pro práci s business rules je charakteristika uživatelů, kteří budou s pravidly dále pracovat. Těmito „uživateli“ jsou nejen lidé, ale také softwarové komponenty, které mají pravidla využívat. V případě uživatelů – pracovníků podniku je nutné již v této fázi výběru definovat, kterým skupinám pracovníků budou definice pravidel přístupné a budou je moci upravovat. U uživatelů je nutné zhodnotit jejich schopnost a ochotu učit se nové technologie a také zkušenosti s prací s možnými formami definice pravidel. V případě managementu podniku je vhodné volit standardy a specifikace, které si kladou za jeden ze svých cílů co největší uživatelskou přívětivost, ale zároveň mají dostatečné vyjadřovací schopnosti. Variantami mohou být záznam ve zjednodušené formě


47

Stanislav Vojíř

angličtiny, rozhodovací struktury (tabulky, stromy), sada rozhodovacích IF-THEN pravidel či záznam pravidel v grafické formě (například UML). V případě uživatelů – systémových integrátorů, analytiků, návrhářů systémů a programátorů mohou být pravidla zachycována nejen ve výše uvedených formách, ale také ve formách techničtějších, které se více blíží zdrojovému kódu aplikací. Tato forma často připadá programátorům a integrátorům přirozenější, než specifikace formou sad slovně vyjádřených pravidel. Pokud mají programátoři pravidla ručně upravovat, je obvykle vhodné, aby byla tato pravidla vyjádřena v textové formě (blízké zdrojovému kódu) – ne tedy ve složité struktuře XML či RDF. Neopomenutelnou skupinou „uživatelů“ jsou taktéž další softwarové komponenty a aplikace. Pokud mají být pravidla zpracovávána automatizovaně, je nutné, aby byla tato varianta použité zvoleného standardu podporována v již existující softwarové podpoře – což je řešeno ve třetím kroku výběru. V tomto případě mohou být vedle formátů pravidel podobných zdrojovému kódu aplikací vhodně využívány také formáty umožňující zachycení pravidel například v podobě dat sémantického webu. Obecně se dá říci, že překážkou není žádný strukturovaný formát.

4.4 Výběr konkrétního standardu a souvisejícího BR enginu V rámci postupného zužování výběru je v rámci třetího kroku procesu výběru nutné zvolit konkrétní možné standardy/specifikace a k nim odpovídající softwarovou podporu. Problémem tohoto kroku je hlavně rozhodnutí, zda bude využíván pouze jeden standard, či zda jich bude využíváno více. Toto tvrzení může vyznívat poněkud zvláštně, je nutné ho tedy více upřesnit. Pokud vyplývá ze specifikace podporovaných typů uživatelů to, že mají být pravidla zároveň uživatelsky přívětivá, ale také snadno zpracovatelná automatizovanými prostředky, je naráženo na problém nedostatečné podpory splnění těchto požadavků zároveň – neboť jsou částečně protichůdné. Lze tedy zvolit i variantu, ve které budou současně kombinovány dvě různé specifikace. V tomto případě je nutné definovat jejich vzájemné provázání a také omezit dostupné vyjadřovací schopnosti pravidel tak, aby byla podporována oběma specifikacemi. Vhodnou variantou může být kombinace standardu vhodného pro automatizované zpracování v kombinaci se zpřístupněním pravidel například ve formě vizualizace či zjednodušených jazykových vyjádřeních. V souvislosti s výběrem konkrétního standardu (či standardů) je vhodné zvolit také vhodnou softwarovou podporu. Jeden ze základních požadavků business rule přístupu je to, že pravidla mají být řízena. I v případě využití business rules např. jen za účelem upřesnění popisného modelu procesů je vhodné, aby byla tato pravidla ukládána do systému, který umožní jejich správu a třídění. V případě požadavků na automatizované vyhodnocování pravidel je nutné zvolit standard, ke kterému je k dispozici alespoň jeden podporovaný business rules engine. V současné době je k dispozici velké množství systému pro správu business rules a jejich vyhodnocování, které se liší poskytovanou škálou funkcionalit (zaměřením čistě na spouštění pravidel, jejich správu, či například na širší podporu systémové integrace) a také licencí. V rámci přípravy této práce byly (jakožto zástupci často užívaných systémů) podrobně porovnány systémy JBoss Drools a Microsoft BizTalk Server – Business Rules Components. Ačkoliv je první ze systémů k dispozici i s open-source licencí a druhý je k dispozici pouze na základě licence komerční, oba systémy jsou v rámci podpory business rules plně srovnatelné a do značné míry podobné. Microsoft BizTalk Server 48



je více provázán s dalšími technologiemi Microsoftu a poskytuje komplexní podporu pro systémovou integraci, ale pokud mají být využívány pouze komponenty pro business rules, je flexibilnější a jednodušší využít řešení JBoss Drools.

4.5 Kontrola vybraného standardu business rule ve vazbě na užívané softwarové komponenty/informatické služby Výsledkem předchozí fáze procesu výběru business rules enginu a standardu pro zachycení business rules by měla být množina možných variant. Jednotlivé business rules management systémy jsou postaveny nejčastěji na technologiích Java či .NET. Konkretizace výběru by měla být realizována s ohledem na technologie a informatické zdroje, které již jsou v podniku využívány – nejen za účelem jednoduššího propojení s dalšími komponentami, ale též s ohledem na úsporu finančních prostředků na správu např. dalšího databázového serveru. Systém pro správu business rules by mělo být možné integrovat s již existujícími softwarovými komponentami. Vhodným prostředkem pro tuto integraci je využití rozhraní Enterprise Service Bus. Pokud není engine pro vyhodnocování business rules součástí integračního middleware, je vhodné, aby jej bylo možné využívat prostřednictvím webových služeb. Alternativou je také volba odvozovacího enginu přímo integrovaná do aplikačního kódu vyvíjeného systému, přičemž oddělena jsou pouze samotná pravidla (respektive jejich sady).

4.6 Testovací sada pravidel, ověření aplikovatelnosti výběru Posledním, neopomenutelným krokem při výběru standardu pro záznam business rules a systému pro jejich správu je ověření platnosti výběru, který byl učiněn v předchozích krocích. Toto ověření je vhodné zrealizovat formou zkušební instalace zvoleného business rules management systému, v rámci kterého je zadána část reálných pravidel. Srozumitelnost záznamu a možnost jejich využití k plánovaným účelům by měla být ověřena zástupci všech skupin uživatelů, zároveň by měla být ověřena možnost integrace daného systému ve spolupráci s dalšími informatickými službami. V případě, že jsou v rámci této fáze výběru nalezeny jakékoliv neodstranitelné problémy, je nutné se vrátit k předcházejícím krokům výběru a zvolit jinou specifikaci. S ohledem na velké množství dostupných variant (jak v oblasti standardů, tak v oblasti softwarových nástrojů) je velmi pravděpodobné nalezení varianty vyhovující všem požadavkům.

4.7 Praktický use case – systém EasyMiner Pro ověření definovaného procesu výběru specifikace business rules je vhodné ilustrovat jeho použití na konkrétním příkladu. Tímto příkladem je výběr specifikace a softwarové podpory pro aplikaci business rules za účelem doporučování v rámci podpory business rules v data miningovém systému EasyMiner ve spolupráci s projektem LinkedTV. Projekt LinkedTV byl evropským výzkumným projektem pro tvorbu interaktivního televizního obsahu. V rámci projektu byly zkoumány možnosti doporučování alternativního a doplňkového obsahu k multimédiím, která uživatel sleduje. Pro hledání vhodného obsahu pro doporučení byla zvolena varianta dolování asociačních pravidel, která byla následně využívána pro řešení klasifikační úlohy vyhodnocení „vhodnosti“ nalezeného alternativního obsahu. Uživateli vytvářených SYSTÉMOVÁ INTEGRACE 3/2015

49

Stanislav Vojíř

business rules měly být jednak automatizované systémy (doporučovací webová služba), a zároveň také uživatelé, kteří by měli mít právo upravovat sady pravidel, na základě kterých je prováděno doporučování jim relevantního obsahu. Pravidla by měla být koncovým uživatelům předkládána pokud možno v textové formě. Zároveň je vhodné, aby také automatizovaně vyhodnocovaná pravidla byla ve formě, která je přímo srozumitelná implementátorům projektu. Pro využití v rámci doporučovací služby bylo nutné zvolit formát podporovaný odvozovacím enginem, který podporuje IF-THEN pravidla a zároveň nabízí dostatečnou míru flexibility použití. Odpovídajících business rules enginů je celá řada, do výběru byly zařazeny všechny specifikace z kapitoly 3.2 (preferovány open-source varianty). Na základě porovnání požadavků s možnostmi jednotlivých standardů bylo rozhodnuto o využití dvojice odlišných standardů. S ohledem na již využívané technologie byl pro správu pravidel zvolen systém JBoss Drools, který je stejně jako další komponenty využívané v rámci projektu implementován v jazyce Java a umožňuje využití databáze MySQL. Pro komunikaci s koncovými konzumenty obsahu byla zvolena specifikace Structured English formátu SBVR. Pro správu pravidel a pro propojení jazyků SBVR a DRL byl implementován vlastní systém pro správu pravidel. Pro podporu zápisu business rules dle specifikace SBVR byla využita možnost šablon Domain Specific Language v jazyce DRL. Systém Drools byl zvolen z důvodu velké flexibility a možnosti samostatně využít odvozovací engine.

5. Závěr Existuje celá řada standardů a specifikací pro definici business rules, z nichž není možné vybrat jednu univerzální variantu, která by byla nejlepší volbou za všech okolností. Zároveň však díky aktivnímu dlouhodobému vývoji v této oblasti lze vybrat vhodnou sadu technologií pro libovolný z možných případů praktického nasazení. V rámci tohoto textu byl vytvořen přehled často užívaných standardů pro záznam business rules, který by měl být dostatečným návodem pro výběr vhodné specifikace a softwarové podpory business rules pro praktické nasazení. Zároveň byl též popsán proces samotného výběru. Při snaze o prosazení využívání business rules v rámci podnikové informatiky by měl být věnován dostatečný prostor právě zhodnocení jednotlivých dostupných standardů, dílčích specifikací a také odpovídajících softwarových komponent pro podporu business rules. S ohledem na jejich rozmanitost lze nalézt vhodnou variantu nejen v podobě konkrétního jednoho softwarového produktu, ale také v podobě kombinace většího množství dílčích komponent a systémů. Problematika business rules je stále předmětem aktivního výzkumu, přičemž v současné době jsou hledány možnost automatizace generování pravidel z vyjádření v přirozeném jazyce či na základě dataminingových modelů – např. (Pick, a další, 2013), (Kliegr, a další, 2014). Praktické využívání business rule přístupu však stále naráží na zvyklostní odpor implementátorů informačních systémů - je obvyklejší zakódovávat obchodní logiku přímo do logiky aplikační, tj. do kódu samotných aplikací, než ji vyčleňovat do zvláštní sady pravidel. Poděkování: Tento text byl zpracován za podpory prostředků institucionální podpory na dlouhodobý koncepční rozvoj vědy a výzkumu na FIS, VŠE Praha.

50



Literatura Boyer, Jerome, 2008: SOA and BRMS. Agile IT Architecture. [Online] 12. červen 2008. http://www.agileitarchitecture.com/2008/06/soa-and-brms.html Business Rules Group, 2003. The Business Rules Manifesto. the Business Rules Group. [Online] 1. listopadu 2003. [Citace: 7. dubna 2015.] http://www.businessrulesgroup.org/brmanifesto.htm. Giurca, Adrian. 2008: R2ML. The REWERSE I1 Rule Markup Language | Working Group I1. [Online] 14. 1 2008. [Citace: 15. prosince 2011.] https://oxygen.informatik.tucottbus.de/rewerse-i1/?q=R2ML. Hay, David, Healy, Keri Anderson a Hall, J., 2000: Defining business rules-what are they really. Final Report Chappell, David A., 2004: Enterprise Service Bus. O'Reilly Media, ISBN 0-596-00675-6. Kliegr, Tomáš, a další, 2014: Learning business rules with association rule classifiers. Rules on the Web. From Theory to Applications Microsoft. 2013: Enterprise Service Bus (ESB). Microsoft BizTalk Server. [Online] [Citace: 9. září 2013.] http://www.microsoft.com/en-us/biztalk/productinformation/enterprise-service-bus.aspx OMG, 2008: Semantics of Business Vocabulary and Rules (SBVR), v1.0. [Online] 2. 1 2008. [Citace: 1. 12 2011.] http://www.omg.org/spec/SBVR/1.0/PDF OpenRules, Inc. OpenRules Business Decision Management System. [Online] [Citace: 5. září 2013.] http://openrules.com/index.htm Pick, Aleksander, a další. 2013: On approach for the implementation of data mining to business process optimisation in commercial companies, stránky 237-256 Ritchie, Andy a Backhouse, Chris, 2010: Business Rules with Enterprise Service Bus and BPM. WebSphere Integration UK Users Group Meeting Ross, Ronald G. a Lam, Gladys S.W. 2011: Building Business Solutions: Business Analysis with Business Rules, Business Rule Solutions, Houston, 304 p., ISBN 978-0-941049-10-8 Ross, Ronald G., 2013: Decision Analysis: A Primer. Ross, Ronald G., 2003: Principles of the Business Rule Approach. Addison-Wesley Professional, ISBN 978-0-201-78893-8 The JBoss Drools Team, 2015: Drools Documentation - Version 6.2.0.Final. jboss.org Community Documentation. [Online] 2015. [Citace: 1. září 2015.] http://docs.jboss.org/drools/release/6.2.0.Final/drools-docs/html_single/index.html. Voříšek, Jiří, 2008: Principy a modely řízení podnikové informatiky. Praha : Oeconomica, ISBN 978-80-245-1440-6. JEL Classification: L52, L86, M15


51

Výběr specifikace business rules pro praktické nasazení v podnikové informatice

Recommend Documents