Frequently Asked Questions

Ja, DecisionRules versioniert nativ einzelne Regeln.

Ja, zu unseren Kunden gehören multinationale Unternehmen, Finanzinstitute und Versicherungsunternehmen, die zu den komplexesten Organisationen der Welt zählen. Wir können auch Ihr Unternehmen betreuen.

Änderungen, die in Organisationen Tage oder Wochen in Anspruch nehmen, können in DecisionRules in wenigen Minuten vorgenommen werden. Es funktioniert wirklich.

DecisionRules spart Ihnen Geld, indem es die Notwendigkeit beseitigt, dass Entwickler die Geschäftslogik bei jeder Änderung der Geschäftsregeln anpassen müssen. Alle Regeländerungen können von einem erfahrenen Produktverantwortlichen oder einem Junior-Analysten vorgenommen werden.

Ja, DecisionRules enthält einen KI-Assistenten, der Ihnen hilft, alle erforderlichen Regeln zu erstellen. Zum Beispiel können Sie eine interne Richtlinie nehmen, die Sie in eine Entscheidungstabelle umwandeln müssen, und DecisionRules wird die Tabelle automatisch basierend auf der Richtlinie erstellen.

Die meisten CRM-zu-ERP-Integrationen erfordern benutzerdefinierte Workflows, Middleware oder Punkt-zu-Punkt-Verbindungen, die schnell schwer zu warten sind. Mit DecisionRules wird die Integration viel einfacher: Beide Systeme senden Daten an eine einzige Entscheidungs-API, und DecisionRules liefert in Echtzeit konsistente Preise, Validierungen oder Genehmigungsergebnisse zurück.

Anstatt die Logik zwischen ERP und CRM zu synchronisieren, zentralisieren Sie sie einmal — und beide Systeme verwenden die gleichen Ergebnisse.

Workflow-Automatisierung in CRM-Systemen ersetzt manuelle Schritte – wie Genehmigungen, Datenprüfungen oder Preiskalkulationen – durch automatisierte Regeln. Das Problem ist, dass native CRM-Automatisierungstools mit komplexer Logik kämpfen und schnell schwer zu verwalten werden.

DecisionRules entlastet diese Komplexität. Sie entwerfen die Logik einmal in einer zentralen Entscheidungsmaschine, und Ihr CRM ruft sie auf, wann immer es Preisgestaltung, Validierung, Genehmigung von Rabatten oder Routing-Entscheidungen benötigt.

Native CRM-Regel-Builder (wie Salesforce oder Dynamics) funktionieren für einfache Regeln, werden jedoch einschränkend, wenn die Logik mehrere Systeme umfasst oder Versionierung, Simulationen oder erweiterte Bedingungen erfordert.

Mit DecisionRules definieren Sie Geschäftsregeln in einer zentralen, visuellen Oberfläche und rufen sie über eine leichte API aus Ihrem CRM auf. Dies hält die Logik aus CRM-Workflows heraus, erleichtert Aktualisierungen und sorgt für konsistente Entscheidungen in Vertrieb, Finanzen, CPQ und ERP.

ERPs sind berüchtigt für kryptische „Ungültiger Eintrag“-Nachrichten, die Benutzer im Stich lassen. Automatisierte Validierungen verbessern ERP-Workflows, indem sie Daten intelligenter bewerten, hilfreiche Anleitungen geben und Fehler verhindern, bevor sie zu Verzögerungen führen.

Mit DecisionRules können Sie ERP-Validierungsregeln in eine klare, wartbare Engine auslagern, die benutzerfreundliche Nachrichten und Korrekturschritte zurückgibt. Das Ergebnis sind weniger Benutzerfehler, weniger Support-Tickets und zuverlässigere ERP-Daten.

Der einzige zuverlässige Weg, um die Preisgestaltung zwischen CRM und ERP zu vereinheitlichen, besteht darin, die Preisregeln in einem System zu zentralisieren und beiden Plattformen zu ermöglichen, diese in Echtzeit abzurufen. Andernfalls endet man mit duplizierten Formeln, inkonsistenten Rabatten und manuellen Übersteuerungen.

DecisionRules löst dies, indem es Ihre einzige Preislogik-Engine wird. Ihr CRM sendet die Angebotsanfrage, Ihr ERP sendet die Produktdaten, und DecisionRules gibt sofort den korrekten Preis, Rabatt oder die Genehmigung zurück – und sorgt so überall für Konsistenz.

Workflow-Automatisierung entfernt repetitive Aufgaben wie Genehmigungen, Datenprüfungen, Gebietszuteilungen oder Rabattvalidierungen. Dies reduziert manuelle Arbeit und hilft Teams, schneller zu reagieren.

Durch die Verwendung von DecisionRules als Logikschicht hinter Ihren CRM-Workflows automatisieren Sie komplexe Entscheidungen, die native CRM-Tools nicht bewältigen können. Das bedeutet schnellere Reaktionszeiten, weniger Fehler und mehr Zeit für den tatsächlichen Verkauf anstelle von administrativen Aufgaben.

Nein. Während der Referenzfall aus der Fahrzeugfinanzierung stammt, konzentriert sich das Whitepaper auf Entscheidungsmanagementmuster, die in den Finanzdienstleistungen Anwendung finden, einschließlich persönlicher Kredite, Kreditvergabe und Inkasso. Die beschriebenen Prinzipien können in jeder Umgebung wiederverwendet werden, in der sich die Entscheidungslogik häufig ändern muss.

Das Whitepaper bietet einen praktischen Überblick über die Einrichtung der Entscheidungsmaschine, das Governance-Modell und den Implementierungsansatz. Es richtet sich an Geschäfts-, Risiko- und IT-Interessengruppen und konzentriert sich darauf, wie die Lösung in der Praxis funktioniert, anstatt auf Theorie oder Produktmarketing.

DecisionRules eignet sich sowohl für mittelständische als auch für große Unternehmen. Wenn Sie Probleme mit Änderungen an Konfigurationen, Geschäftslogik oder Entscheidungsprozessen haben, dann ist DecisionRules das richtige System für Sie.

Der Anwendungsfall konzentriert sich auf Organisationen, in denen Underwriting- oder Entscheidungsregeln in den Kernsystemen fest codiert sind, was Änderungen langsam und von Entwicklungszyklen abhängig macht. Er zeigt, wie die Trennung der Entscheidungslogik in eine dedizierte Entscheidungs-Engine schnellere Updates, klarere Zuständigkeiten und eine bessere Zusammenarbeit zwischen Fachabteilungen und IT ermöglicht.

Nein. Während das Beispiel auf der Risikoprüfung basiert, gilt derselbe Ansatz auch für andere entscheidungsintensive Prozesse wie Kreditbewertung, Preisgestaltung, Berechtigungsprüfungen und Inkasso. Der Anwendungsfall zeigt ein wiederverwendbares Entscheidungsmanagementmuster und nicht eine einzelne isolierte Lösung.

Ein Space ist ein gemeinsamer Bereich für Regeln, die irgendwie miteinander verbunden sind. Es ist ein unabhängiges Projekt innerhalb von DecisionRules, das es Ihnen ermöglicht, die Logik für verschiedene Abteilungen oder Teams in Ihrem Unternehmen zu trennen.

Dies ist die grundlegende Einheit, um die DecisionRules aufgebaut ist: die Anzahl der Geschäftsregeln, die Sie erstellen können.

Im Falle von Knoten bezieht es sich auf die Anzahl der Knoten, die Sie in einem Entscheidungsfluss oder einem Integrationsfluss platzieren können.

Die Gesamtzahl der verwendeten Regeln und Knoten darf das von Ihrem Plan festgelegte Limit nicht überschreiten.

Der einfachste Weg ist, auf einen höheren Plan umzusteigen. Die Änderung tritt sofort in Kraft.

Eine weitere Möglichkeit ist ein maßgeschneidertes Angebot, das auf Ihre spezifischen Bedürfnisse zugeschnitten ist. Wir würden Ihnen gerne ein individuelles Angebot unterbreiten.

Die Management-API dient einfach der automatisierten Modifikation direkt innerhalb von DecisionRules. Sie können sie verwenden, um Daten über DecisionRules-Objekte in Ihr System zu laden, wie z. B. Regelnamen, verfügbare Versionen usw.

Darüber hinaus wird die Management-API für automatisierte Importe/Exporte, Backups oder die Integration in CI/CD-Pipelines verwendet.

Der Zugriff auf die Management-API erfolgt über einen API-Schlüssel, der direkt in der Anwendung erhalten werden kann.

Entscheidungstabellen, Entscheidungsgrafen, Skriptregeln und der Regeltyp für den KI-Agenten, die zu Entscheidungsabläufen zusammengesetzt sind.

Eine zustandslose, deterministische Plattform zur Automatisierung von Entscheidungen. Sie führt Ihre Geschäftsregeln über eine REST-API aus, ist versioniert und nachvollziehbar, sodass dieselbe Eingabe immer zur selben Entscheidung führt.

DecisionRules lagert die Entscheidungslogik in visuelle Regeltabellen aus. Dadurch können Fachexperten Regeln direkt pflegen, während sich Entwickler auf die Kerninfrastruktur konzentrieren.

Die Integration mit DecisionRules entfernt fest codierte Geschäftslogik aus dem Anwendungscode, beseitigt Bereitstellungsengpässe und ermöglicht es Fachexperten, Regeln ohne vollständige Entwicklungszyklen zu aktualisieren.

Sie wurden für DevOps-Teams entwickelt, die DecisionRules auf Kubernetes betreiben und schnellere Bereitstellungen, eine einfachere Konfigurationsverwaltung sowie unkomplizierte Upgrades wünschen.

Offizielle Helm Charts bündeln DecisionRules und seine Abhängigkeiten in einer einzigen verwaltbaren Bereitstellung für Kubernetes-Umgebungen und folgen dabei branchenüblichen Best Practices.

Ja. Alle Konfigurationsoptionen werden über eine values.yaml-Datei verwaltet. Damit haben Sie vollständige Kontrolle über Ressourcen, Skalierung und Umgebungseinstellungen.

Ja, DecisionRules hat öffentlich verfügbare Docker-Container, die jeder herunterladen kann. Es wird empfohlen, ein vorgefertigtes Docker-Compose-Skript zu verwenden, das alles direkt auf Ihrem Computer herunterlädt, installiert und ausführt. Sie müssen lediglich Docker Desktop installiert haben, das kostenlos erhältlich ist.

Ja, DecisionRules ist so konzipiert, dass es skalierbar ist. Die Skalierung kann automatisch basierend auf mehreren Parametern eingestellt werden, wie z.B. CPU-Auslastung, Anzahl der eingehenden Verbindungen und mehr. Sie können problemlos eine Umgebung haben, die zig Millionen Entscheidungen pro Stunde treffen kann.

Ja, DecisionRules verwendet Redis Cache, der allgemein verfügbar ist. Der Cache wird als nicht persistent verwendet. Um die Verfügbarkeit zu erhöhen, ist es möglich, ein Redis-Cluster zu verwenden.

Sie können aus mehr als 30 Amazon Web Services-Standorten wählen, an denen Ihre Umgebung verfügbar sein wird.

DecisionRules unterstützt eine Vielzahl von privaten Clouds, wie AWS, Azure oder Google Cloud. Wenn Sie Ihren eigenen Kubernetes-Cluster verwenden, wird DecisionRules perfekt für Sie funktionieren.

Unser durchschnittlicher Kunde kann DecisionRules innerhalb weniger Stunden problemlos in sein System integrieren.

Dieser Prozess dauert ungefähr 5 Tage ab Vertragsunterzeichnung.

Ja, es verwendet standardmäßig mehrere Verfügbarkeitszonen an einzelnen Standorten. Dank der einzigartigen Architektur von DecisionRules ist es möglich, mehrere Standorte auszuwählen, die basierend auf der geografischen Position des Benutzers automatisch ausgewählt werden.

Sie können aus mehr als 30 Amazon Web Services-Standorten wählen, an denen Ihre Umgebung verfügbar sein wird.

DecisionRules verwendet MongoDB oder dessen Klone wie CosmosDB oder DocumentDB zur Datenspeicherung. Es ist auch möglich, Mongo Atlas oder Ihren eigenen Cluster problemlos zu verwenden. Die Verwendung von verwaltetem MongoDB ist vorteilhaft für die Datenbanksicherung, die mit einem Klick durchgeführt werden kann.

DecisionRules bietet 3 Optionen an:

Ja. DecisionRules ist so konzipiert, dass es in Unternehmensgröße betrieben werden kann, mit99,99% Verfügbarkeitund KundenverarbeitungHunderte Millionen Entscheidungen pro Tag. Es unterstützt auch hochgradige Arbeitslasten, einschließlichZehntausende von gelösten Regeln pro Stunde für einen einzelnen Kunden, und es skaliert automatisch bei höherer Last.

Es wird bereits in großen Organisationen eingesetzt, darunter Accenture, Boohoo Group, Wizz Air und mehr. Wenn Sie konkrete Beispiele möchten, hier sind einige reale Implementierungen:

Private Managed Cloud ist für mittelständische und große Unternehmen konzipiert, die DecisionRules als Dienstleistung unter einem vorher vereinbarten SLA nutzen möchten und über eine eigene dedizierte Infrastruktur verfügen, die nicht mit anderen geteilt wird.

Ja, das können Sie. Viele Kunden wählen diesen Ansatz, indem sie einfach mit der Cloud-Variante beginnen und dann zu einer Private Managed Cloud oder On-Premise-Lösung migrieren. Das Projekt kann einfach in die neue Umgebung exportiert und importiert werden. Es dauert etwa 1 Minute Ihrer Zeit.

Dies ermöglicht es den Kunden, Regeln zu erstellen und Systeme sofort zu integrieren.

Public Cloud, Private Managed Cloud oder selbst gehostet über Docker und Kubernetes, einschließlich On-Premises.

Ja, wir bieten unseren Kunden globalen Support in den Modi 5x8, 24x7 oder zu individuellen Zeiten an. Sie können den Support ganz einfach über unsere kontaktierenSupport-Portal.

Sie können die Implementierung problemlos selbst durchführen. Wenn Ihnen die Kapazität im Team fehlt, können wir die erste Iteration der Regeln für Sie übernehmen oder sie langfristig für Sie verwalten.

Natürlich wird Ihnen unser erfahrenes DevOps-Team helfen, DecisionRules in Ihrer privaten Cloud zu installieren und zu testen. Wir haben unzählige Installationen durchgeführt.

Nein. Aktivieren Sie die Protokollierung für eine Regel, und Statistics liest die dabei erzeugten Protokolle. Das Data Dictionary erkennt Ihre Felder aus den Protokolldaten selbst. Es gibt also kein Schema, das Sie deklarieren müssten, und nichts, das synchron gehalten werden muss.

Ja. Die BI API ist schreibgeschützt, und es gibt einen nativen Power-BI-Connector. Ihr BI-Tool liest dieselben Audit-Protokolle wie die Statistics-Seite. Damit gibt es eine zentrale Datenquelle und keine Kopien, die auseinanderlaufen können.

DecisionRules ist ein sicheres System. Alle Verbindungen sind verschlüsselt, und Ihre Daten sind ebenfalls durch Verschlüsselung geschützt.

Die Entscheidungsregeln und unsere Prozesse entsprechen der ISO 270001-Zertifizierung.

Die DecisionRules und unsere Prozesse entsprechen der ISO 270001-Zertifizierung.

Nein. Ihre Regeln und Daten werden niemals zum Trainieren von KI-Modellen verwendet.

Der Zugriff ist auf den ausgewählten Space beschränkt, jede Änderung wird versioniert und kann rückgängig gemacht werden, und ohne Ihre Freigabe wird nichts veröffentlicht.

Ja, wir bieten auch Offline-Lizenzen an.

Die On-Premise-Bereitstellung ist immer eine individuelle Angelegenheit, bei der Sie die Anzahl der Umgebungen, Organisationen, Funktionen und Benutzer festlegen können, die Sie in Ihren DecisionRules verfügbar haben möchten. Unsere Vertriebsingenieure helfen Ihnen gerne, Ihren Anwendungsfall durchzugehen und eine maßgeschneiderte Lösung für Sie zu erstellen. Eine unbegrenzte DecisionRules-Lizenz ist ebenfalls verfügbar.

Ja, DecisionRules verfügt über eine öffentlich zugängliche Akademie, die Sie Schritt für Schritt anleitet, wie Sie DecisionRules verwenden. Wir bieten auch Online- und Offline-Schulungen für Kunden an.

Interessiert an Schulungen? Kontaktieren Sie uns.

Ja, DecisionRules verfügt über umfangreiche öffentlich zugängliche Dokumentationen, die wir jede Woche erweitern und verfeinern. Die Dokumentation ist verfügbar unterdocs.decisionrules.io.

Nein. Jeder mit Excel-Kenntnissen kann DecisionRules verwenden.

Alle Regeln und Entscheidungsprozesse können exportiert und importiert werden. Dank der integrierten Ordnerstruktur innerhalb jedes Raums ist es möglich, einzelne Ordner oder gesamte Projekte zu exportieren.

Das Exportformat ist JSON.

DecisionRules kann standardmäßig 30.000 Datensätze in einer einzelnen Tabelle verarbeiten. Dieses Limit ist für die meisten Kunden ausreichend. Wenn Sie mehr benötigen, kann dieses Limit individuell erhöht werden.

DecisionRules funktioniert mit Entscheidungstabellen, Entscheidungsbäumen, Entscheidungsflüssen und Integrationsflüssen. Diese Regeln sind immer codefrei und benutzerfreundlich.

Wenn eine komplexere Datenumwandlung erforderlich ist, können Sie eine Skriptregel verwenden, in der Sie JavaScript anwenden können.

Ja, das werden sie. Alle interessierten Parteien können jederzeit in DecisionRules nachsehen, wie ein spezifischer Fall bewertet wird. Für eine umfassendere Überwachung können Sie DecisionRules problemlos mit PowerBI verbinden und individuelle Entscheidungen statistisch anzeigen.

Der Integrationsfluss ist eine Möglichkeit, einen Entscheidungsprozess zu erstellen, der mit Datenquellen integriert werden kann. Zum Beispiel ermöglicht es Ihnen, 1 Million Ihrer Kunden, die in einem CRM oder einer Datenbank gespeichert sind, im Batch zu verarbeiten.

Für solche Entscheidungsprozesse schätzen wir eine Dauer von mehreren Sekunden bis zu Stunden.

Decision Flow ist eine Funktion innerhalb von DecisionRules, die es Ihnen ermöglicht, komplexere Entscheidungsprozesse zu erstellen, die aus mehreren kleineren Entscheidungen, Berechnungen oder externen Aufrufen bestehen.

Der Entscheidungsfluss ermöglicht es Ihnen, mehrere Entscheidungstabellen zu kombinieren, einzelne Entscheidungen zu iterieren oder Daten zu aggregieren.

Für solche Entscheidungen schätzen wir, dass sie Millisekunden bis Sekunden dauern.

Ja, wenn Sie mit großen Tabellen arbeiten, können Sie diese mit einem einzigen Klick nach Excel oder Google Sheets exportieren, wo Sie sie bearbeiten und dann problemlos wieder importieren können.

Wenn während des Imports ein Fehler auftritt, zeigt DecisionRules interaktiv an, welche Zelle korrigiert werden muss.

Ja, DecisionRules ermöglicht die Verarbeitung von Batchdaten mithilfe von Jobs, die mehrere Stunden laufen können. Alternativ kann DecisionRules als Teil von Rechenprozessen verwendet werden, die auf anderen Plattformen orchestriert werden.

DecisionRules ist als ein robustes und leistungsstarkes System konzipiert. Unsere Infrastruktur kann mühelos Zehntausende von gelösten Regeln pro Stunde für einen einzelnen Kunden verarbeiten. Die Plattform skaliert automatisch bei höherer Last.

Dies ist die Grenze, wie viele Regeln Sie innerhalb Ihres Plans lösen können – oder, wie oft Sie die Solver-API erfolgreich aufrufen können.

DecisionRules können Hunderttausende von Regeln pro Minute auswerten. Das Ergebnis kann je nach individuellen Bereitstellungen variieren. Private Managed Cloud- oder On-Premise-Bereitstellungen bieten die beste Leistung, da die Infrastruktur nicht mit anderen Benutzern geteilt wird.

Einfache Regeln haben eine sehr niedrige Latenz von etwa 20 ms. Komplexere Regeln können eine Latenz von etwa 250 ms aufweisen, und wirklich komplexe Entscheidungsprozesse mit Dutzenden von Entscheidungstabellen und externen Aufrufen können Latenzen von mehreren Sekunden haben.

DecisionRules ist das einzige Tool auf dem Markt, das mehrere Rechenzentren weltweit nutzen kann. Dies gewährleistet hervorragende Reaktionszeiten, egal auf welchem Kontinent Sie sich befinden. Wenn Sie feststellen, dass DecisionRules in einer bestimmten Region fehlt, lassen Sie es uns bitte wissen. Wir sind offen für den Ausbau unserer Infrastruktur.

Um zu sehen, was eine neue Version tun würde, bevor sie es tut. Die aktuelle Version bedient weiterhin die Produktion, während die Kandidatin auf denselben Anwendungen läuft und protokolliert, was sie entschieden hätte, ohne danach zu handeln. Rufen Sie die Regel dafür zweimal auf – jeweils an eine Version gebunden – und senden Sie beiden dieselbe Eingabe. Das Ergebnis der Kandidatin wird protokolliert, nicht verwendet. Wenn sie sich wie erwartet verhält, führen Sie sie in die Produktion über.

Sie bleibt bestehen. Durch die Bearbeitung entsteht eine neue Version, statt die vorherige zu überschreiben, und die alte Version behält ihre eigenen Audit-Protokolle. So können Sie sie vergleichen und Fragen zu einer Entscheidung beantworten, die unter einer inzwischen ersetzten Richtlinie getroffen wurde.

Beides. Die Vergleichsauswahl akzeptiert jede Regel. Einzige Voraussetzung ist, dass das betrachtete Feld auf beiden Seiten vorhanden ist, denn ein Diagramm braucht etwas zum Zeichnen. Der Vergleich von Versionen derselben Regel ist der sauberste Fall, weil alles andere konstant bleibt.

Ja, DecisionRules wird häufig mit verschiedenen Integrationsplattformen wie Power Automate, SAP Platform, n8n, Workato und anderen verwendet. Die Integration ist sehr unkompliziert.

DecisionRules können über eine einfache Solver REST API integriert werden. Sie fügen einfach ein JSON-Objekt als Eingabedaten ein und erhalten die Ausgabe der Regel in der Antwort. Integrationsbeispiele für einzelne Sprachen und Plattformen finden Sie direkt in der Anwendung.

Ja, wir haben eine Vielzahl von SDKs auf unsererDecisionRules Github.

Über die native MCP-Integration können KI-Tools auf vordefinierte Vorlagen, wiederverwendbare Komponenten, Dokumentationen, Academy-Ressourcen und strukturierten Content zugreifen. Außerdem können sie in einem authentifizierten Bereich Regeln erstellen, aktualisieren, testen und ausführen – wobei jede Änderung geprüft wird, bevor sie live geht.

Nein. Sie verbinden ihn mit Ihrem bestehenden DecisionRules-Konto und wählen während der Einrichtung den Space aus, in dem der Assistent arbeiten soll.

Claude, ChatGPT, Codex unterstützen native Konnektoren. Alle anderen MCP-kompatiblen Clients können sich über Smithery verbinden.

Die Organisation ermöglicht eine zentrale Verwaltung von Projekten und Benutzern innerhalb Ihrer Organisation. Sie können Teams und Berechtigungsgruppen für einzelne Projekte definieren. Die Organisation ermöglicht die Anmeldung über SAML Single Sign-On, wie Microsoft Entra ID, Okta, 0Auth usw. Diese Funktion ist besonders nützlich für größere Unternehmen mit komplexeren Organisationsstrukturen.

Weil sich die Versionen nicht immer überschneiden. Wenn Sie zwei Versionen parallel ausführen, möchten Sie auf beiden Seiten dasselbe Zeitfenster. Nach der Umstellung liegt die alte Version in den Wochen davor und die neue in den Wochen danach. Deshalb braucht jede Seite ihr eigenes Zeitfenster, damit es überhaupt etwas darzustellen gibt.

Ein nativer Regeltyp, der Dokumente, Narrative und Signale liest und strukturierten, typisierten Output mit nachvollziehbarer Begründung zurückgibt. Er unterscheidet sich vom KI-Assistant.

Nein. Er erstellt und bearbeitet sowohl Entscheidungstabellen als auch Scripting-Regeln, generiert Funktionen und Testdaten, fasst Regeln zusammen, empfiehlt Vorlagen und beantwortet Fragen aus den Dokumenten und der Academy.

Etwa 60 % weniger Zeit beim Verfassen und bis zu 3-mal mehr tägliche Produktivität – gemessen in einem kontrollierten Benchmark.

Ja, sowohl für den KI-Assistenten als auch den KI-Agenten: Gemini, OpenAI, Anthropic, Vertex AI oder Microsoft Foundry.

DecisionRules nutzt KI, um Nutzern dabei zu helfen, Business Rules zu erstellen und zu pflegen. Der KI-Assistent kann natürliche Sprache in Decision Tables umwandeln, Funktionen und Testdaten generieren, bestehende Business-Logik erläutern, komplexe Regeln zusammenfassen und mithilfe der DecisionRules-Dokumentation Produktfragen beantworten. Sobald sie erstellt wurden, werden Business Rules von der DecisionRules-Engine ausgeführt, wobei sie versioniert, revisionssicher und deterministisch bleiben – sodass immer die gleiche Eingabe auch zur gleichen Entscheidung führt.

Rule Comparison zeigt zwei Regeln nebeneinander und markiert jeden Unterschied farblich. So beantwortet es schnell eine Frage: Was hat sich tatsächlich geändert? Besonders nützlich ist der Vergleich zweier Versionen derselben Regel, etwa der Live-Version mit einer neuen Version in Vorbereitung.

Grün steht für Ihre aktuell geöffnete Regel. Blau steht für die Vergleichsversion. Gelb bedeutet, dass eine Zeile, Spalte oder Zelle in beiden Versionen vorhanden ist, sich aber geändert hat. Ungefärbte Inhalte sind identisch. Das Prinzip ist bei Tabellen und Bäumen gleich.

Sie liefern eine schnelle Übersicht der Unterschiede, getrennt nach Zeilen und Spalten. Für beides sehen Sie, wie viel gleich geblieben ist und wie viel sich geändert hat, aufgeschlüsselt nach Farben.

Nur Regeln desselben Typs: Tabellen mit Tabellen, Bäume mit Bäumen und Scripts mit Scripts. So bleibt der Vergleich sinnvoll, denn ein Raster und eine Code-Datei lassen sich nicht miteinander abgleichen.

Beim Vergleich zweier Versionen derselben Regel. Auch nicht verwandte Regeln lassen sich vergleichen, aber dann erscheint fast alles als unterschiedlich – daher ist das selten hilfreich.

Machen Sie Rule Comparison zum letzten Schritt Ihrer Prüfung. Öffnen Sie die neue Version neben der aktuellen Live-Version, gehen Sie jeden Unterschied durch, prüfen Sie die Statistik für einen schnellen Überblick und bestätigen Sie, dass jede Änderung beabsichtigt ist. Aus „Ich glaube, das stimmt“ wird „Ich sehe genau, was ich geändert habe.“

Erstellen Sie Teams und Departments, die der Arbeitsweise Ihres Unternehmens entsprechen. Vertraute Strukturen vereinfachen das Onboarding und die Administration und erleichtern die Skalierung Ihrer Organisation.

Konfigurieren Sie Branding, Authentifizierung und Einstellungen des KI-Anbieters auf Organisationsebene, um ein einheitliches Erlebnis in allen Spaces zu gewährleisten und den Administrationsaufwand zu reduzieren.

Nein. Die Migration ist eine Übersetzung, keine Neuerstellung. Die fachliche Absicht hinter jeder Regel bleibt unverändert; nur die zugrunde liegenden Artefakte ändern ihre Form. Die meisten Regeltypen werden eins zu eins abgebildet: Eine Entscheidungstabelle wird zu einer Entscheidungstabelle, ein Entscheidungsbaum zu einem Entscheidungsbaum.

Ja. In ODM stellen selbst flüssig lesbare BAL-Regeln nur das Vokabular bereit, das Entwickler zuvor vorbereitet haben. In DecisionRules können Fachanwender ein Feld selbst hinzufügen. Für die meisten alltäglichen Änderungen ist kein Entwickler mehr nötig.

Sobald Sie eine Regel bearbeiten und veröffentlichen, ist die Änderung sofort live. Sie brauchen keinen separaten Deployment-Schritt und keinen Entwickler, der sie ausrollt; sofern Ihr Prozess es verlangt, kann dennoch eine zusätzliche Prüfung erfolgen.

Ja. DecisionRules führt Event Logs, die festhalten, wer eine Änderung vorgenommen hat und wann. So können Sie die Historie einer Regel jederzeit nachvollziehen.

Ja. Testfälle aus Decision Validation Services werden zusammen mit den Regeln übersetzt und gegen die neuen DecisionRules-Versionen ausgeführt. So können Sie die Gleichwertigkeit vor der Umstellung bestätigen. Ohne Testsuite erstellt der AI Assistant eine aus der Regellogik.

Kaum. Ihre Anwendung sendet weiterhin dieselbe Anfrage und erhält dieselbe Antwortstruktur. Geändert wird nur das Ziel: Statt eines Rule Execution Server auf Ihrer WebSphere-Instanz verwenden Sie eine Solver-API-URL, die DecisionRules beim Veröffentlichen der Regel erstellt. In der Praxis aktualisieren Sie eine Endpoint-Adresse und das Protokoll, nicht die gesamte Integration.

Eine Organisation ist die höchste Verwaltungsebene in DecisionRules. Sie ermöglicht Unternehmen, Benutzer, Authentifizierung, gemeinsame Einstellungen und mehrere Spaces zentral an einem Ort zu verwalten.

Organisationen eignen sich für Unternehmen, die mehrere Teams oder Spaces verwalten und eine zentrale Administration benötigen, während einzelne Teams weiterhin unabhängig zusammenarbeiten können.

Nein. Teams können weiterhin in ihren bestehenden Spaces arbeiten. Organisationen zentralisieren lediglich die Administration und unternehmensweite Konfiguration.

Teams fassen Benutzer zusammen, die an denselben Projekten oder Geschäftsbereichen arbeiten, und vereinfachen dadurch die Administration und Benutzerverwaltung.

Departments organisieren mehrere Teams in größeren Geschäftseinheiten und helfen Unternehmen, ihre bestehende Organisationsstruktur in DecisionRules abzubilden.

Department Manager verwalten einzelne Departments und helfen dabei, administrative Aufgaben in größeren Organisationen zu verteilen.

Organisationen unterstützen Single Sign-On über Microsoft, Google und Okta.

Mit Organisationen können Sie Unternehmensbranding, Einstellungen des KI-Anbieters, Authentifizierung, Organisationsstruktur und weitere organisationsweite Präferenzen zentral konfigurieren.

Organisationsadministratoren verwalten Benutzer, Teams, Departments, Authentifizierung, gemeinsame Einstellungen und die gesamte Organisationsstruktur.

CI/CD Pipelines automatisieren die Übertragung von Geschäftsregeln zwischen DecisionRules Spaces und Umgebungen. Sie nutzen die Management API und DecisionRules Pipeline Tools, um Regelprojekte als Teil eines bestehenden DevOps-Prozesses zu exportieren, zu vergleichen, zu sichern und zu importieren.

Nein. DecisionRules stellt die Management API und Pipeline-Dienstprogramme für Regeloperationen bereit. Ihre bestehende CI/CD-Plattform steuert, wann diese ausgeführt werden, wo Artefakte gespeichert werden und ob eine Freigabe erforderlich ist.

Die Tools sind providerneutrale Skripte. DecisionRules stellt Beispiele für Azure DevOps, AWS CodeBuild und Google Cloud Build bereit. Der gleiche Ansatz funktioniert mit GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines und weiteren Plattformen, die Node.js Befehle ausführen können.

Ja. Die Pipeline Tools unterstützen DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud und On-Premise-Bereitstellungen. Quelle und Ziel werden jeweils über ihre Umgebungs-URL und einen Space-spezifischen Management API key identifiziert.

Sie benötigen einen Quell-Space, einen Ziel-Space, deren DecisionRules-Umgebungs-URLs und für jeden Space einen Management API key. Die offiziellen Pipeline Tools laufen mit Node.js und können einem üblichen CI/CD Runner hinzugefügt werden. Für Release-Artefakte und Backups empfiehlt sich ein geschütztes Git-Repository oder Object Storage.

Die Standard-Pipeline Tools exportieren und importieren einen vollständigen Space einschließlich Regelressourcen und Ordnerstruktur. Für gezieltere Workflows bietet die Management API auch Operationen für einzelne Regeln, Versionen, Rule Flows und Ordner.

Ja. Exportieren Sie Quell- und Ziel-Spaces und führen Sie den Vergleich vor dem Import aus. Die Pipeline Tools können ein JSON-Vergleichsartefakt erzeugen, das einen Überblick über Regeländerungen zwischen beiden Umgebungen gibt.

Ja. Ihre CI/CD-Plattform steuert den Auslöser. Eine Pipeline kann manuell gestartet, geplant oder mit einem Repository-Ereignis wie Commit oder Merge verbunden werden.

Nein. Die Veröffentlichung ist eine eigene Lifecycle-Entscheidung. Die Pipeline überträgt das exportierte Regelprojekt und ist keine automatische Freigabe unfertiger Geschäftslogik. Definieren und prüfen Sie erwartete Regelstatus vor Produktionsverkehr.

Ja. Der dokumentierte Workflow sichert das Ziel, leert es und importiert danach das ausgewählte Quellartefakt. Ziel-Backup, Umgebungsvergleich und Freigabe sind deshalb wichtige Schutzmaßnahmen. Ein angepasster Management-API-Workflow kann einen engeren Umfang verwenden.

Ja. Die Freigabe wird in Ihrer CI/CD-Plattform konfiguriert. Im dokumentierten Azure-DevOps-Workflow sind Vergleich und Migration getrennte Phasen; vor der Aktualisierung des Ziel-Space ist eine Freigabe erforderlich.

Ja. Da die Pipeline Teil Ihres DevOps-Workflows ist, können Validierungsschritte vor der Freigabe oder nach dem Import ergänzt werden. Teams können die Pipeline um eigene Richtlinienprüfungen oder Solver API Smoke Tests erweitern.

Vor der Bereitstellung speichert die Pipeline den aktuellen Produktions-Space als Backup. Muss das neue Release zurückgesetzt werden, leert eine Recovery-Pipeline den betroffenen Space und importiert das ausgewählte Backup. Die Produktion kehrt zum vorher erfassten Zustand zurück.

Nein. Rule Versioning verwaltet nummerierte Iterationen einer einzelnen Regel in einem Space. Eine Pipeline-Recovery stellt einen gespeicherten Snapshot eines Space oder einer Umgebung wieder her. Nutzen Sie Rule Versioning für eine Regel und CI/CD Backups für die Wiederherstellung auf Umgebungsebene.

Speichern Sie Backups außerhalb des Ziel-Space, in einem geschützten Git-Repository, im CI/CD-Artefaktspeicher oder Object Storage wie Amazon S3 oder Google Cloud Storage. Wenden Sie die erforderlichen Aufbewahrungs- und Zugriffsrichtlinien an.

Ja. Die Pipeline gehört zu Ihrem DevOps-Workflow, sodass Validierungsschritte vor der Genehmigung oder nach dem Import hinzugefügt werden können. Die offiziellen Pipeline Tools konzentrieren sich auf das Exportieren, Vergleichen, Leeren und Importieren von Spaces. Teams können die Pipeline um eigene Richtlinienprüfungen oder Solver-API-Smoke-Tests nach der Bereitstellung erweitern.

Vor der Bereitstellung speichert die Pipeline den aktuellen Produktions-Space als Sicherungsdatei. Wenn die neue Version zurückgenommen werden muss, leert eine Wiederherstellungspipeline den betroffenen Space und importiert die ausgewählte Sicherung. Die Produktion wird dadurch in den Zustand vor der Bereitstellung zurückversetzt.

Nein. Rule Versioning verwaltet nummerierte Iterationen einer einzelnen Regel innerhalb eines Space. Die Pipeline-Wiederherstellung stellt einen gespeicherten Snapshot eines Space oder einer Umgebung wieder her. Verwenden Sie Rule Versioning für den Lebenszyklus einer einzelnen Regel und CI/CD-Sicherungen für die Wiederherstellung von Bereitstellungen auf Umgebungsebene.

Speichern Sie Sicherungen außerhalb des Ziel-Space in einem geschützten Git-Repository, im Artefaktspeicher Ihrer CI/CD-Plattform oder in einem Objektspeicher wie Amazon S3 oder Google Cloud Storage. Wenden Sie die von Ihrem Unternehmen vorgeschriebenen Aufbewahrungs- und Zugriffsrichtlinien an.

Speichern Sie jeden Management API key im Secret Store Ihrer CI/CD-Plattform. Verwenden Sie pro Space einen separaten Key, beschränken Sie Produktionsbereitstellungen und übertragen oder protokollieren Sie Keys niemals im Repository.

Ja. Getrennte Spaces schaffen eine klare Grenze zwischen laufender Arbeit und produktionsreifer Logik. Viele Teams nutzen Entwicklung, Test oder Staging und Produktion; die genaue Zahl der Umgebungen hängt von ihren Prüf- und Compliance-Anforderungen ab.

Exportieren und sichern Sie das Ziel, vergleichen Sie es mit der Quelle, prüfen Sie unerwartete Änderungen, verlangen Sie die passende Freigabe und bewahren Sie das bereitgestellte Artefakt auf. Führen Sie nach dem Import die vorgesehenen Validierungs- oder Smoke Tests aus.

Halten Sie die Recovery-Pipeline von der normalen Bereitstellungspipeline getrennt, schützen Sie ihren Zugriff und testen Sie sie vor dem Einsatz. Das Team muss wissen, welches Artefakt den letzten bekannten funktionsfähigen Produktionsstand darstellt und wie es bei der Wiederherstellung gewählt wird.

Nein. Sie verbinden sich mit Ihrem vorhandenen DecisionRules-Konto und wählen bei der Einrichtung, in welchem Space der Assistent arbeiten soll.

Ja. Im Space muss ein Management API Key eingerichtet sein. Darüber hinaus kann der Space leer sein; Ihre erste Anfrage kann darin etwas erstellen.

Ja. Der optionale Distribution Server stellt DecisionRules-Dokumentation, Vorlagen und wiederverwendbare Funktionen ohne Anmeldung in Ihrer Unterhaltung bereit. Er greift niemals auf Ihren Space zu.

Es ist die Verbindung zwischen Ihrem KI-Client und Ihrem DecisionRules Space. Nach der Verbindung kann Ihr Assistent Regeln erstellen und erklären, Testdaten generieren, Regeln mit echten Eingaben ausführen, Versionen und Tags verwalten und Abhängigkeiten nachverfolgen.

Das Model Context Protocol ist ein gemeinsamer Standard, mit dem sich ein KI-Client direkt mit einem Tool verbinden und darin Aktionen ausführen kann, statt Dokumentation zu lesen und zu raten. ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und andere unterstützen ihn nativ.

Mehr erfahren: weiterführende Dokumentation

Claude, ChatGPT, GitHub Copilot, VS Code und Codex haben eigene Connector-Einträge. Cursor und andere MCP-kompatible Clients verbinden sich über Smithery. DecisionRules ist außerdem im Docker MCP Catalog und im Azure MCP Center veröffentlicht.

Öffnen Sie die Connector-Liste in Ihrem Client, suchen Sie nach DecisionRules, melden Sie sich an und wählen Sie einen Space. Clients, die keinen Anmeldefluss abschließen können, lassen sich stattdessen mit einem Management API Key authentifizieren.

Sie legt alles fest, was der Assistent sehen und bearbeiten kann. Er kann keine Regeln in einem anderen Space erreichen und wechselt nicht selbstständig. Nutzen Sie für einen ersten Test besser einen Sandbox-Space statt eines Space mit Produktionsentscheidungen.

Meist wurde der falsche Space ausgewählt. Verbinden Sie sich erneut und prüfen Sie die Space-Auswahl, besonders wenn Ihr Konto mehrere Spaces hat.

Prüfen Sie, ob Ihr Client im Agent-Modus und nicht im normalen Chat-Modus läuft. In Copilot und Cursor ist dies ein separater Schalter, während die Tools in beiden Modi sichtbar bleiben können.

Alles – von einer vollständigen Regel bis zu einem einzelnen Lookup. Häufige Anfragen sind: eine Decision Table aus einer Beschreibung erstellen, eine angehängte Preisliste in eine neue Version überführen, Testfälle generieren, eine Regel mit Eingaben ausführen, Versionen vergleichen und Abhängigkeiten finden.

Ja. Sie können eine Regel mit beliebigen Eingaben ausführen und erhalten das Ergebnis in der Unterhaltung. Für eine vollständige Test-Suite mit erfolgreichen und fehlgeschlagenen Fällen verwenden Sie Rule Tests im Editor.

Ja. MCP-Clients können mehrere Serververbindungen gleichzeitig halten, und Ihr Assistent kann sie in einer Anfrage verwenden. Jeder Server wird separat verbunden; DecisionRules muss nicht wissen, dass die anderen existieren.

Nein. Die Erstellung erfolgt über den DecisionRules AI Assistant, denselben Assistenten wie im Editor. Er ist mit echter Regellogik und Best Practices trainiert und kennt Ihre Tabellenstruktur.

Der Assistent kann Regeln ändern, doch der Zugriff ist auf einen Space begrenzt, jede Änderung landet im Versionsverlauf und nichts erreicht Aufrufer, bevor eine Version veröffentlicht wird. Event Logs erfassen jede Änderung und ihren Auslöser.

Der Regelverlauf erfasst jeden Speichervorgang, Versionen sind explizite Momentaufnahmen und beides unterstützt ein Rollback mit einem Klick. Das schlimmste realistische Ergebnis ist ein Rollback.

Nein. Anfragen werden zu Enterprise-Bedingungen verarbeitet, ohne Training mit Ihren Daten. DecisionRules verfügt über SOC-2- und ISO-27001-Zertifizierungen sowie konfigurierbare Datenresidenz und SSO. Wenn Sie einen eigenen Modellanbieter nutzen, bestimmen dessen Bedingungen die No-Training-Garantie.

Die API ist für Systeme und wiederholbare Aufrufe. MCP ist für Unterhaltungen, Erstellung und Debugging. Die meisten Teams erstellen und debuggen über MCP und übernehmen sowie synchronisieren Änderungen anschließend über die API.

Nein. Alles, was geplant, reproduzierbar oder hochvolumig ist, gehört in die Management API. Eine Pipeline, die Anweisungen gelegentlich anders interpretiert, ist keine Pipeline.

Ja. Regeln können über MCP erstellt und debuggt und anschließend über die API übernommen und synchronisiert werden. MCP schreibt den Entwurf, die API liefert ihn aus.

Mit White Labeling können Sie die visuelle Identität Ihrer DecisionRules-Umgebung mit Ihrem eigenen Unternehmenslogo und Ihren Markenfarben anpassen.

Nein. White Labeling verändert die visuelle Identität Ihrer Umgebung, während die zugrunde liegenden Funktionen und Workflows von DecisionRules unverändert bleiben.

Nein. Logo- und Farbanpassung sind voneinander unabhängig. Sie können entweder nur eines davon konfigurieren oder beides kombinieren, um ein umfassenderes Markenerlebnis zu schaffen.

SVG wird für das beste Ergebnis empfohlen. Das Logo wird innerhalb des verfügbaren Branding-Bereichs angezeigt. Ein passend dimensioniertes horizontales Logo sorgt daher für gute Lesbarkeit in der gesamten Benutzeroberfläche.

Das Branding kann unter Organization → Settings → Organization Branding verwaltet werden. Dort stehen separate Bereiche für die Konfiguration Ihres Logos und benutzerdefinierter Farben zur Verfügung.

Ja. Logo- und Farbeinstellungen werden unabhängig voneinander konfiguriert, sodass Sie Ihr visuelles Design aktualisieren können, ohne Ihr vorhandenes Logo zu ersetzen.

Verwenden Sie dasselbe Logo und dieselbe visuelle Identität, die Ihre Teams bereits aus anderen internen Systemen kennen. Eine konsistente Benutzererfahrung lässt DecisionRules wie einen Teil Ihrer bestehenden Technologieumgebung wirken und nicht wie ein losgelöstes Tool.

Wählen Sie ein klares horizontales Logo und Markenfarben, die in der DecisionRules-Benutzeroberfläche gut lesbar bleiben. Ihr Branding sollte die Umgebung wiedererkennbar machen, ohne die Benutzerfreundlichkeit oder visuelle Klarheit zu beeinträchtigen.

Ja. Sie können Ihr Branding an die Weiterentwicklung Ihrer visuellen Identität anpassen, ohne Ihre Geschäftsregeln oder Entscheidungslogik zu beeinflussen.

Ja. White Labeling kann mit privaten DecisionRules-Bereitstellungen einschließlich Docker verwendet werden. Mit der Branding-Konfiguration kann Ihre bereitgestellte Umgebung die visuelle Identität Ihres Unternehmens übernehmen.

CI/CD-Pipelines automatisieren die Übertragung von Geschäftsregeln zwischen DecisionRules Spaces und Umgebungen. Sie verwenden die Management API und die DecisionRules Pipeline Tools, um Regelprojekte als Teil eines bestehenden DevOps-Release-Prozesses zu exportieren, zu vergleichen, zu sichern und zu importieren.

Nein. DecisionRules stellt die Management API und Pipeline-Dienstprogramme bereit, die die Regeloperationen ausführen. Ihre bestehende CI/CD-Plattform steuert, wann diese Operationen ausgeführt werden, wo Artefakte gespeichert werden und ob eine Genehmigung erforderlich ist.

Sie benötigen einen Quell-Space, einen Ziel-Space, die URLs der jeweiligen DecisionRules-Umgebungen und einen Management-API-Schlüssel für jeden Space. Die offiziellen Pipeline Tools werden mit Node.js ausgeführt und können einem standardmäßigen CI/CD-Runner hinzugefügt werden. Für Release-Artefakte und Sicherungen wird ein geschütztes Git-Repository oder ein Objektspeicher empfohlen.

Die Tools sind anbieterneutrale Skripte. DecisionRules stellt dokumentierte Beispiele für Azure DevOps, AWS CodeBuild und Google Cloud Build bereit. Derselbe Ansatz kann mit GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines und anderen Plattformen verwendet werden, die Node.js-Befehle ausführen können.

Ja. Die Pipeline Tools unterstützen DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud und On-Premise-Bereitstellungen. Jede Quelle und jedes Ziel wird durch die URL der Umgebung und einen Space-spezifischen Management-API-Schlüssel identifiziert.

Die standardmäßigen Pipeline Tools exportieren und importieren einen vollständigen Space einschließlich seiner Regelressourcen und Ordnerstruktur. Für selektivere Workflows stellt die Management API außerdem Operationen für einzelne Regeln, Versionen, Rule Flows und Ordner bereit. So können Teams eine Pipeline mit dem benötigten Umfang erstellen.

Ja. Exportieren Sie die Quell- und Ziel-Spaces und führen Sie vor dem Import den Vergleichsschritt aus. Die Pipeline Tools können ein JSON-Vergleichsartefakt erstellen, das Prüfern einen Überblick über die Regeländerungen zwischen den beiden Umgebungen gibt.

Ja. Die Genehmigung wird in Ihrer CI/CD-Plattform konfiguriert. Der dokumentierte Azure-DevOps-Workflow trennt beispielsweise Vergleich und Migration in verschiedene Phasen und erfordert eine Genehmigung, bevor die Migrationsphase den Ziel-Space aktualisieren kann.

Ja. Ihre CI/CD-Plattform steuert den Auslöser. Eine Pipeline kann manuell oder nach einem Zeitplan gestartet oder – abhängig von Ihrer Release-Richtlinie – mit einem Repository-Ereignis wie einem Commit oder Merge verknüpft werden.

Die Veröffentlichung ist eine separate Entscheidung im Lebenszyklus. Die Pipeline überträgt das exportierte Regelprojekt; sie sollte nicht als automatische Genehmigung unfertiger Geschäftslogik betrachtet werden. Legen Sie die erwarteten Regelstatus in Ihrem Release-Prozess fest und prüfen Sie diese, bevor Produktionsdatenverkehr an die importierten Regeln geleitet wird.

Ja. Der dokumentierte Full-Space-Workflow sichert den Ziel-Space, leert ihn und importiert anschließend das ausgewählte Quellartefakt. Da es sich um einen Ersetzungsvorgang handelt, sind die Sicherung des Ziel-Space, der Umgebungsvergleich und die Genehmigung wichtige Schutzmaßnahmen. Ein angepasster Management-API-Workflow kann einen engeren Bereitstellungsumfang verwenden, wenn eine vollständige Ersetzung nicht geeignet ist.

Speichern Sie jeden Management-API-Schlüssel im Secret Store Ihrer CI/CD-Plattform. Verwenden Sie für jeden Space einen separaten Schlüssel, beschränken Sie die Berechtigung zur Ausführung von Produktionsbereitstellungen und übertragen Sie Schlüssel niemals in das Repository oder in Pipeline-Protokolle.

Ja. Getrennte Spaces schaffen eine klare Grenze zwischen laufender Arbeit und produktionsbereiter Logik. Viele Teams verwenden eine Abfolge aus Entwicklung, Test oder Staging und Produktion. Die genaue Anzahl der Umgebungen hängt jedoch von ihren Prüfungs- und Compliance-Anforderungen ab.

Exportieren und sichern Sie das Ziel, vergleichen Sie es mit der Quelle, prüfen Sie unerwartete Änderungen, holen Sie die erforderliche Genehmigung ein und bewahren Sie das bereitgestellte Artefakt auf. Führen Sie nach dem Import die in Ihrem Release-Prozess definierten Validierungs- oder Smoke-Tests aus.

Halten Sie die Wiederherstellungspipeline von der normalen Bereitstellungspipeline getrennt, schützen Sie den Zugriff darauf und testen Sie sie, bevor sie benötigt wird. Stellen Sie sicher, dass das Team weiß, welches Artefakt den letzten bekannten fehlerfreien Produktionszustand darstellt und wie es bei der Wiederherstellung ausgewählt wird.

Sie benötigen DecisionRules App 1.26.1 oder neuer und AI Engine 1.2.0 oder neuer. Ihr Benutzerkonto muss berechtigt sein, den AI Assistant zu verwenden und die Regel zu bearbeiten. Die Regel darf nicht gesperrt sein.

Beschreiben Sie die Änderung und das erwartete Ergebnis möglichst konkret. Konzentrieren Sie sich darauf, was geändert werden soll oder wie es sich verhalten muss, anstatt eine vollständige Neufassung anzufordern.

Ja. Sie können Zellen aktualisieren, Spalten hinzufügen, Regelvariablen ändern und Eingabe- oder Ausgabemodelle in einer einzigen Anfrage anpassen. Der Assistant verarbeitet alle zusammengehörigen Änderungen gemeinsam, um die Konsistenz zu wahren.

Nein. Die Identität der Regel – Name, Alias, Version und andere Regeleinstellungen – bleibt erhalten.

Nein. Nichts wird automatisch gespeichert. Der Assistant erstellt lediglich einen Vorschlag. Sie müssen ihn prüfen und anwenden. Sie können ihn jederzeit verwerfen oder rückgängig machen.

Der Vorschlag kann veraltet sein. Erstellen Sie ihn in diesem Fall erneut, damit er die aktuelle Regelversion berücksichtigt. Bereits angewendete Änderungen können weiterhin rückgängig gemacht werden.

In unseren Tests war es die Replikatgrenze, nicht die Engine. Bis 100 gleichzeitige Clients verhielten sich beide Konfigurationen identisch; danach skalierte die elastische Bereitstellung weiter, während die begrenzte bei etwa 9.800 Berechnungen/s plateauierte.

Mit zwei k6-Lasttests gegen DecisionRules auf Kubernetes. Die Lastgeneratoren liefen in derselben Region wie der Cluster; jede Antwort wurde inhaltlich validiert. Alle Werte sind clientseitig beobachtete Roundtrip-Zeiten einschließlich Netzwerkübertragung.

Bei Entscheidungstabellen steigt die Latenz unter fester Last von 3 ms bei 500 Anfragen/s auf 10 ms bei 100.000 Anfragen/s. Durch Skalierung lässt sich dies jedoch vermeiden.

Null. Alle Anfragen lieferten HTTP 200 und bestanden die Inhaltsvalidierung.

Ein Workflow mit mehreren Regeln (bis zu 10 Regeln) benötigt durchschnittlich höchstens 5,5 ms – je nachdem, ob die Regeln parallel oder nacheinander ausgeführt werden.

Innerhalb eines Flows ist es schneller. Ein Flow mit 5 parallelen kleinen Entscheidungen ist nur 0,1 ms langsamer als eine einzelne Entscheidung. Der größte Teil der Ausführungszeit entfällt bereits auf die Orchestrierung und nicht auf die Auswertung.

Eine mittelgroße Entscheidungstabelle (etwa 20 Zeilen) oder ein Entscheidungsbaum wird bei 500 Anfragen pro Sekunde in weniger als 3 Millisekunden verarbeitet – einschließlich der Netzwerk-Roundtrip-Zeit.

Wir haben mehr als 106.000 Entscheidungen pro Sekunde mit 600 gleichzeitig aktiven virtuellen Benutzern gemessen.