In einem modernen Unternehmen darf Ihre Entscheidungslogik keine Insel sein. Sie brauchen eine Möglichkeit, Ihre leistungsstarken, fachlich gesteuerten Regeln in DecisionRules mit dem Rest Ihres Technologie-Stacks zu verbinden – um Benachrichtigungen zu versenden, Freigaben auszulösen und komplexe, systemübergreifende Workflows zu orchestrieren. Genau das leisten Automatisierungsplattformen, und die gute Nachricht ist: Die Anbindung an DecisionRules ist denkbar einfach.
Da DecisionRules eine API-first-Plattform ist, ist jedes Automatisierungstool, das einen standardmäßigen REST-API-Aufruf ausführen kann, sofort kompatibel.
In diesem praxisnahen Schritt-für-Schritt-Leitfaden konzentrieren wir uns auf eine der derzeit beliebtesten und flexibelsten Plattformen: N8N. Wir zeigen Ihnen zwei grundlegende Muster für den Aufbau eines leistungsstarken Automatisierungs-Workflows:
- Eine DecisionRules-Regel aus N8N ausführen, um Benachrichtigungen zu automatisieren.
- Einen N8N-Workflow auslösen, um einen manuellen Freigabeprozess zu steuern.
Am Ende dieses Tutorials können Sie anspruchsvolle, automatisierte Entscheidungs-Workflows erstellen, die die Lücke zwischen Geschäftslogik und konkretem Handeln schließen.
Der Anwendungsfall: Ein automatisierter AML-Freigabe-Workflow
Um es praxisnah zu machen, verwenden wir ein gängiges und aussagekräftiges Beispiel aus der Praxis: einen Prüfprozess zur Geldwäschebekämpfung (Anti-Money Laundering, AML).
Unsere DecisionRules-Regel analysiert eine Finanztransaktion und ordnet sie einer von drei Kategorien zu: Automatisch genehmigt, Zur Prüfung markiert oder An Compliance eskalieren. Während „Automatisch genehmigt“ ein abgeschlossener Fall ist, erfordern die beiden anderen Ergebnisse eine abschließende Entscheidung durch einen Menschen. Dieser „Human-in-the-Loop“-Freigabeprozess ist eine ideale Aufgabe für eine Automatisierungsplattform.
Muster 1: Eine Entscheidung aus N8N ausführen
Unser erstes Ziel ist ein Workflow, der in N8N startet, unsere AML-Regel in DecisionRules aufruft und die Entscheidung anschließend automatisch an die richtige Stelle weiterleitet – in diesem Fall durch den Versand einer E-Mail-Benachrichtigung, wenn die Transaktion geprüft werden muss.
Gehen wir Schritt für Schritt vor. Beginnen Sie in Ihrem N8N-Canvas mit einem manuellen Trigger („When clicking 'Execute workflow'“) und fügen Sie einen HTTP-Request-Node hinzu. Für die Konfiguration haben Sie zwei einfache Möglichkeiten:
Schritt 1: Den HTTP-Request-Node konfigurieren
Beginnen Sie in Ihrem N8N-Canvas mit einem manuellen Trigger („When clicking 'Execute workflow'“) und fügen Sie einen HTTP Request-Node hinzu. Dieser Node übernimmt die Kommunikation mit der DecisionRules-API. Für die Konfiguration haben Sie zwei einfache Möglichkeiten.
Option A: Einrichtung in 10 Sekunden (cURL importieren)
Das ist die schnellste Methode. Klicken Sie in der DecisionRules-Testbench Ihrer Regel auf die Schaltfläche „cURL“, um die Anfrage zu kopieren. Klicken Sie dann im HTTP-Request-Node von N8N einfach auf „Import cURL“ und fügen Sie sie ein. Alles – URL, Header und Body – wird automatisch für Sie konfiguriert.
Option B: Manuelle Einrichtung
Wenn Sie die Einrichtung lieber manuell vornehmen möchten, konfigurieren Sie die folgenden Parameter:
Methode: POST
- URL: Die „Solve API“-URL Ihrer Regel (zu finden in DecisionRules).
- Send Headers: Aktivieren (ON).
- Header Name: Authorization
- Header Value: Bearer
Schritt 2: Die Eingabedaten bereitstellen (der Body)
Der letzte Teil der HTTP-Request-Konfiguration ist der Body. Das sind die Eingabedaten, die DecisionRules analysieren soll. Die API erwartet diese Daten als JSON-Objekt, eingebettet in ein übergeordnetes Objekt namens „data“.
Wechseln Sie im N8N-Node zum Abschnitt Body und fügen Sie Ihr Eingabe-JSON ein. Für unser AML-Beispiel sieht das so aus:
Schritt 3: Mit dem IF-Node einen bedingten Pfad erstellen
Da die Entscheidung von DecisionRules nun im rechten Bereich angezeigt wird, ist es an der Zeit, Ihren Workflow darauf reagieren zu lassen. Mit dem leistungsstarken IF-Node von N8N erstellen wir eine Verzweigung, die den Workflow je nach Ergebnis der Regel auf einen anderen Pfad schickt.
- Fügen Sie Ihrem Canvas einen IF-Node hinzu und verbinden Sie ihn mit dem Ausgang des HTTP-Request-Nodes.
- In den Conditions des IF-Nodes legen wir fest, wonach in den von DecisionRules empfangenen Daten gesucht werden soll. Dazu verwenden wir einen Ausdruck, der die JSON-Ausgabe auswertet. Wenn das Ausgabeobjekt unserer AML-Regel Escalation heißt und eine Eigenschaft namens escalate besitzt, lautet der Ausdruck: {{ $json.Escalation.escalate }}
- Legen Sie im restlichen Teil der Bedingung fest, dass geprüft wird, ob dieser Wert true ist. Ihre Konfiguration sollte genau so aussehen:
Ihr Workflow verfügt nun über zwei getrennte Pfade, die vom IF-Node abzweigen: einen „true“-Pfad für Transaktionen, die eskaliert werden müssen, und einen „false“-Pfad für alle anderen Ergebnisse.
Schritt 4: Die Aktion definieren
Im letzten Schritt legen Sie fest, was passiert, wenn die Eskalationsbedingung erfüllt ist.
- Fügen Sie Ihrem Canvas einen Send Email-Node hinzu.
- Entscheidend: Verbinden Sie den „true“-Ausgang des IF-Nodes mit dem Eingang des Send-Email-Nodes. So wird nur dann eine E-Mail versendet, wenn die Eskalationsbedingung erfüllt ist.
- Konfigurieren Sie im Send-Email-Node Empfänger, Betreff und Text der Benachrichtigung. Sie können sogar Daten aus der DecisionRules-Ausgabe (etwa eine Transaktions-ID oder den Kundennamen) übernehmen, um dynamische, kontextreiche Benachrichtigungen zu erstellen.
Wir verwenden hier zwar den generischen Send-Email-Node, doch N8N bietet auch eigene Nodes für Gmail, Slack und Microsoft Teams, die eine noch tiefere Integration mit Ihren konkreten Tools ermöglichen.
Muster 2: Einen N8N-Freigabe-Workflow aus DecisionRules auslösen
Kehren wir den Ablauf nun um. Was ist, wenn ein Entscheidungsprozess, der von einer beliebigen Ihrer Anwendungen angestoßen wird, einen manuellen Freigabe-Workflow starten muss? Bei diesem Muster fungiert DecisionRules als „Gehirn“, das den Eskalationsbedarf erkennt, und N8N als „Hände“, die den mehrstufigen Freigabeprozess orchestrieren.
Unser Ziel ist es, unseren DecisionRules-Flow so zu konfigurieren, dass er einen REST-API-Aufruf an einen N8N-Webhook sendet – aber nur dann, wenn unsere AML-Regel feststellt, dass eine Transaktion geprüft werden muss.
Dieses Diagramm veranschaulicht den Ablauf: Ein externes Tool ruft DecisionRules auf, das die Daten auswertet. Ist eine Eskalation erforderlich, startet DecisionRules in N8N den Freigabeprozess.
Schritt 1: Den empfangenden Workflow in N8N erstellen
Bevor DecisionRules etwas auslösen kann, müssen wir den N8N-Workflow erstellen, der auf den Trigger wartet.
- In einem neuen N8N-Canvas ist Ihr erster Node der Webhook-Trigger. Wenn Sie diesen Node hinzufügen, generiert N8N automatisch eine eindeutige URL dafür. Diese URL ist der Endpunkt, den DecisionRules aufrufen wird. Kopieren Sie diese URL jetzt – Sie benötigen sie im nächsten Schritt.
- Verbinden Sie den Webhook mit den Nodes, die Ihren Freigabeprozess abbilden. Der oben gezeigte Workflow ist ein klassisches Beispiel:
- SendAndWait-E-Mail: Dieser Node sendet einer genehmigenden Person eine E-Mail mit den Links „Approve“ und „Reject“. Der Workflow pausiert dann und wartet, bis einer der Links angeklickt wird.
- Update rows in a table: Sobald die Antwort vorliegt, kann dieser Node das Ergebnis übernehmen und einen Datensatz in der Datenbank aktualisieren, um den Status der Transaktion abzuschließen.
Damit steht Ihnen nun ein leistungsstarker Freigabeservice zur Verfügung, der auf Abruf bereitsteht.
Schritt 2: Den Webhook aus DecisionRules auslösen
Wechseln wir nun zurück zu Ihrem DecisionRules-Flow. Dort fügen wir die Logik hinzu, die den eben erstellten N8N-Webhook aufruft – aber nur, wenn eine Eskalation erforderlich ist.
- Fügen Sie in Ihrem DecisionRules-Flow nach Ihrer Business Rule einen Switch-Node hinzu. Der Switch prüft die Ausgabe der Regel.
- Fügen Sie auf dem „Escalate“-Pfad des Switch einen REST API Client-Node hinzu. Dieser Node löst unseren N8N-Workflow aus.
Konfigurieren wir nun den REST-API-Client-Node. Hier verbinden Sie die beiden Plattformen.
- Select Connector: Klicken Sie auf das Dropdown-Menü „Select Connector“.
- POST URL: Fügen Sie die Webhook-URL ein, die Sie im vorherigen Schritt aus N8N kopiert haben.
- Body: Hierüber übergeben Sie Daten von DecisionRules an N8N. Sie können ein JSON-Objekt aus den Ausgabedaten Ihrer Regel zusammenstellen. Um beispielsweise die Informationen zur Mailingliste zu senden, verwenden Sie: { "mailing": mailing.output }
Das war's schon. Ihr DecisionRules-Flow führt nun seine Logik aus und löst bei Bedarf einer Eskalation sofort Ihren N8N-Freigabe-Workflow aus – inklusive aller erforderlichen Daten. Entscheidend ist: Der DecisionRules-Flow wartet nicht, sondern gibt sein eigenes Ergebnis sofort an die aufrufende Anwendung zurück, während N8N den separaten, asynchronen Freigabeprozess steuert.
Fazit: Von einfachen Regeln zu leistungsstarken Workflows
Wie Sie anhand dieser beiden Muster gesehen haben, ist die Verbindung von DecisionRules und N8N denkbar einfach. Dank des API-first-Designs von DecisionRules können Sie Ihre leistungsstarke Geschäftslogik nahtlos mit den umfangreichen Orchestrierungsfunktionen moderner Automatisierungsplattformen integrieren.
Sie haben nicht einfach zwei Tools verbunden, sondern ein System geschaffen, in dem Ihre Fachexperten das „Was“ (die Entscheidungslogik) definieren und Ihre Automatisierungs-Workflows das „Wie“ (Benachrichtigungen, Freigaben und Systemaktualisierungen) übernehmen. Das ist das Fundament echter Unternehmensautomatisierung.