Dies ist ein konzeptioneller Überblick über die Architektur der Business Rules Engine auf hoher Ebene. Sie steht über dem eigentlichen Code. Wenn Sie eine Business Rules Engine bauen – ist es sehr wahrscheinlich, dass Sie diesen Text nützlich finden werden.

Einst habe ich eine Business Rules Engine gebaut, die Geschäftsautomatisierung für kleine und mittlere Unternehmen ermöglichte und auch alle Fähigkeiten und das Potenzial hatte, großen Unternehmen gut zu dienen. Es war ein Weg von einer normalen Softwareanwendung zu einer ausgefeilten und komplexen Lösung, die den hohen Anforderungen an Skalierbarkeit, Wartbarkeit und Erweiterbarkeit gerecht wurde. Dieser Text gibt einen Überblick darüber, was eine Business Rules Engine ist, und beschreibt einen der modernen Ansätze, die Sie bei der Entwicklung dieser Art von Software in Betracht ziehen können.

Zunächst ist es wichtig, grundlegende Begriffe zu definieren. Business Rules Engines gibt es in der einen oder anderen Form schon sehr lange in der Industrie, und es gibt einige Definitionen für so ziemlich jeden Begriff, den wir verwenden werden. Beginnen wir mit einer „Geschäftsregel“ – es gibt eine bekannte Definition für diesen Begriff. Eine „Geschäftsregel“ ist also:

Eine Aussage, die einen Aspekt des Geschäfts definiert oder einschränkt. Sie dient dazu, die Geschäftsstruktur durchzusetzen oder das Verhalten des Unternehmens zu kontrollieren oder zu beeinflussen.

T. Morgan, Business Rules and Information Systems. Boston: Addison-Wesley Publishing, 2002

Geschäftsregeln haben einen sehr weiten Anwendungsbereich und können auf jeden Aspekt des Unternehmens angewendet werden. Zum Beispiel wird die Regel „Wenn ein Kunde hereinkommt, grüßen Sie ihn mit einem warmen Lächeln und einem freundlichen „Hallo““ von einem Mitarbeiter des Unternehmens angewendet, wenn er sich mit Kunden trifft. Eine andere Regel kann die Herangehensweise an die Lösung von Routineaufgaben durch eine bestimmte Rolle in einem Unternehmen definieren oder einschränken. Mit der stetig wachsenden Popularität von Softwarelösungen wie CRM-Systemen und der vollständigen Integration von Software in eine Vielzahl von Geschäftsbereichen ist ein Großteil der Geschäftsprozesse teilweise oder vollständig datenorientiert geworden. Die Geschäftsregel „Wenn ein Kunde etwas in unserem Geschäft kauft, rufen Sie ihn später an und fragen ihn, ob er noch andere verwandte Waren kaufen möchte“ hat sich zu einer moderneren Regel gewandelt: „Wenn ein Kunde etwas in unserem Online-Shop kauft, schicken Sie ihm später eine E-Mail mit einer Liste weiterer verwandter Waren“. Heutzutage haben viele Unternehmen bei ihrer täglichen Arbeit hauptsächlich mit Daten zu tun. In Anbetracht der Tatsache, dass die meisten Unternehmen aller Größenordnungen Softwarelösungen in ihre Geschäftsaktivitäten integriert haben, kann die Definition des Begriffs „Geschäftsregel“ durch Hinzufügen einer Klarstellung (fett gedruckt) zu der oben genannten Definition von T. Morgan präzisiert werden:

Eine Geschäftsregel ist eine Aussage, die einen Aspekt des Geschäfts definiert oder einschränkt. Sie dient dazu, die Geschäftsstruktur durchzusetzen oder das Verhalten des Unternehmens zu kontrollieren oder zu beeinflussen. Sie wird als Datenkonstrukt im persistenten Speicher abgelegt und enthält ein atomares Paket von Geschäftslogik. Sie wird über eine Softwarelösung verwaltet und automatisch auf die Geschäftsprozesse des Unternehmens angewendet.

Nachdem der Begriff „Geschäftsregel“ definiert wurde, wird der Begriff „Business Rules Engine Management System“ (BRMS) wie folgt definiert:

BRMS ist eine Softwarelösung zur Verwaltung (Speichern, Bearbeiten und Löschen etc.) von Geschäftsregeln sowie zu deren Anwendung auf die Geschäftsprozesse des Unternehmens.

Standardmäßige kommerzielle BRMS können extrem teuer sein, was den Erwerb der Lizenz und die Integration in die IT-Infrastruktur des Unternehmens angeht, daher implementieren Unternehmen oft firmeninterne Lösungen, wenn sie auf die Notwendigkeit stoßen, Geschäftsprozesse oder andere Arten von Prozessen zu automatisieren.
BRMS können zu einem wesentlichen und lebenswichtigen Bestandteil eines jeden Unternehmens werden. Manchmal kann der Erfolg eines Unternehmens von den Geschäftsregeln abhängen, die es hat, und davon, wie gut diese Geschäftsregeln verwaltet und angewendet werden.

Das Datenkonstrukt für Geschäftsregeln

Eine Geschäftsregel kann als eine konsequente Folge von atomaren Befehlen dargestellt werden. Die Befehle können bedingte Datenanalysen, Befehle zum Warten auf Zeit, Befehle zur Ausführung von Aktionen usw. umfassen. Das Beispiel der Geschäftsregel „Wenn ein Kunde etwas in unserem Online-Shop kauft, schicke ihm später eine E-Mail mit einer Liste anderer verwandter Waren“ ist ein gutes und allgemeines Beispiel, und viele andere Geschäftsregeln können eine sehr ähnliche logische Struktur haben:

Der Regelverarbeitungsfluss wird gestartet, wenn ein Kauf getätigt wurde und einige Geschäftslogik wird angewendet, indem der Befehl „Sende dem Käufer eine E-Mail mit relevanten Warenangeboten“ ausgeführt wird. Dabei kann es vorkommen, dass der Käufer das E-Mail-Abonnement deaktiviert hat. Dann muss der Geschäftsregel die zusätzliche Bedingung „wenn der Käufer das E-Mail-Abonnement aktiviert hat“ hinzugefügt werden:

Die Befehle werden folglich ausgeführt und es gibt nun einen Datenanalysebefehl, um zu prüfen, ob der Käufer ein aktives E-Mail-Abonnement hat. Wenn ja – fahren Sie mit der Ausführung des nächsten Befehls der Geschäftsregel fort. Und wenn nicht – nicht fortfahren, die Geschäftsregel wird als beendet betrachtet, der Verarbeitungsfluss stoppt, die nachfolgenden Befehle werden nicht ausgeführt.

Der Käufer kann auch ein SMS-Abonnement haben, und wenn es aktiv ist, sollte es auch einen weiteren Befehl geben – „Sende eine SMS mit zugehörigem Werbeangebot“. Damit wird eine Verzweigung in die Logik der Geschäftsregel eingeführt:

Die Zweige der Regel werden unabhängig voneinander verarbeitet. Die Verarbeitung eines der Zweige kann beim Befehl zur Bedingungsauswertung aufhören und ein anderer Zweig kann bis zum Ende verarbeitet werden.

Das UI der BRMS-Client-seitigen Anwendung zur Darstellung einer Geschäftsregel kann auf verschiedene Weise implementiert werden (jede Art von grafischer Baumdarstellung ist möglich):

Das Datenkonstrukt der Geschäftsregel ist ein gerichteter verwurzelter Baumgraph (ein gerichteter azyklischer Graph, dem ein Baum als ungerichteter Graph zugrunde liegt). Die Knoten des Geschäftsregelgraphen werden durch verschiedene Arten von Befehlen dargestellt: Befehle zur Datenanalyse, Befehle zur Ausführung von Aktionen, Befehle zum Abwarten von Zeiten usw. Jeder gerichtete, verwurzelte Baum hat eine Wurzel – einen Knoten, von dem aus alle Kanten nach außen zeigen. Somit beginnt jede Regel mit einem speziellen Knoten (oder Wurzelknoten im Sinne der Graphentheorie) – dem Knoten, der den Einstiegspunkt für die Regelverarbeitung bezeichnet.

CRUD-Operationen auf dem Datenkonstrukt der Geschäftsregeln

Da das Datenkonstrukt durch einen gerichteten Wurzelbaum und niemals durch irgendeine andere Art von Graph dargestellt wird, entfallen die Unannehmlichkeiten, die mit der Speicherung allgemeiner Graphenstrukturen in RDBMS einhergehen (wie z.B. die Speicherung der Scheitelpunkte und Kanten in verschiedenen Tabellen, was zu einer erhöhten Anzahl von Suchvorgängen für eine einzige Regelabfrage führen kann usw.). Und das ist kritisch, denn es ist klar, dass während des normalen Betriebs des BRMS Datenabfragen viel häufiger vorkommen als andere Operationen wie Einfügen, Aktualisieren oder Löschen.

Nur zur Erinnerung – jeder Scheitelpunkt der Geschäftsregel stellt einen atomaren Befehl dar. Er wird in der RDBMS-Tabelle als Datensatz mit Attributen wie Befehlstyp, Beschreibung und anderen zusätzlichen Daten gespeichert. In einem Baum hat jeder Knoten ein und nur ein Elternteil (mit Ausnahme des Wurzelknotens, der keine Eltern hat), daher sollte jeder Datensatz eine ID des Elternknotens enthalten. Es ist auch praktisch, eine weitere Tabelle zu haben, die die Regeldatensätze mit den für die Geschäftsregel selbst relevanten Daten enthält. Bei diesem Ansatz gibt es keine Probleme mit der Speicherung von beliebig komplexen Datenkonstrukten für Geschäftsregeln.

Die CRUD-Operationen sind ziemlich einfach. Die Änderungen der Geschäftsregel können Aktualisierungen in einer oder beiden Tabellen – Regel oder Befehl – erfordern. Beim Löschen oder Einfügen von Befehlen ist es notwendig, die Referenzen zwischen den Befehlen zu erhalten (dies ist im Wesentlichen das Löschen oder Einfügen von Knoten in einen Baum).

Eine der BRMS-Komponenten, nennen wir sie einen Manager, sollte die beschriebenen Datenbankoperationen durchführen und eine API für CRUD-Operationen auf Geschäftsregeln bereitstellen.

Die Verarbeitung der Geschäftsregel

Die Verarbeitung der Geschäftsregel beginnt, wenn ein bestimmtes Geschäftsereignis eintritt. Das kann alles Mögliche sein – ein Benutzer hat sich eingeloggt, ein Kauf wurde getätigt, ein Geldbetrag wurde überwiesen, usw. Diese Art von Aktivität sollte nachverfolgt werden und das BRMS sollte über einen Transport darüber informiert werden. AMQP ist höchstwahrscheinlich die beste Lösung für diese Art von Aufgabe.

1. Das gesamte Konzept ist auf einer Microservice-Architektur aufgebaut. Der Microservice, der Geschäftsereignisse konsumiert, hört auf alle Geschäftsereignisse, indem er eine Warteschlange deklariert und sie an einen bestimmten Austausch auf einem RabbitMQ-Austauschserver bindet. Wenn eine Geschäftsaktivität (die als wichtig angesehen und verfolgt wird) im Hauptsystem stattfindet, wird die Nachricht an den RabbitMQ-Exchange-Server gesendet. Sie enthält Informationen über das Ereignis sowie einige relevante Zusatzdaten. Das Geschäftsereignis kann durch ein beliebiges Attribut identifiziert werden, das in der Nachricht übergeben oder als Routing-Schlüssel verwendet wird, z. B. durch die Zeichenfolge purchase.completed. Die Nachricht wird dann vom BRMS-Microservice für Geschäftsereignisse konsumiert.

2. Wenn der BRMS-Microservice für Geschäftsereignisse die Nachricht vom Hauptsystem erhält, fragt er den Manager-Microservice ab, ob es in der Datenbank Geschäftsregeln gibt, die den entsprechenden Regelauslöser für das Geschäftsereignis haben. Wenn eine solche passende Geschäftsregel vorhanden ist, gibt der Manager-Microservice die ursprünglichen Befehlsdaten an den Business Event Consumer Microservice zurück. Dieser Datenabruf vom Manager erfolgt über gRPC und wird mit einer gestrichelten Linie visualisiert.

3. Unmittelbar nach der Antwort des Manager-Microservice mit den anfänglichen Befehlsdaten ist der Business Event Consumer Microservice bereit, die Verarbeitung der Geschäftsregel zu initialisieren. Der Geschäftsereigniskonsument erstellt eine weitere Nachricht, die die anfänglichen Befehlsdaten (vom Manager-Microservice empfangen) und die Daten des Geschäftsereignisses, die vom Hauptsoftwaresystem empfangen wurden, kapselt. Er sendet sie über AMQP an einen internen BRMS-Austausch. Der Routing-Schlüssel der Nachricht entspricht dem Befehlstyp.

4. Der Microservice für die anfängliche Befehlsverarbeitung konsumiert die Nachricht (er hört die Warteschlange ab, in der die Nachrichten mit dem Routing-Schlüssel initial gestapelt sind). Dann führt er seine Logik aus (im Grundfall beherbergt der Anfangsblock keine Logik) und fragt den Manager ab, ob es in der Geschäftsregel nachfolgende Befehle gibt (das sind die Befehle mit parent_id gleich id des Befehls, der gerade verarbeitet wird). Wenn ja, erhält er die Daten des nächsten Befehls und sendet sowohl die Geschäftsereignisdaten als auch die Daten des nächsten Befehls an den internen RabbitMQ-Server. Ja, es sieht jetzt aus wie eine verknüpfte Liste, und wenn die Regel Verzweigungen hat, ist es ein Baum-Traversal! Auf diese Weise wird die Geschäftsregel Befehl für Befehl verarbeitet. Und noch etwas ist wichtig: In diesem Kontext werden die Geschäftsereignisdaten an jeden untergeordneten Befehl weitergegeben. Es handelt sich um einen Kontext der einmaligen Ausführung der Geschäftsregel. Er kann später im Datenanalyse-Befehlsprozessor und im Aktionsbefehlsprozessor verwendet werden.

Nehmen wir zur Veranschaulichung an, dass die Beispielregel folgende Struktur hat: Initialbefehl -> bedingter Datenanalysebefehl -> Geschäftsaktionsbefehl. Dann ist der nächste Befehl nach dem Initialbefehl der Datenanalysebefehl.

5. Der Analyse-Befehlsprozessor konsumiert die Nachricht mit dem Routing-Schlüssel analysis aus dem internen Austausch. Auf der Grundlage der Auswertung der Bedingungen, die im Analysebefehl der Geschäftsregel beschrieben sind, und unter Verwendung der Geschäftsereignisdaten kann der Regelausführungsfluss hier fortgesetzt oder angehalten werden. Wenn er anhält, werden keine weiteren Geschäftsregelbefehle ausgeführt. Wird der Ausführungsfluss fortgesetzt, fragt der Analysebefehlsprozessor den Manager nach den nächsten Geschäftsregelbefehlen, ruft sie ab und veröffentlicht eine weitere Nachricht an den internen Exchange Server.

6. Schließlich befindet sich eine Nachricht im internen Austausch, die für den Aktionsbefehlsprozessor bereit ist, konsumiert zu werden. Wenn der Ausführungsfluss der Geschäftsregel bis zu diesem Befehl gekommen ist, bedeutet das, dass in diesem Zweig der Regel jede Bedingung, die in dem Datenanalysebefehl enthalten war, wahr war und der Ausführungsfluss nicht unterbrochen wurde. Der Aktionsbefehlsprozessor führt die Aktion aus, z. B. sendet er eine E-Mail.

Diese Art von Graphentraversal ist tiefenorientiert, und wenn ein Befehl mit 2 oder mehr untergeordneten Befehlen angetroffen wird, beginnt die gleichzeitige tiefenorientierte Traversal für jeden Zweig aufgrund der asynchronen Natur der Geschäftsregelverarbeitung in dem beschriebenen System.

Skalierung

Der beschriebene Ansatz ermöglicht nicht nur eine große Trennung von Belangen, sondern kann auch viel Geld sparen, wenn es um die Bezahlung der IaaS-Rechnungen geht. Endbenutzer erstellen eine Vielzahl von Geschäftsregeln mit einer unterschiedlichen Anzahl von Befehlen verschiedener Art und einer unterschiedlichen Anzahl von Verzweigungen. Die häufigsten Skalierungsszenarien sind jedoch die folgenden:
1. Die Anzahl der Geschäftsereignisse nimmt zu – der Ereignisverbraucher skaliert nach oben.
2. Die Anzahl der Geschäftsregeln, die mit den Geschäftsereignissen verbunden sind (ausgelöst werden), nimmt zu – der Ausgangsbefehlsprozessor skaliert zusammen mit dem Manager nach oben.
3. Es gibt viele Analysebefehle in den Geschäftsregeln – der Analysebefehlsprozessor skaliert nach oben
4. Zu viele Aktionsbefehle müssen ausgeführt werden – der Aktionsbefehlsprozessor skaliert nach oben.

Zuverlässigkeit

Das Blutgefäß des Systems ist der Transport. Damit das System auch unter hoher Last funktionsfähig bleibt, sollte der interne Nachrichtenaustausch sehr zuverlässig sein. RabbitMQ bietet Clustering und erfüllt die Anforderungen an die Zuverlässigkeit gut (https://www.rabbitmq.com/clustering.html).

Andere Befehlsarten

Eine andere Geschäftslogik kann in das System eingeführt werden. Einer der beliebtesten und am häufigsten nachgefragten Befehlstypen ist der Zeit-Warte-Befehl (z.B. ’45 Minuten warten, dann weiter‘). Mit der Einführung des Time-Wait-Befehls ist die Verarbeitung der Geschäftsregel keine Echtzeitverarbeitung mehr, da sie für einige Zeit ausgesetzt werden kann. Solche Änderungen erfordern zusätzliche Befehlsprozessoren und einige Anpassungen an den Datenstrukturen, die den Rahmen dieses Textes sprengen würden. Es kann schwierig sein, mit der Zeit umzugehen, und das Schreiben eines Dienstes, der die Zeitpläne und die Zeit steuert, kann eine Herausforderung sein: https://github.com/nextiva/krolib

Alternativen von Drittanbietern

Es gibt bekannte Alternativen von Rules Engines/Workflow Engines, hier sind die Top 3 davon (IMHO):
1. Comunda – es ist ein ausgereiftes Produkt mit Community- und Enterprise-Versionen, die Sie vielleicht verwenden möchten. Natürlich ist die Unternehmensversion kostenpflichtig.
2. Luigi – es ist ein Workflow-Engine-Tool, das von Spotify für ihre internen Bedürfnisse entwickelt wurde, aber bereits von Dutzenden anderer Unternehmen verwendet wird.
3. Apache Airflow – dies ist ein weiteres bekanntes Produkt, das sich als fähig, bequem und anpassbar erwiesen hat.

Was diese Tools eint, ist, dass sie alle direkte azyklische Graphen als Datenstruktur verwenden, die die Geschäftsregeln oder Workflows darstellen. Das ist keine Überraschung.

Es mag noch andere Produkte geben, die es wert sind, beachtet zu werden, aber jede Untersuchung sollte mit diesen drei beginnen.

Schlussfolgerung

Die Entwicklung einer eigenen Business Rules Engine mag eine Herausforderung sein, aber sie lohnt sich. Sie erhalten nicht nur ein eigenes System, sondern es wird auch nach den spezifischen Anforderungen Ihres Unternehmens erstellt. Ein gutes DevOps-Team ist ein Muss, wenn es um die Aufrechterhaltung der Zuverlässigkeit, Skalierbarkeit und Überwachung geht. Schließlich erhalten Sie ein fantastisches Produkt, auf das Sie stolz sein können.