Geschäftsregeln mit Business Rule Engines abbilden

Software > Rule Engines WissenHeute Jg. 64 5/2011 Das Thema im Überblick Nach Datenbanksystemen und Workflow Engines sind Business Rule Engines (BRE) eine vergleichsweise neue Spezialisierung von Softwarelösungen. Die BREs ermöglichen eine strikte Trennung von Business- und Programmierlogik. Sie werden in Unternehmen hauptsächlich zur Entscheidungsfindung auf Grundlagen von Attributen und Ereignissen eingesetzt und können über Schnittstellen mit anderen Programmen kommunizieren. Die BREs unterstützen zahlreiche Formate zur Regelerstellung. Weit verbreitete BREs sind z.b. IBM ILog und JBoss Drools. Geschäftsregeln mit Business Rule Engines abbilden Häufig gibt es für Bestellungen bei einem Onlineversand Sonderaktionen mit Rabatten, zusätzlichen Gratis-Produkten oder dem kostenlosen Warenversand ab einem gewissen Bestellwert. Damit nicht bei jeder Sonderaktion Geschäftsprozesse oder sogar der Programmcode angepasst werden müssen, kommen für sich ändernde Geschäftsregeln in Unternehmen immer häufiger Rule Engines zum Einsatz. Diese ermitteln anhand von Fakten und Regeln (Rules) z.b. den jeweiligen Rechnungsbetrag. In diesem Beitrag wird unter anderem anhand von Beispielregelwerken eine Rechnungszuordnung erklärt, welche Eingaben die Rule Engine dazu benötigt und welche Ergebnisse sie liefert. Grundlagen der Rule Engine Der Autor einem einzelnen Programmierer entwickelt, umgesetzt oder administriert wurde, sind Alexander Groenewold schrieb seine Bachelor Arbeit zum Thema Rule Engine bei der SAPERION AG und arbeitet dort mittlerweile als Entwickler. Dr. Martin Bartonitz ist als Produktmanager bei der SAPERION AG verantwortlich für die Themen Workflow und Records Management und betreute die Bachelorarbeit von Herrn Groenewold. 42 Eine Rule Engine auch als BRE bezeich- lange vorbei. Durch die stets umfangreicher net ist ein eigenständiges, in sich ge- werdenden Anwendungen entsteht die Not- schlossenes Programm (Software), das zum wendigkeit, einzelne Aufgaben auszulagern Auswerten von Geschäftsregeln (Business und spezialisierte Standardsoftware zu ent- Rules) dient. Die Geschäftsregeln beschrei- wickeln. Eines der frühesten Beispiele hier- ben interne Abläufe, Richtlinien und Bedin- für ist die Entwicklung von Datenbanken. gungen eines Unternehmens und können Diese bieten eine strikte Trennung von Pro- für alle Geschäftsbereiche aufgestellt wer- grammierlogik und Datenspeicherung und den. Eine Rule Engine ermöglicht die zent- ermöglichen es, für beide Aufgaben opti- rale Verwaltung und Auswertung dieser Ge- mierte Lösungen zu entwickeln, ohne dass schäftsregeln. die jeweiligen Anforderungen miteinander kollidieren. Einsatzbereiche von Rule Engines In den letzen Jahren ist Software immer Ein aktuelleres Beispiel für diese Ausglie- umfangreicher und komplexer geworden. Die derung von speziellen Aufgaben aus der all- Zeiten, in denen ein ganzes Programm von gemeinen Programmierlogik ist die Entwick-

WissenHeute Jg. 64 5/2011 lung von Workflow Engines, die auf das Ausführen von Abläufen und Prozessen spezialisiert sind. Bild 1 Einflussfaktoren auf Änderungs- und Entwicklungszyklen Neue Regeln, Anpassungen, Erweiterungen Geschäftsregeln ändern sich in der Regel häufiger als Arbeitsabläufe oder Anwendungsoberflächen, woraus sich unterschiedliche Entwicklungszyklen ergeben. In Bild 1 sind diese Zusammenhänge und die Einflussfaktoren als Übersicht dargestellt. Änderungszyklen der Richtlinien, Tarife, Regeln Schnittstelle Was Oft ist es schwierig, umständlich und auch kostspielig, eine individuelle Softwarelösung ständig an die sich in kurzen Abständen ändernden Geschäftsregeln des Unternehmens anzupassen. Hierfür bietet die Rule Engine ein Lösungskonzept an. Durch die Trennung der Geschäftslogik (z.b. Abläufe, Grenzwerte und interne Abhängigkeiten) von der Programmierlogik (z.b. Benutzerverwaltung, Datenverarbeitung und Steuerung von Ein- und Ausgaben) lassen sich die Regeln ändern oder ergänzen, ohne das Programm selbst zu verändern. In vielen Fällen können die Änderungen im Geschäftsprozess durch die Verantwortlichen selbst durchgeführt werden, ohne einen Programmierer aus der eigenen IT-Abteilung oder sogar den Hersteller einer Standardsoftware beauftragen zu müssen. Die Beziehung zwischen Standardsoftware und Rule Engine sowie die Ausgliederung der speziellen Administration ist in Bild 2 dargestellt. Nutzen der Rule Engine Den größten Nutzen stellt die Rule Engine als zentrale Sammlung des Geschäftswissens dar. In diesem Fall können die in der Rule Engine hinterlegten Regeln von den unterschiedlichen Anwendungen des Unternehmens genutzt werden. Ein weiterer Vorteil ist dabei, dass die einheitliche Kommunikation unter den Abteilungen gefördert wird, weil alle Definitionen von Begriffen und Prozessen für die Rule Engine unternehmensweit eindeutig sein müssen. In den meisten Unternehmen gibt es je nach Abteilung häufig mehrere Definitionen von Standardbegriffen wie z.b. Kunde oder Auftrag. Dies kann zu Missverständnissen führen. Bild 2 Benutzer Funktionale Erweiterung Des Weiteren können mit einer Rule Engine wiederkehrende Prozesse und Berechnungen vereinfacht und automatisiert werden, was die Fehlerhäufigkeit senkt und Zeit einspart. Grundlegende Funktionsweise Bei dem grundlegenden Ablauf erhält die Rule Engine über eine Schnittstelle zunächst die sogenannten Fakten, auf deren Grundlage eine Entscheidung getroffen wird. Die Fakten werden gegen das hinterlegte Regelwerk geprüft. Die daraus resultierenden Ergebnisse und Anweisungen werden abschließend über die Schnittstelle wieder zurückgegeben. Begriffe Nachfolgend sind die wichtigsten Begriffe im Zusammenhang mit einer Rule Engine aufgezählt: Schnittstelle (Interface) Terms & Facts (Begriffe & Fakten) Regel Regelwerk Rule Flow (Regelfluss) Entwicklungszyklen der Anwendung Servicepack Wie Zusammenhang und Administration von Standardsoftware und BRE Standardsoftware BRE Business Rule Engine Anwendungs-Administration Schnittstelle Regel-Administration BRE Allgemein beschreibt eine Schnittstelle (Interface) die Grenze/Verbindung zweier unterschiedlicher Systeme. Sie enthält die Definition (Methoden) der erwarteten und angebotenen Informationen. Je nach Art der eingesetzten Rule Engine und dem verwendeten Programm gibt es vordefinierte oder selbst definierbare Schnittstellen. Dies wird häufig in einer Programmiersprache umgesetzt, die für beide Systeme verwendet wurde. Wird die Programmiersprache Java eingesetzt, bietet sich die Standardschnittstelle JSR 94 an, welche von nahezu allen Javabasierten Rule Engines unterstützt wird. Dies ermöglicht den Anschluss verschiedener Rule Engines, ohne dass der Programmcode angepasst werden muss. Weil die Schnittstelle jedoch für viele verschiedene Rule Engines einsetzbar sein muss, ist die Verwendung ihrer speziellen Funktionen, die über den allgemeinen Standard hinausgehen, meist nicht möglich. Wenn der gesamte Funktionsumfang einer einzelnen Rule Engine genutzt werden soll, ist die Verwen- 43

Software > Rule Engines WissenHeute Jg. 64 5/2011 Kasten 1 Beispiel Terms & Facts Bild 3 schematische Darstellung der SimpleDemoApp Kostenstelle Kostenstellenname Kostenstellennummer Mitarbeiterlimit Leiterlimit Rechnung Betreff Rechnungsnummer Kostenstellennummer Betrag SimpleDemoApp Setup Fakten Benutzer <<Abstract>> RuleEngine llogconnector DroolsConnector Regelwerke ILog Drools Regelwerk Benutzer Benutzername Benutzerrolle zugeordnete Kostenstellen Rechnung Kostenstelle dung des vom Hersteller der Rule Engine definierten Interface zu bevorzugen. Die zur Ergebnisfindung benötigten Informationen werden als Terms & Facts bezeichnet. Die Terms (Begriffe) stellen hierbei die einzelnen Objekte des Geschäftsalltags dar. Beispiele dafür sind: Kunde, Rechnung, Bestellung, Dokument, Adressen. Die Facts Bild 4 Programmablauf der SimpleDemoApp Fakten erstellen Rule Engine instanziieren DroolsConnector Regelwerk laden ILogConnector (Fakten) beschreiben hingegen die Beziehung der Terms untereinander. Beispiele dafür sind die Beziehung zwischen Kunde und Adresse oder zwischen Bestellung und Rechnung. Eine Regel stellt eine Bedingung, Abhängigkeit oder Beschränkung (Constraint) dar. Sie besteht immer aus zwei Teilen: Einer Aussage, die entweder wahr oder falsch sein kann (when) und einer Anweisung, die auszuführen ist, wenn die Aussage zutrifft (then). Als Regelwerk wird die Summe von Regeln bezeichnet, die eine inhaltliche Einheit bilden und/oder zur Lösung eines speziellen Problems benötigt werden. Einige Rule Engines bieten die Möglichkeit, einen Rule Flow zu erstellen. Dieser Rule Flow legt fest, welche Regeln und Regelwerke in welcher Reihenfolge ausgeführt werden sollen. In diesem Beispiel gibt es in einem Unternehmen die drei Kostenstellen Marketing, Verwaltung und Gebäude. Des Weiteren gibt es Benutzer, die unterschiedliche Rollen innerhalb der Unternehmenshierarchie als Mitarbeiter (Employee), Leiter (Supervisor) oder Direktor (Director) einnehmen. Jeder Benutzer ist einer oder mehreren Kostenstellen zugeordnet, für die er Rechnungen freigeben darf. Jede Kostenstelle enthält einen festgelegten Betrag als Grenzwert, ab dem ein Benutzer der direkt übergeordneten Rolle die Rechnung freigeben muss. Eine Rechnung enthält eine Rechnungssumme und ist einer Kostenstelle zugeordnet. Die Terms & Facts für dieses Beispiel sind im Kasten 1 aufgelistet: Um die Regelwerke auszuführen, wird ein in Java geschriebenes Demo-Programm (SimpleDemoApp) benutzt. Eine schematische Übersicht zu dieser SimpleDemoApp ist in Bild 3 sowie der Programmablaufplan dazu in Bild 4 dargestellt. Fakten übergeben Regeln anwenden Ergebnisse zurückliefern Ergebnisse verarbeiten Anwendungsbeispiel Rechnungseingang Im folgenden Beispiel sind die verschiedenen Regelformate unter Verwendung der zuvor genannten Begriffe erklärt. Dazu werden die Regelformate der beiden meist verbreiteten Rule Engines JBoss Drools (Open Source Software Rule Engine) und IBM ILog verwendet. Eingabe der Fakten In der main Methode des Demo-Programms wird ein Setup Objekt erzeugt. Dieses befüllt zunächst eine Liste mit Fakten. Der Programmcode zur Befüllung der Fakten ist in Kasten 2, Punkt 1 dargestellt. Instanziieren der Rule Engine Der Begriff Instanziieren bedeutet, dass ein konkretes Objekt einer Klasse mit kon- 44

WissenHeute Jg. 64 5/2011 kreten Eigenschaften erzeugt wird. Anschließend wird mit der Anweisung initiaterule- Engine() eine von Rule Engines abgeleitete Klasse (DroolsConnector oder Ilog- Connector) instanziiert. Beide verarbeiten die Ergebnisse auf dieselbe Weise, unterscheiden sich jedoch bei dem Aufruf der Rule Engine. Um welche Art von Rule Engine und Regelwerk es sich handelt, wird mithilfe der von der SimpleDemoApp an Setup übergebenen Parameter gesteuert. Kasten 2 Programmcode Fakten-Befüllung, Rule Engine Aufruf und SimpleDemoApp Punkt 1: public List<Object> getfacts(){ List<Object> facts=new ArrayList<Object>(); facts.add(new CostCentre("Marketing", 23,(new int[]{500,2000))); facts.add(new CostCentre("Accounting", 42,(new int[]{5000,10000))); facts.add(new CostCentre("Facility", 13,(new int[]{500,3000))); facts.add(new User("Mrs. Maier", facts.add(new User("Miss Schulze", facts.add(new User("Mr. Anderson", Role.EMPLOYEE, (new int[]{23))); Role.EMPLOYEE, (new int[]{42))); Role.EMPLOYEE, (new intt[]{42,13))); facts.add(new User("Mr. Smith", Role.SUPERVISOR, (new int[]{23))); facts.add(new User("Mr. Jones", Role.SUPERVISOR, (new int[]{42,13))); facts.add(new User("Mr. Blank", Role.DIRECTOR, (new int[]{23,42,13))); Zuletzt wird die Methode (Prozedur) run- RuleEngine() aufgerufen, welche die Fakten an die Rule Engine übergibt, eine Abfrage auslöst und anschließend die Ergebnisse verarbeitet. Der Programmcode dazu ist in Kasten 2, Punkt 2 dargestellt. facts.add(new Invoice("Poster", 22057, 23,153.34)); facts.add(new Invoice("Elevator Repairs", 17348, 13, 900)); facts.add(new Invoice("New Software", 27315, 42, 670.78)); facts.add(new Invoice("Photo Shooting", 10623, 23, 1600.50)); facts.add(new Invoice("Training for new Software", 27316, 42, 7800)); facts.add(new Invoice("Energy Bill", 13560, 13,460)); facts.add(new Invoice("Convention Booth", 22059, 23,5000)); return facts; Rule Engine Connectoren Die von der Rule Engine abgeleiteten Klassen DroolsConnector und IlogConnector steuern den Verbindungsaufbau und stellen die Schnittstelle zu ihrer jeweiligen Rule Engine dar. Obwohl die Aufrufe innerhalb der Connectoren im Einzelnen unterschiedlich sind, passiert dennoch in beiden wenn auch stark vereinfacht prinzipiell das Gleiche: zuerst wird das Regelwerk geladen und ein Session Objekt erzeugt. Anschließend werden die Fakten an die Session übergeben und mit einem weiteren Befehl werden die Regeln auf die Fakten angewendet. Die Objekte, die Fakten enthalten, können direkt innerhalb der Rule Engine verändert werden, was unter anderem das Auslösen weiterer Regeln bewirken kann. Der spätere Zugriff auf Objekte innerhalb der Session kann je nach Rule Engine und Verbindungsart auf verschiedenen Wegen (z.b. mit Handles 1 oder globalen Variablen) vorgenommen werden. In der SimpleDemoApp wird eine Liste mit Ergebnissen (ResultSets) zurückgegeben. Ein ResultSet enthält eine Rechnung, die dazugehörige Kostenstelle sowie den zur Unterschrift berechtigten Benutzer/Mitarbeiter. Punkt 2: public void runruleengine() { re.processresults(re.queryruleengine(getfacts())); Punkt 3: The invoice for "Convention Booth" may be approved by Mr. Blank, DIRECTOR of the Marketing cost centre. The invoice for "Energy Bill" may be approved by Mr. Anderson, EMPLOYEE of the Facility cost centre. The invoice for "Training for new Software" may be approved by Mr. Jones, SUPERVISOR of the Accounting cost centre. The invoice for "Photo Shooting" may be approved by Mr. Smith, SUPERVISOR of the Marketing cost centre. The invoice for "New Software" may be approved by Mr. Anderson, EMPLOYEE of the Accounting cost centre. The invoice for "New Software" may be approved by Miss Schulze, EMPLOYEE of the Accounting cost centre. The invoice for "Elevator Repairs" may be approved by Mr. Jones, SUPERVISOR of the Facility cost centre. The invoice for "Poster" may be approved by Mrs. Maier, EMPLOYEE of the Marketing cost centre. Mithilfe der Methode processresults() wird diese Kombination als Ergebnis auf dem Bildschirm ausgegeben. Zusätzlich können die Ergebnisse aber auch von Programmen wie z.b. einem CRMS oder ECMS weiterverwendet werden, die sie an den jeweiligen Benutzer weiterleiten. Ein Beispiel für die Bildschirmausgabe der SimpleDemoApp ist im Kasten 2, Punkt 3 dargestellt. Weil es für das Accounting zwei Benutzer mit der Rolle EMPLOYEE gibt, kann die Rechnung für New Software von beiden Benutzern freigegeben werden. Entsprechend der Unternehmenspolitik zur Lastverteilung könnte hier entweder ein weiteres Regelwerk oder die darüberliegende Software entscheiden, wie zu verfahren ist. Regelwerke Die meisten Rule Engines unterstützen mehrere Regelformate. Weder Drools noch ILog sind auf die hier beschriebenen Formate begrenzt. Alle Regelwerke haben das Ziel, einer Rechnung die entsprechende Kostenstelle und einen Mitarbeiter zuzuordnen, der aufgrund seiner Position (Rolle) die Höhe dieses Rechnungsbetrags für die zugeordnete Kostenstelle freigeben darf. Dabei ist zu beachten, dass immer einer der rangniedrigsten befugten Mitarbeiter ausgewählt werden muss. DRL Der grundlegende Aufbau einer Regel in DRL ist in Kasten 3, Punkt 1 dargestellt. Mit dem Befehl rule wird der Regelname festgelegt und dies ist gleichzeitig auch der Anfang der Regel. Mit der Anweisung dialect wird die verwendete Programmiersprache 1 Handles: eindeutiger Objektschlüssel (Identifikator), der von einem anderen System verwaltet wird (abstrakte Referenz). 45

Software > Rule Engines WissenHeute Jg. 64 5/2011 Kasten 3 Punkt 1 rule "Regelname" dialect "java" oder "mvel" when Bedingung then Anweisung end Ende der Regel Punkt 2 package com.saperion.drools.rules import java.util.arraylist; import com.saperion.facts.*; global ArrayList returnvalues; Programmcode DRL und SimpleDemoApp rule "Employee" dialect "java" when $i:invoice($invoicecostcentre : costcentreid, $amount : amount); $c:costcentre( $costcentreid : ID,ID == $invoicecostcentre, userlimit >= $amount); $u:user(costcentre contains $costcentreid, roleasstring == "EMPLOYEE" ); then ResultSet resultset=new ResultSet(); resultset.setuser($u); resultset.setinvoice($i); resultset.setcostcentre($c); returnvalues.add(resultset); end rule "Supervisor" dialect "java" when $i:invoice($invoicecostcentre : costcentreid, $amount : amount); $c:costcentre( $costcentreid : ID,ID == $invoicecostcentre, supervisorlimit >= $amount, userlimit < amount); $u:user(costcentre contains $costcentreid, roleasstring == "SUPERVISOR" ); then ResultSet resultset=new ResultSet(); resultset.setuser($u); resultset.setinvoice($i); resultset.setcostcentre($c); returnvalues.add(resultset); end rule "Director" dialect "java" when $i:invoice($invoicecostcentre : costcentreid, $amount : amount); $c:costcentre( $costcentreid : ID,ID == $invoicecostcentre, supervisorlimit < $amount); $u:user(costcentre contains $costcentreid, roleasstring == "DIRECTOR" ); then ResultSet resultset=new ResultSet(); resultset.setuser($u); resultset.setinvoice($i); resultset.setcostcentre($c); returnvalues.add(resultset); end festgelegt, was Einfluss auf die Semantik der Programmcodeteile (Anweisung, Vergleiche) der jeweiligen Auswertung hat. Die Regeln für die SimpleDemoApp sind in Kasten 3, unter Punkt 2 aufgeführt. Die Bedingungen der Regeln sind in der Programmiersprache MVEL, einer Expression Language für Java, die Anweisungen bei erfüllter Bedingung direkt in Java verfasst. Nachfolgend ist der Programmcode der Regel Director beschrieben: Bedingung (when) und Zwischenschritt: Gibt es eine Rechnung? Zwischenschritt: Speichere die Rechnung in der Variablen $i, die angegebene Kostenstellennummer in der Variablen $invoicecostcentre und den Rechnungsbetrag in der Variablen $amount. Gibt es eine Kostenstelle, bei der die Nummer der Kostenstelle der in der Rechnung angegebenen Kostenstellennummer entspricht und der Rechnungsbetrag ($amount) größer als der maximale Freigabebetrag für den Abteilungsleiter dieser Kostenstelle ist? Zwischenschritt: Speichere Kostenstelle ($c) und Kostenstellen-ID ($costcentreid). Gibt es einen Benutzer, dessen zugeordnete Kostenstellen die zuvor gefundene Kostenstelle ($costcentreid) enthält und der die Rolle Director hat? Zwischenschritt: Speichere den Benutzer ($u). Anweisung (then): Dann erzeuge ein neues Ergebnisobjekt, speichere Rechnung, Kostenstelle und Benutzer im Ergebnisobjekt und füge das Ergebnisobjekt der globalen Liste von Ergebnissen hinzu. Im Anschluss an den Aufruf der Regeln wird die Ergebnisliste vom Connector aus der Session ausgelesen und an die Methode processresults() übergeben. IRL/ILog Intellirule Der Programmiercode der IRL sieht dem der DRL sehr ähnlich. Bei ILog werden die Regeln jedoch nicht direkt in IRL verfasst, sondern mithilfe von Intellirule. Die in Intellirule erstellten Regeln werden anschließend automatisch in die IRL übersetzt. Dieses Mapping muss vor dem Erstellen der ersten Regel in ILOG teilweise manuell, aber teilsweise auch mit einem Eingabetool (Wizard) eingerichtet werden. Drools ermöglicht es hingegen, sofort mit dem Erstellen der Regeln zu beginnen. Intellirule bietet dafür im Gegensatz zu Drools eine einfache Autovervollständigung und ist der natürlichen Sprache sehr nahe, was das Definieren der Regeln besonders für Nicht-Programmierer stark vereinfacht. Im Vergleich zu Drools ist die Regel Director im Kasten 4, Punkt 2 mit Intellirule dargestellt. 46

WissenHeute Jg. 64 5/2011 Anders als bei Drools wird das Zwischenspeichern der Variablen bei Intellirule getrennt von der Prüfung auf erfüllte Bedingungen vorgenommen. Das Regelwerk sucht sich eine beliebige Kostenstelle, Rechnung und Benutzer und prüft anschließend, ob diese der Bedingung entsprechend zusammenpassen. Dies geschieht für alle möglichen Kombinationen. Ist die Bedingung erfüllt, wird die Kombination als RuleSet in der Ergebnisliste (result list) gespeichert, welche nach der Ausführung aller Regeln zur Auswertung ( processresults() ) vom IlogConnector an die Rule Engine-Klasse zurückgegeben wird. Entscheidungstabelle Eine weitere Möglichkeit der Regeldarstellung ist die Entscheidungstabelle. Ein Beispiel dazu ist mit der Zuordnung von Kostenstellennummer, Rechnungsbetrag und Zuständigkeit in Tabelle 1 aufgelistet. Die Entscheidungstabelle ist besonders bei den Führungskräften beliebt, weil Tabellen für sie ein bekanntes Medium sind und sich Bedingungen und Abhängigkeiten sehr einfach daraus ablesen lassen. In der Tabelle 1 beschreiben die ersten drei Spalten den Bedingungsteil einer Regel. Die letzten drei Spalten enthalten die Anweisung bei erfüllten Bedingungen. Die Tabelle ist eine andere Darstellungsvariante, bei der die zugrundeliegende Logik nahezu identisch mit der Intellirule-Variante ist. Die Anweisungen, die sich hinter der Entscheidungstabelle verbergen, sind als Übersicht in Tabelle 2 dargestellt. Weitere Anwendungsbeispiele Der Einsatz einer BRE ist dann besonders effektiv, wenn es um die Entscheidungsfindung auf Grundlage von logischen und/oder numerischen Eigenschaften geht. Nachfolgend sind einige Anwendungsbeispiele für den Einsatz einer Rule Engine aufgezählt. Berechnen von Rabatten/Prämien (speziell) Berechnen von Werten auf Grundlage von Attributen (allgemein) Posteingang Zugriffskontrolle Dokumentenklassifizierung Zuweisung von Ansprechpartnern und Arbeitslastausgleich Berechnen von Rabatten/Prämien Basierend auf Attributen wie Menge, Warentyp, Kundenstatus und Verfügbarkeit kann in Bezug auf verschiedene Sonderangebote oder allgemeine Verkaufsrichtlinien des jeweiligen Anbieters der Gesamtpreis einer Bestellung ermittelt werden. Berechnen von Werten auf Grundlage von Attributen Jeder Fall, der sich durch Berechnung oder auf Basis von Eigenschaften logisch herleiten lässt, kann mit einer Rule Engine bearbeitet werden. Konkrete Anwendungsbeispiele hierfür sind Steuern, Limits, Zinsen, Abgaben, Versandkosten oder Gebühren. Posteingang Größere Unternehmen erhalten täglich eine beträchtliche Menge an elektronischer Post. Durch das Auslesen von z.b. Absen- Kasten 4 Programmcode IRL und Intellirule Punkt 1 package simpleapprules { rule Director { property status = new ; when { the cost_centre: com.saperion.facts.costcentre(); the user: com.saperion.facts.user(); result_list: com.saperion.facts.resultlist(); the invoice: com.saperion.facts.invoice(); evaluate ((((the invoice.costcentreid == the cost_centre.id && (double) the cost_centre.supervisorlimit < the invoice.amount) && the cost_centre.id in the user.costcentre) && (the user.role.equals(com.saperion.facts.role.director)))); then { result_list.addresult(the user, the invoice, the cost_centre); Punkt 2 defi nitions if set the cost centre to a cost centre ; set the user to a user ; set result list to a result list ; set the invoice to an invoice ; Verwendete Abkürzungen BRE CRMS DRL ECMS Business Rule Engine Customer Relations Management System Drools Rule Language Enterprise Content Management System ID Identifier IRL ILog Rule Language JSR 94 Java Specification Request 94 MVEL MVFLEX Expression Language der oder Inhalt kann eine automatische Vorsortierung vorgenommen werden. (Beispiel: Rechnungseingang) Zugriffskontrolle Die Zugriffskontrolle auf interne und externe Ressourcen gestaltet sich teilweise komplex und unterliegt gelegentlichen Änderungen wie z.b. bei einer Vertreterregelung. Basierend auf Ort, Abteilung oder Rolle innerhalb der Unternehmenshierarchie ist eine Rule Engine in der Lage, Zugriff auf einen Bereich oder ein bestimmtes Dokument zu gewähren und/oder zu verweigern. the cost centre ID of the invoice equals the ID of the cost centre and the supervisor limit of the cost centre is less than the amount of the invoice and the cost centres of the user contain the ID of the cost centre and the role of the user is DIRECTOR then add the user, the invoice and the cost centre to result list ; 47

Software > Rule Engines WissenHeute Jg. 64 5/2011 Dokumentenklassifi zierung und -sicherung Unter dem Begriff Retention werden gesetzliche und unternehmenspolitische Richtlinien zum Aufbewahrungszeitraum von verschiedenen Dokumententypen beschrieben. Auch die Einhaltung dieser Vorgaben kann mit dem Einsatz einer Rule Engine abgesichert werden. Tabelle 1 Entscheidungstabelle Bedingung Anweisung Cost Center Invoice Amount Role Add results to the result list ID Minimum Maximum Required User Invoice Cost Centre 23 0 500 Employee > 500 2 000 Supervisor > 2 000 Director 42 0 5 000 Employee > 5 000 10 000 Supervisor >10 000 Director 13 0 500 Employee > 500 3 000 Supervisor > 3 000 Director Tabelle 2 Anweisungen für Entscheidungstabelle Aufgabe/Bereich Interrule Eingabe Vorbedingung definitions set the cost centre to a cost centre ; set the user to a user ; set result list to a result list ; set the invoice to an invoice ; Cost Centre ID the ID of the cost centre equals the cost centre ID of the invoice and the cost centre ID of the invoice equals <a number> Invoice Amount the amount of the invoice is at least <min> and less than <max> Role Required the cost centres of the user contain the ID of the cost centre and the role as string of the user is <a string> Add results to add <a user>, <an invoice> and <a cost centre> to the result list result list Zuweisung von Ansprechpartnern und Arbeitslastausgleich Einem neuen Kunden weist die Rule Engine automatisch einen dauerhaft zuständigen Ansprechpartner aus dem Unternehmen zu. Diese Entscheidung wird beispielsweise auf Grundlage der aktuellen Auslastung, Erfahrung und Fachkenntnis des jeweiligen Mitarbeiters getroffen. Eine mögliche Erweiterung dieser Funktion wäre die automatische Zuweisung eines neuen Mitarbeiters, wenn der zugewiesene Mitarbeiter nur kurz oder auch dauerhaft nicht mehr verfügbar ist. Zusammenfassung Die Vorteile im Einsatz einer Rule Engine sind vielfältig. Sie hilft bei der Vereinfachung und Automatisierung von Geschäftsprozessen und kann gleichzeitig auch als zentrale Sammelstelle des Geschäftswissens genutzt werden. Weil die Einrichtung der Rule Engine und die Definition der Regeln zur Abbildung der Geschäftsprozesse mit einigem Aufwand verbunden sind, wird der Einsatz erst dann effektiv, wenn die Rule Engine für die Abbildung einer entsprechend großen Zahl von Geschäftsprozessen genutzt wird. Eine mehrfache Nutzung steigert dabei zusätzlich die Effektivität. Weiterhin muss bei der Implementierung einer Rule Engine beachtet werden, dass auch entsprechend ausgebildetes Personal für die Administration vorhanden sein muss. Ist die Rule Engine innerhalb eines Unternehmens jedoch erst einmal in die Geschäftsprozesse integriert und wird auch dementsprechend angewendet, so kann sie vergleichsweise leicht auch auf andere Geschäftsbereiche abteilungsübergreifend übertragen und ihre Nutzung ausgedehnt und intensiviert werden. Internetadressen und Literaturhinweis (Gl) www.saperionblog.com/lang/de/saperion-meets-ruleengine/ (entnommen 07.07.2011) www.jboss.org/drools (entnommen 07.07.2011) www.ilog.com/products/jrules (entnommen 07.07.2011) Ronald G. Ross: Business Rule Concepts ; Verlag: Business Rule Solutions, LLC 48