Agilität in Integrationsprojekten

Umsetzung von fachlichen Entscheidungen mit Apache Camel

In vielen Enterprise Integration Patterns müssen Entscheidungen aufgrund des Inhaltes der Messages gefällt werden (Message Router, Content Based Router, Message Filter, Dynamic Router, Recipient List, ControlBus). Häufig sind dies rein fachliche Entscheidungen, beispielsweise die Festlegung von bestimmten Grenzwerten. Aufgrund von äußeren Rahmenbedingungen (z.B. Änderung der Strategie eines Unternehmens, neue Gesetze) müssen diese Entscheidungen oft auch angepasst und neu umgesetzt werden.

In Apache Camel gibt es verschiedene Ansätze, wie Entscheidungsregeln implementiert und angebunden werden können.

Verschiedene Einbindungsstrategien von Fachentscheidungen in Apache Camel:

Alles im Code

Die einfachste Möglichkeit, solche Entscheidungen in Apache Camel abzubilden, ist deren direkte Implementierung. Je nach Komplexität der Struktur der Messages kann dies entweder mit einer von Apache Camel unterstützten Sprache (z.B. Simple Expression Language oder XPath) oder ausgelagert in einem Java Bean im Java Code umgesetzt werden. Die so direkt im Sourcecode abgelegte Logik ist für einen Entwickler sehr einfach umzusetzen. Für eine Fachperson hingegen ist sie nur sehr schwer verständlich. Weiter ist die Entscheidungslogik stark mit den technischen Strukturen der Integration verwoben, sodass jede (fachliche) Änderung dieser Logik ein Deployment des gesamten Systems erfordert.

	
	public void decide(Customer c) {
		if (c.getAge < 15) {
		c.setAccount("infant");
		} else if (c.getAge < 21) {
		c.setAccount("youth");
		} ...
		}
	

Abbildung 1: Beispiel einer Regel im Sourcecode

Anwendungsfall:

Die Entscheidungsregeln ändern sich während des Lebenszyklus der Software kaum und das Regelwerk wird ausschließlich von Entwicklern gepflegt und verwaltet.

Verwendung einer Regel-Engine (Drools)

Um die Entscheidung für Fachpersonen verständlich zu machen oder es sogar zu ermöglichen, die Entscheidungsregeln direkt von Fachanwendern zu verwalten, kann Drools eingesetzt werden. Drools bietet von der Rule Language bis zu Decision Tables verschiedene Arten, um Regeln zu definieren. Es gibt auch Tools, um die Regeln in DMN zu definieren und diese in Drools laufen zu lassen.

Abbildung 2: Beispiel einer Decision Table

Drools kann einfach in Apache Camel integriert werden. Dazu wird als erstes eine Drools KIE Session definiert. Die Session bekommt einen Namen und einen Type und mit dem packages-Attribut in kie:kbase wird der Ablageort der Regeldefinitionen angegeben.

	
	<kie:kmodule id="camel-context">
	<kie:kbase name="rules" packages="ch.adesso.crm.rules">
	<kie:ksession name="ksession-1" type="stateless"/>
	</kie:kbase>
	</kie:kmodule>
	

Abbildung 3: Drools KIE Session definieren

Wenn die Session einmal definiert ist, kann sie anschliessend in Apache Camel mit Hilfe der KIE-Komponente verwendet werden. Für das Objekt, das sich im Body des Exchanges befindet, werden die Regeln der Session ausgewertet.

	
	<to uri="kie:ksession-1?action=insertBody" />
	

Abbildung 4: KIE Session in Apache Camel verwenden

Der Vorteil dieses Ansatzes ist, dass die Regeln nun in einer für Fachbenutzer verständlicheren Notation definiert werden können. Wird aber eine Regel geändert, bedingt das immer noch ein Deployment in Apache Camel, um die neuen Regeldefinitionen anwendbar zu machen.

Anwendungsfall:

Die Entscheidungsregeln ändern sich während des Lebenszyklus der Software selten und die Fachbenutzer sind bei der Pflege der Regeln involviert.

Auslagerung von Regeln in einen Decision Server

Um das Deployment der Routen in Apache Camel (Integrationslogik) und den fachlichen Regeln für Entscheidungen voneinander zu trennen, kann ein von Apache Camel unabhängiger Decision Server für Drools verwendet werden. Die Regeln werden direkt in diesem Server definiert und können über ein REST API eingebunden werden. Somit können sie im Decision Server beliebig geändert werden – die Apache Camel Route verwendet immer die aktuellste Version der Regeln, ohne dass ein Deployment der Integrationslogik notwendig wäre. Wenn die Regeln zentral im Decision Server verwaltet werden, hat dies auch den Vorteil, dass sie von weiteren Applikationen verwendet werden können und sie nicht für jede Applikation kopiert oder sogar neu implementiert werden müssen. Somit wird Redundanz vermieden und ein konsistentes System garantiert.

Um die Regeln in einem Decision Server implementieren zu können, muss im Server das Domänenmodell mit Hilfe von Maven importiert werden. Die Regeln werden dann auf Basis der Domänenklassen definiert. Der Decision Server bietet ein Web GUI, das es auch Fachbenutzern erlaubt, die Regelbasis einfach zu pflegen.

Um die Regeln aus Apache Camel schliesslich anwenden zu können, müssen die zu analysierenden Objekte serialisiert im Exchange Body abgelegt werden, damit in der Folge mit einem simplen REST-POST-Aufruf die entsprechenden Regeln ausgeführt werden können. Das Resultat der Regelauswertung wird anschließend wieder im Body des Exchanges abgelegt und muss allenfalls wieder deserialisiert werden.

	
	<to uri="http://localhost:8080/kie-server/services/rest/server/containers/instances/customerdrl?authMethod=Basic&amp;authUsername=xxx&amp;authPassword=xxx" />
	

Abbildung 5: REST Aufruf aus Apache Camel

	
	<batch-execution lookup="defaultStatelessKieSession">
	<insert out-identifier="customer" return-object="true" entry-point="DEFAULT">
	<ch.adesso.crm.persistence.entities.Customer>
	<name>Daniel</name>
	<age>24</age>
	</ch.adesso.crm.persistence.entities.Customer>
	</insert>
	<fire-all-rules />
	</batch-execution>
	

Abbildung 6: Beispiel Body des REST Request

Bei der Verwendung eines Decision Servers muss jedoch berücksichtigt werden, dass die Komplexität des Systemes durch den zusätzlichen Server erhöht wird. Es muss ebenfalls in Betracht gezogen werden, dass die Kommunikation mit dem Decision Server einen gewissen Overhead mit sich bringt, der bei sehr vielen Aufrufen die Performance beeinträchtigen könnte.

Anwendungsfall:

Die Regeln ändern sich häufig und die Fachbenutzer spielen eine wesentliche Rolle bei der Entwicklung und Pflege der Regelbasis.

Fazit

Es gibt verschiedene Ansätze, wie Business Rules in Apache Camel integriert werden können. Doch gibt es auch hier nicht die perfekte Lösung für jede Situation und es muss je nach Anwendungsfall entschieden werden, was am meisten Sinn macht.