Flexibilität im Prozess mit Oracle Business Rules 11g Michael Stapf ORACLE Deutschland GmbH Frankfurt Schlüsselworte: Geschäftsregeln, Business Rules, Rules Engine, BPEL Process Manager, SOA Suite 11g, Entscheidungsdienst, Service-orientierte Architektur, SOA Einleitung Geschäftsregeln außerhalb der Implementierung erhöhen die Flexibilität und ermöglichen den Aufbau und die Einbindung eines Wissens-Repositories als einen wiederverwendbaren Service in einen Prozessablauf. In der SOA Suite 11g ist eine dafür geeignete Regelmaschine enthalten. Der Vortrag stellt diese Rules Engine vor und zeigt Nutzenpotenziale und Einsatzgebiete auf. Neue Funktionen in 11g, wie der Regelentwurf im JDeveloper, Decision Tables, das Testen der Regeln und die Einbindung als SCA Komponente innerhalb einer Composite Application, werden behandelt und demonstriert. Entscheidungsdienst Heutzutage sind nach wie vor viele geschäftliche Regeln eines Unternehmens im Programmcode untergebracht und damit mehr oder weniger statisch und nur schwer von anderen Systemen oder Prozessen, neben dem ursächlichen Zweck des Programms für das die Regeln implementiert wurden, nutzbar. Die Wiederverwendung von Services spielt bei einem service-orientierten Ansatz eine zentrale Rolle. Ein Service, der das Wissen im Unternehmen wiederverwendbar macht, erhöht diesen Mehrwert gewaltig und kann helfen die Produktivität im Unternehmen dramatisch zu verbessern. Oracle stellt in der Fusion Middleware seit Jahren eine Rules Engine genannt Oracle Business Rules zur Verfügung, die in Kombination mit anderen Komponenten etwa die der SOA Suite 11g genutzt werden kann. Ein Anwendungsbeispiel ist die Nutzung der Rules Engine als Entscheidungsdienst im Ablauf eines Prozesses der mit BPEL (Business Process Execution Language) beschrieben ist. Damit erhöht sich die Flexibilität im Prozess, ohne das sein grundsätzlicher Aufbau geändert werden müsste. Dies ist vor allem sinnvoll, bei Geschäftsregeln, die sich sehr häufig ändern, wobei dies je nach Kontext etwa täglich oder wöchentlich bedeuten kann. Durch den Einsatz einer expliziten Rules Engine sind die Regeln direkt zugreif- sprich änderbar ohne, dass der komplette Software-Lebenszyklus durchlaufen werden müsste. Der könnte unter Umständen einen viel größeren Zeitraum d.h. unter Umständen mehrere Monate in Anspruch nehmen, was nicht im Einklang mit dem Geschäft, und dem berühmten Time to Market steht.
Informationen fließen an einer bestimmten Stelle im Prozessablauf in den Entscheidungsdienst hinein, werden dort ausgewertet eine Entscheidung wird getroffen und das Ergebnis in Form von Daten fließt wieder zurück in den Prozess, der damit weiterarbeiten kann. Die Information wird in der SOA Suite als XML Dokument definiert und durch ein XML Schema beschrieben. Regeln Eine Regel besteht im Wesentlichen aus zwei Teilen. Zum einen einer Bedingung Wenn X zum anderen einer Aktion Dann Y, die im Prinzip ausgeführt wird, wenn die Bedingung erfüllt ist. In der Geschäftswelt könnten dies Beispiele für solche Regeln sein: Wenn der Kunde in den nächsten zwei Wochen seine Bestellung für ein bestimmtes Produkt über das Internet ausführt, dann bekommt er 20% Rabatt. Oder Wenn ein Fluggast mehr als 100000 Meilen geflogen ist, dann ändere seinen Status auf GOLD. Als Regel im Rules Designer sieht das folgendermaßen aus: Abb. 1: Darstellung einer Regel im Rules Designer Oracle Business Rules in SOA Suite 11g Oracle Business Rules enthält verschiedene Komponenten für den Ablauf, die Erfassung und Pflege von Regeln. Um Regeln skalierbar ausführen bzw. auswerten zu können, gibt es verschiedene Algorithmen. Die Rules Engine von Oracle verwendet den RETE-Algorithmus für den Test, welche Regeln gültig sind und ist in Java implementiert. Es liegt ein deklarativer Ansatz zugrunde, der mit Regeln beschreibt was passieren soll, wenn die Bedingungen der Regel erfüllt sind. Die Abarbeitung wird effizient von der Rules Engine erledigt. Das Erschließen von neuem Wissen wird durch datengetriebene Vorwärtsverkettung erreicht. Es können mehrere Regeln aktiv werden, da als Ergebnis von vorherigen Regeln Bedingungen nachfolgender Regeln erfüllt werden können. Als Konfliktlösungsstrategien bei gleichzeitig ausgewählten Regeln kommen etwa Prioritäten, oder deren Aktualität zum Einsatz. Man kann sich das in etwa wie ein Filter für Regeln vorstellen. Datenobjekte, die dem Arbeitsspeicher (Working Memory) von Business Rules zugewiesen wurden, werden Fakten (Facts) genannt. Fakten können auf XML Daten, Java Objekten oder
ADF Business Component Views basieren. Sie werden im Rahmen der Zuweisung (Assertion) in ein Dictionary eingetragen. Das Dictionary ist ein XML Dokument, welches die Regeln und die Daten für einen bestimmten Kontext ablegt. Dictionaries lassen sich mit anderen Dictionaries verlinken um etwa ein gemeinsames Datenmodell zu teilen. Abb. 2: Oracle Business Rules - Komponenten und Abläufe Der Ablauf sieht folgendermaßen aus. Innerhalb einer sogenannten Rule Session wird aufgrund der Faktenlage d.h. den Daten die der Rules Engine im Arbeitsspeicher zur Verfügung stehen getestet, welche Regelbedingungen der Regelmenge erfüllt sind. Diese Regeln werden der Agenda (einer Liste) zugeordnet (sie werden aktiviert) und daraufhin wird mit Konfliktauflösungsstrategien entschieden, welche Regel und damit welche Regelaktion ausgeführt wird (die Regel feuert). Aktionsmöglichkeiten können das Erzeugen von neuen Fakten, das Ändern von Fakten oder das Löschen von Fakten sein. Auch Java-Methoden können als Aktion ausgeführt werden. Nach der Regelausführung fängt der sogenannte Inferenzzyklus von Neuem an. Der Regelentwurf wird mit dem Rules Designer innerhalb des JDeveloper 11g vorgenommen. Die grundsätzliche Vorgehensweise ist die, dass zunächst die Fakten importiert oder erzeugt werden, beispielsweise auf Basis von XML Schemas. Anschließend besteht die Möglichkeit direkt eine Regel oder falls es sich um viele ähnliche Regeln handelt eine Entscheidungstabelle zu wählen um seine Regeln zu definieren. Die Regeln werden einer Menge von Regeln (Rulesets) zugehörig gruppiert. Die Regeln können nach dem Entwurf mit einer Business Rule Function getestet werden.
Abb. 3: JDeveloper 11g - Rules Designer Decison Table Zusammengesetzte Anwendungen (Composite Applications) nach dem Service Component Architecture (SCA)-Standard können auch Entscheidungskomponenten enthalten. Die Business Rule Service Komponente lässt sich dann in mehreren Prozessabläufen wiederverwenden, wo dieses Wissen eine Rolle spielt. Eine Composite Application lässt sich sogar mit mehreren Service Komponenten ausstatten, diese können etwa auf Business Rules und BPEL Prozess basieren. Damit lassen sich explizit und flexibel dynamische Prozessabläufe gestalten, die Geschäftsregeln von einem eher statischen Prozess separieren, Validierungsregeln umsetzen und komplexe Benutzerinteraktionen steuern. Abb. 4: Business Rules Komponente Darstellung im SOA Composite Editor Im SOA Kontext ist ein häufiger Anwendungsfall wie oben beschrieben die Nutzung der definierten Regeln innerhalb eines Entscheidungsservice. Eine Business Rule Aktivität wird dafür einfach durch Drag & Drop dem BPEL-basierten Prozessablauf hinzugefügt. Was ist neu? Im aktuellen Release 11gR1 sind viele Neuerungen zur Verfügung. Einige sollen hier kurz zusammenfassend genannt werden. Die Business Rules Engine steht mit 11g als auf SCA basierende Service Komponente mit eigener Engine zur Verfügung. Damit lässt sich eine
Entscheidungskomponente sehr einfach in verschiedenen Kombinationen mit BPEL Process Manager, mit Human Workflow, mit Mediator oder auch alleine einsetzen. Es gibt einen neuen Business Rules Designer im JDeveloper 11g der es ermöglicht die notwendigen Objekte, wie Regeln und Fakten usw., grafisch mit Unterstützung durch Assistenten zu entwerfen. Entscheidungstabellen helfen eine große Anzahl von ähnlichen Regeln einfacher, wie in einer Tabellenkalkulation darzustellen und dadurch besser definierund pflegbar zu machen. Regeln können jetzt für einen bestimmten Zeitraum aktiviert werden. Neben Fakten lassen sich auch sogenannte Bucketsets für Wertemengen oder Bereiche für bestimmte Fakten festlegen. Daneben gibt es noch weitere Neuerungen, etwa bei den APIs. Zusammenfassung Die Verwendung einer Rules Engine eignet sich besonders dort, wo Entscheidungen im Prozess getroffen werden müssen und das Wissen um diese Entscheidungen treffen zu können als Regeln formulierbar ist. Der Aufbau eines anwendungsunabhängigen Wissens-Repository für alle Geschäftsprozesse sollte das Ziel sein. Regeln lassen sich wiederverwenden, d.h. durch das Konzept des Entscheidungsservice können die Regeln in verschieden Prozessen angewandt werden. Strukturierung und Kategorisierung der Regeln in Dictionaries etwa nach fachlichen Domänen oder Problembereichen, hilft die Wiederverwendung zu fördern. Die Regeln lassen sich innerhalb der SOA Suite 11g durch eine sehr enge Integration zusammen mit anderen Komponenten wie dem Mediator, BPEL Process Manager und Human Workflow nutzen. In Zukunft wird auch wieder eine browserbasierte Oberfläche für die Pflege der Regeln als Alternative zum JDeveloper zur Verfügung stehen. Eine Regel ist näher an der Fachabteilung dran. Regeln lassen sich schnell auch zur Laufzeit von geschulten Endanwendern ändern. Dies hilft somit dem Ziel, das eine enge Zusammenarbeit zwischen Fachabteilung und IT, und damit eine schnelle Reaktion auf die Markterfordernisse möglich wird. Kontaktadresse: Michael Stapf ORACLE Deutschland GmbH Business Unit Middleware Technology Geschäftsstelle Frankfurt Robert-Bosch-Str. 5 D-63303 Dreieich Telefon: +49(0)6103-397238 Fax: +49(0)6103-397111 E-Mail: michael.stapf@oracle.com Internet: http://www.oracle.com/technology/products/ias/business_rules/index.html