Use Cases

Wie man ein Provisionsmodell mit DecisionRules aufbaut Teil III - Detaillierte Implementierung von Regeln und Orchestrierung

In den vorherigen Artikeln haben wir das Provisionsmodell beschrieben, einen Überblick über seine Struktur gegeben und Beispiele für mehrere Provisionsregeln für jede der vorgeschlagenen Klassen (Verkaufs-, Leistungs- und Umsatzprovisionen) bereitgestellt. Im letzten Artikel der Reihe werden wir uns darauf konzentrieren, die praktische Umsetzung der Regeln mithilfe der DecisionRules-Umgebung zu zeigen, deren Orchestrierung und die Einrichtung eines externen API-Aufrufs, der verwendet wird, um das Modell in Ihre eigenen Anwendungen zu integrieren.

Wie man ein Provisionsmodell mit DecisionRules aufbaut Teil III - Detaillierte Implementierung von Regeln und Orchestrierung hero image

Implementierung der Provisionsregeln in DecisionRules

Zunächst werden wir mehrere Beispiele präsentieren, wie die Regeln mit unserem Tool implementiert werden. Es stehen uns 3 Optionen zur Verfügung, wenn wir eine neue Regel erstellen: Entscheidungstabelle, Entscheidungsbaum und eine Skriptregel. Die meisten Regeln in unserem Modell sind in Form von Entscheidungsbäumen gestaltet, die die logische Struktur IF(Bedingung) THEN Ergebnis, wenn die Bedingung erfüllt ist oder ELSE Ergebnis, wenn die Bedingung nicht erfüllt ist annehmen.

Beispiel für die Regelimplementierung

Beispiele für Provisionsregeln

Zuvor haben wir beschrieben, wie eine typische Provisionsregel aussehen und funktionieren wird (als Beispiel haben wir die Regeln Darlehensverkauf und Neukunde verwendet). Jetzt werden wir einen etwas detaillierteren Blick auf einige ausgewählte Teile der Implementierung werfen, um zu zeigen, wie Sie Bedingungen einrichten können, um benutzerdefinierte Ausgaben zu erstellen.

Die meisten der Regeln, die wir für diese Präsentation erstellt haben, sind in Form eines Entscheidungsbaums, der die Eingabebedingungen bewertet und die Ausgabe entsprechend festlegt.

Diese Regeln verwenden eine einfache Menge vordefinierter Operatoren und Funktionen. Die Verwendung nur einer einfachen Menge von Operatoren bedeutet, dass wir Regeln erstellen können, die leicht zu verstehen, zu unterstützen und bei Bedarf zu ändern sind.

Alle verfügbaren Operatoren und Funktionen sind in der Dokumentation mit Erklärungen und Anwendungsbeispielen beschrieben.

Sowohl Operatoren als auch Funktionen können je nach Bedarf in einer Regel kombiniert werden. Ein Beispiel dafür ist die Provisionsregel Darlehen durchführen.

Hier verwenden wir grundlegende Operatoren, um die Werte in den Variablen productType und daysDelinquentCount zu überprüfen, sowie eine Funktion, um zu prüfen, ob das openDate mindestens ein Jahr in der Vergangenheit liegt. Sie können sehen, dass wir auch den OR-Block verwenden, um zwei mögliche Werte für die Eingabevariable state zuzulassen. Für die Implementierung dieser speziellen Bedingung könnten Sie auch den grundlegenden Operator IN verwenden, was zum gleichen Ergebnis führen würde.

Der Stil der Implementierung hängt von Ihren Vorlieben ab und vor allem davon, welchen Ansatz Sie für besser lesbar und leichter verwaltbar halten.

Verwendung von Skriptregeln

Die meisten der Regeln, die wir in DecisionRules erstellen, können mit den bereitgestellten Operatoren in Entscheidungstabellen oder -bäumen ausgedrückt werden. Sie könnten jedoch in einer Situation sein, in der diese bereitgestellten Funktionen nicht ausreichen oder zu einer schwer lesbaren Regel führen.
Für diese speziellen Fälle steht ein weiterer Regeltyp zur Verfügung, der als Skriptregel bezeichnet wird. Diese ermöglichen es Ihnen, Javascript-Code zu verwenden, um komplexe Regeln mit fortgeschrittenen Berechnungen zu implementieren. Sie können ein Beispiel für ein solches Skript in der Implementierung der Provisionsregel Verkaufte Darlehen sehen. Diese Provision überprüft alle Darlehen, die der Makler unterzeichnet hat, und wenn die Gesamtsumme einen Schwellenwert überschreitet, wird eine Provision gewährt.

Im Skript können Sie die Eingabe- und Ausgabevariablen verwenden, indem Sie auf die Objekte input und output zugreifen und dann die erforderlichen Berechnungen durchführen. Die Regel endet immer mit einem Rückgabebefehl output, der die ausgegebene Information an den Aufrufer sendet.

Wenn Sie Fragen zu diesem Skript haben, können Sie unsere Dokumentation konsultieren.

Hauptorchestrierungsregel

Im vorherigen Artikel haben wir die Struktur unseres Provisionsmodells beschrieben, indem wir es in 3 Schichten unterteilt haben. Die Schichten 2 und 3 sind die Bereiche, in denen Sie die meisten Änderungen vornehmen würden, um ein Provisionsmodell für Ihren eigenen Anwendungsfall zu erstellen (diese Schichten enthalten die Listen der Regeln in jeder Klasse und die Provisionsregeln selbst). Schicht 1 enthält die orchestrierende Regel des gesamten Modells, und sie benötigt keine Änderungen, es sei denn, Sie möchten die Funktionalität des Modells erheblich ändern.

Die Hauptorchestrierungsregel Calculate Commissions behandelt die Integration in beide Richtungen (IN und OUT) und wird als Skriptregel implementiert. In unserem Fall wird die Regel verwendet, um die Eingabe zu verarbeiten, alle erforderlichen Provisionsregeln zu bewerten und dann die Ausgabe in die gewünschte Form zu kompilieren. Es ist nicht notwendig, dieses Skript zu ändern, es sei denn, Sie möchten eine völlig neue Klasse von Provisionen in das Modell einfügen.

Das Skript hat einen separaten Teil für jede der Provisionsklassen, und in jedem Fall ruft es zuerst die entsprechende Tabelle Commissions List auf, um alle aktiven Provisionen zu erhalten, die bewertet werden sollen. Dann durchläuft es alle Geschäfte in der Eingabe und überprüft das Ergebnis jeder Provisionsregel in der ausgewählten Klasse. Wenn alle Regeln für alle Geschäfte bewertet wurden, werden alle Ergebnisse in einem Array an die Ausgabe gesendet, zusammen mit zusätzlichen Informationen über das Bewertungsdatum und den Broker.
Der vollständige Code ist im Modell in der Skriptregel Calculate Commissions verfügbar.

Die meisten Berechnungen in dieser orchestrierenden Regel werden mit regulärem JavaScript durchgeführt; die einzigen Ausnahmen sind die Bewertungen anderer Regeln in Ihrem Bereich. Dafür können Sie ein DR-Paket verwenden, das eine „solve“-Funktion zur Bewertung von Regeln bereitstellt. Der Code kann folgende Form annehmen:

Zuerst müssen wir den Alias der Regel angeben, die wir bewerten möchten (alternativ können Sie immer die Regel-ID verwenden, aber die Verwendung des Alias macht den Code viel lesbarer; beide sind in den Regel-Einstellungen jeder Regel verfügbar) und dann einige Daten an deren Eingabe übergeben. Wir haben dann die Möglichkeit, mehrere optionale Parameter zu verwenden, die es uns beispielsweise ermöglichen, anzugeben, welche Version der Regel wir verwenden möchten, welche Strategie wir zur Bewertung verwenden möchten oder welche Teile der Ausgabe wir extrahieren möchten. Für weitere Informationen zu diesen Einstellungen werfen Sie bitte einen Blick in unsere Dokumentation.

Im obigen Beispiel sehen Sie, wie wir diese solve-Funktion verwenden, um eine Liste von IDs der Provisionsregeln zu erhalten. Wir bewerten eine Tabelle der Verkaufsprovisionen, die eine Liste aller aktiven Provisionen enthält, daher müssen wir keine Eingabedaten verwenden. Der Parameter „latest“ ist einer der optionalen Parameter, und wenn Sie immer die neueste Version der Regel verwenden, kann er weggelassen werden.

Regelentwurf

Lassen Sie uns nun einige Dinge betrachten, die es Ihnen erleichtern werden, das Modell zu verwenden und es an Ihre Bedürfnisse anzupassen:

Testbank

Beim Testen oder Feinabstimmen der Regeln können Sie die Funktion Testbank verwenden, um zu visualisieren, wie die Bewertung der Regel verläuft, und um sie zu testen und zu debuggen. Auf der linken Seite der Testbank können Sie Werte für Ihre Eingangsvariablen festlegen, und nachdem Sie die Schaltfläche Ausführen gedrückt haben, sollten Sie die Ausgabe auf der rechten Seite sehen. Wenn die Provision gewährt wird, sehen die Testergebnisse ungefähr so aus (mit der Debug-Einstellung sind die aktiven Blöcke grün hervorgehoben).

Ein weiteres Beispiel zeigt, was passiert, wenn die Provision nicht gewährt wird (Sie können die fehlgeschlagene Bedingung in Rot hervorgehoben sehen, und die Ausgabemeldung enthält eine Liste der Werte aus der Eingabe, sodass klar ist, welche Bedingungen fehlgeschlagen sind).

Vorlagenregeln - Einrichten einer neuen Provisionsregel

Die gesamte Verwaltung der Provisionen erfolgt über die Benutzeroberfläche. Beim Einrichten einer neuen Regel sind Vorlagen im Vorlagenordner des Projekts vorbereitet, die bereits die gängigen Ausgaben enthalten; die nächsten Schritte zum Einrichten der Regel sind:

  1. Kopieren Sie die Regel in den entsprechenden Ordner und benennen Sie sie in den gewünschten Namen um und fügen Sie Ihren einzigartigen Regelalias hinzu.
  2. Füllen Sie das erforderliche Eingabemodell aus (unsere Standardstruktur ist bereitgestellt, sodass Sie diesen Schritt überspringen können, wenn Sie keine neuen Eingaben hinzufügen).
  3. Definieren Sie die erforderlichen Regelvariablen.
  4. Richten Sie die Logik der Regel in Ihrem gewählten Format ein.
  5. Testen Sie die Regel mit der Testbank-Funktion.
  6. Fügen Sie die Regel der entsprechenden Listentabelle hinzu (zum Beispiel, wenn Sie eine neue Verkaufsprovision erstellen, müssen Sie eine neue Zeile in der Liste der Verkaufsprovisionen hinzufügen und den Regelalias in der Spalte comissionId ausfüllen).

Integration

Wie wir im vorherigen Artikel beschrieben haben, kann die Integration von DecisionRules in Ihre eigene Anwendung über die REST-API erfolgen. Wir werden die Postman-Anwendung verwenden, um zu zeigen, wie ein API-Aufruf erstellt und strukturiert wird.

Vorbereitung

Um den API-Aufruf erfolgreich einzurichten, benötigen wir mehrere Dinge:

  • ID oder Alias der Regel, die Sie bewerten möchten.
  • Ihr Eingabemodell.
  • Solver-API-Schlüssel Ihres DecisionRules-Raums - Der Schlüssel kann gefunden werden, nachdem Sie die Option API-Schlüssel im linken Menü ausgewählt haben.

In unserem Fall möchten wir die Hauptregel Provisionen berechnen aufrufen, für die wir einen Alias zur Vereinfachung eingerichtet haben.

Jetzt, da wir alles haben, was wir brauchen, können wir mit der Erstellung des Aufrufs in Postman beginnen.

Einrichten des API-Aufrufs in Postman

Um eine beliebige Regel, die in DecisionRules erstellt wurde, zu bewerten, verwenden wir die Rule Solver API (wie in der Dokumentation erklärt). Wir werden zwei Möglichkeiten beschreiben, den Aufruf einzurichten. Die erste besteht darin, DecisionRules den Aufruf für Sie erstellen zu lassen, die zweite darin, den Aufruf manuell einzurichten.

Erstellen des Aufrufs mit der Funktion Request Preview

Wenn Sie eine Regel in DecisionRules öffnen, sehen Sie im unteren Menü eine Option namens Request Preview.

Dies öffnet das folgende Fenster, das einen vorbereiteten API-Aufruf enthält, mit mehreren Programmiersprachen zur Auswahl.

In unserem Fall können Sie den cURL-Code kopieren und direkt in einen neuen Aufruf in Postman einfügen. Alles, was Sie ändern müssen, um einen funktionierenden Aufruf zu haben, ist, Ihre Eingabedaten im Body bereitzustellen.

Jetzt schauen wir uns an, was Sie tun müssten, um den Aufruf manuell von Grund auf einzurichten. Diese Anleitung beschreibt, wie Sie alles einrichten, was im Aufruf erstellt wurde, der durch Request Preview erstellt wurde, und ermöglicht eine größere Auswahl an Optionen (zum Beispiel die Verwendung des lesbareren Regelalias anstelle der Regel-ID).

Erstellen des Aufrufs manuell

Der Endpunkt, den wir aufrufen müssen, um eine Regel zu „lösen“, ist

https://api.decisionrules.io/rule/solve/:ruleId/:version

Wir haben den Endpunkt in die Adresszeile kopiert und den Regel-ID-Schlüssel mit unserem Regelalias ausgefüllt. Beachten Sie, dass wir den Parameter :version entfernt haben, da er optional ist und wenn wir nur die neueste Version der Regel bewerten möchten, nicht erforderlich ist.

Jetzt müssen wir die Header einrichten, in denen wir unseren Solver-API-Schlüssel eingeben, der dann als unser „Benutzername und Passwort“ fungiert. Alles, was Sie tun müssen, ist zum Tab Headers zu gehen und einen Schlüssel vom Typ Authentication mit dem Wert „Bearer <Ihr API-Schlüssel hier>“ hinzuzufügen. Es könnte ungefähr so aussehen:

Zu guter Letzt müssen wir einige Eingabedaten für unseren Aufruf bereitstellen, damit wir etwas zu bewerten haben. Dies geschieht im Tab Body, wo Sie die Option „raw“ aktivieren, aus dem Dropdown-Menü „JSON“ auswählen und dann Ihre Eingabedaten in den bereitgestellten Bereich kopieren können.
Bitte beachten Sie, dass Ihre Eingabedaten innerhalb einer vordefinierten Eigenschaft namens „data“ enthalten sein müssen.

Nachdem Sie dies abgeschlossen haben, sollte die Seite so aussehen:

Jetzt sind Sie bereit, Ihre Regeln mit API-Aufrufen zu bewerten!

Postman zeigt die Ausgabe Ihres Aufrufs in einem Fenster unter Ihrem Aufrufkörper an.

Jeder Aufruf der DecisionRules-API gibt seine Antwort in Form eines Arrays zurück. Selbst wenn Sie nur ein Objekt zur Bewertung senden, wird die Antwort in Form eines Arrays mit einem Eintrag zurückgegeben, wie Sie unten sehen können:

Wenn Sie experimentieren oder mehr über die Optionen erfahren möchten, die die API Ihnen bietet, konsultieren Sie bitte die Dokumentation.

Berichterstattung in PowerBI

Lassen Sie uns ansehen, wie man die Audit-Protokolle von DecisionRules in Power BI verarbeitet, um die Daten für die Kommissions-Dashboards vorzubereiten.

Hinweis: Bitte stellen Sie sicher, dass Sie die Audit-Protokolle aktiviert und für Ihre Regel Kommissionen berechnen eingeschaltet haben. Wie Sie dies einrichten, wird hier beschrieben: https://docs.decisionrules.io/doc/business-intelligence/audit-logs

Audit-Protokolle können über die Business Intelligence API abgerufen werden; diese API verwendet einen anderen API-Schlüssel als den, den wir zur Bewertung der Regeln in Postman verwendet haben. Sie finden diesen Schlüssel im selben Menü für API-Schlüssel unter Business Intelligence API Key (wenn Sie keine Schlüssel sehen, können Sie einige mit der Schaltfläche Business Intelligence API-Schlüssel hinzufügen hinzufügen).

Darüber hinaus benötigen Sie die Regel-ID Ihrer Regel Kommissionen berechnen (wenn die Regel-ID nicht verwendet wird, funktioniert das Alias nicht!).

Beim Laden der Daten über die Business Intelligence API greifen wir in mehreren Schritten auf die Audit-Protokolle zu, indem wir jeweils eine Seite mit einer begrenzten Anzahl von Protokollen laden. Wir müssen diesen Ansatz wählen, um den Server nicht zu überlasten, wenn wir eine große Anzahl von Protokollen auf einmal laden müssen.

Jetzt können wir PowerBI öffnen und eine Abfrage erstellen, um die Daten zu importieren. Nachdem Sie ein neues Projekt geöffnet haben, sollten Sie im Dropdown-Menü Daten abrufen die Option „Leere Abfrage“ auswählen (dies öffnet den PowerQuery-Editor).

Sie müssen zwei Parameter mit der Option Parameter verwalten im Menüband Start erstellen, um diese Parameter BI_API_KEY und RULE_ID zu benennen und ihre aktuellen Werte auf die Werte des API-Schlüssels und der Regel-ID, die Sie von DecisionRules erhalten haben, festzulegen.

PowerBi-Abfrage

Unsere PowerBI-Abfrage kann in die folgenden 5 Teile unterteilt werden:

Teil 1

Zunächst fragen wir die Business Intelligence API von DecisionRules ab und extrahieren einen Parameter matchedCount aus dem Aufruf (der Aufruf selbst verwendet eine limit=1-Einstellung, da wir noch keine Daten benötigen). Dieser Parameter sagt uns, wie viele Protokolle wir laden müssen; wir speichern ihn in der Variablen iterations.

Teil 2

Hier bereiten wir eine Funktion vor, die eine Seite von Protokollen liest.

Teil 3

Jetzt haben wir eine Schleife, die die Funktion für alle Seiten von Protokollen aufruft (die die Anzahl der zu ladenden Protokolle enthalten), und für jede Iteration rufen wir die Funktion FnGetOnePage aus dem vorherigen Teil auf und verbinden alle Protokolle zu einer einzigen Tabelle.

Teile 4 & 5

In diesen letzten Teilen transformieren wir die Daten aus dem Format der Audit-Protokolle, das möglicherweise viele Daten enthält, die Sie in diesem Moment nicht nützlich finden, in eine Tabelle mit nur den Ausgabedaten, die uns wichtig sind. Teil 4 kümmert sich darum, die Ausgabedaten der Regel aus dem Protokoll zu erhalten und sollte gleich bleiben, selbst wenn Sie die Ausgabestruktur ändern. Wenn Sie dies jedoch tun möchten, müssen Sie den Code im letzten Teil ändern, da wir es mit Spaltennamen zu tun haben, die wir aus der DecisionRules-Ausgabe erhalten, und wenn Sie etwas hinzufügen oder entfernen, müssen diese Namen geändert/angepasst werden.

Sie können den vollständigen Code unten sehen; bitte kopieren Sie ihn und fügen Sie ihn in Ihre PowerBI-Abfrage ein.

Jetzt können Sie die Funktion aufrufen, und Sie sollten alle Ausgabedaten aus Ihren Audit-Protokollen in PowerBI verfügbar haben, und Sie können mit der Einrichtung Ihrer Berichte beginnen.

Natürlich können Sie die Berichte gemäß Ihren eigenen Bedürfnissen und Spezifikationen erstellen, aber für die Zwecke dieser Präsentation haben wir ein einfaches Dashboard eingerichtet, wie hier zu sehen ist:

Fazit

In diesem Artikel haben wir gezeigt, wie man ein Provisionsmodell im PowerBI-Tool einrichtet. Die Regeln sind so gestaltet, dass sie einfach sind, um die Logik zu veranschaulichen und eine Richtung vorzugeben. Provisionslogik kann komplex sein, und dies ist nur der erste Schritt.

Wenn Sie mehr über die Möglichkeiten von DecisionRules erfahren möchten, finden Sie die Dokumentation hier für Sie. Tauchen Sie mit Vertrauen ein und erkunden Sie weiter.

Ondrej Brejla

Ondrej Brejla

Business Analyst