HTTP POST-Anfragen
HTTP POST-Anfragen bieten eine vielseitige Methode zur Integration von DecisionRules mit externen Systemen. Dieser Ansatz ermöglicht es jeder Anwendung, die in der Lage ist, HTTP-Anfragen zu empfangen, mit DecisionRules zu interagieren. Durch das Senden einer strukturierten JSON-Nutzlast aus einer Regel heraus können Benutzer die Ausgaben von DecisionRules direkt in ihren anderen Systemen verwenden. Es kann jedoch auch verwendet werden, um DecisionRules-Löseraufrufe zu tätigen, wenn es richtig konfiguriert ist. Ein solcher Aufruf erfolgt über das öffentliche Internet und zurück zu DecisionRules zur Lösung.
SOLVE-Funktion
Die SOLVE-Funktion wurde speziell für die Verwendung innerhalb von DecisionRules-Regeln entwickelt. Sie ist besonders nützlich für die Erstellung komplexer Regelorchestrierungen in Anwendungsfällen, in denen der Regelfluss möglicherweise nicht ausreicht. Sie ruft intern einen anderen DecisionRules-Server über das Backbone auf, um die angegebene Regel zu lösen. Die Funktion ermöglicht die dynamische Aufrufung anderer Regeln, wobei nur die Zielregel-ID (oder Alias), die Eingabedaten und ein optionales Optionsobjekt verwendet werden.
Vergleich der Ansätze: Unterschiede, Gemeinsamkeiten und Anwendungsfälle
Sowohl die SOLVE-Funktion als auch HTTP POST-Anfragen lösen letztendlich die Zielregel und geben die Ergebnisse an die aufrufende Regel zurück. Es gibt jedoch mehrere wichtige Unterschiede, die berücksichtigt werden sollten:
Wie oben dargestellt, ist die Verwendung der SOLVE()-Methode sehr einfach, während es mühsam sein kann, die HTTP_POST()-Methode syntaktisch korrekt zu gestalten. Im Gegensatz zur SOLVE()-Methode ermöglicht die HTTP_POST()-Methode jedoch, Regeln in anderen Spaces als der aufrufenden Regel aufzurufen, da wir den Aufruf explizit mit Headern versehen, die den Solver-API-Schlüssel des Ziel-Space enthalten. Beachten Sie, dass dies ein Sicherheitsrisiko darstellen kann, da Sie möglicherweise nicht möchten, dass Ihre API-Schlüssel für jeden zugänglich sind, der Zugriff auf Ihre Regeln hat.
Ein weiterer wesentlicher Unterschied besteht darin, dass Aufrufe, die mit dem SOLVE()-Ansatz getätigt werden, nur als ein API-Aufruf zählen, da sie als „interner“ Aufruf betrachtet werden, während der HTTP_POST()-Aufruf als „extern“ zählt und somit zu zwei API-Aufrufen führt. Dies ist besonders wichtig, wenn Sie sich Sorgen machen, Ihr monatliches API-Aufruflimit zu überschreiten.
Zum Thema interne und externe Aufrufe: Wenn Ihre Regel eine Audit-Protokoll für eine über die SOLVE()-Methode aufgerufene Regel generiert, wird die correlationId des genannten Audit-Protokolls die gleiche sein wie die der aufrufenden Regel. Dies ist bei der HTTP_POST()-Methode nicht der Fall.
Darüber hinaus bietet die SOLVE-Funktion eine praktische Pfadoption, die es Benutzern ermöglicht, einen JSON-Pfad anzugeben, um direkt einen bestimmten Teil der Ausgabedaten abzurufen. Dies kann den Prozess vereinfachen, wenn nur eine Teilmenge der Ausgaben der Regel benötigt wird, wodurch die SOLVE-Funktion noch effizienter und auf spezifische Bedürfnisse zugeschnitten wird.
Fazit
In fast allen Fällen ist die Verwendung der integrierten SOLVE()-Methode der HTTP_POST()-Methode vorzuziehen. Es sei denn, Sie rufen Regeln in anderen Spaces oder Umgebungen (für On-Premise-Lösungen) auf, sollten Sie bei dem einfacheren und integrierteren Ansatz der SOLVE()-Funktion bleiben.
David Janata
Fullstack-Entwickler