So funktioniert CLE

Excel speichern. JSON rein. JSON raus.

Geschäftslogik gehört nicht in den Anwendungscode.

CLE trennt Entscheidungslogik vom Anwendungscode. Fachbereiche pflegen Entscheidungen in Excel, während Anwendungen die Ergebnisse über APIs nutzen.

CLE ist Compiler und Runtime für Excel-basierte Entscheidungsmodelle.

Drei Dinge. Mehr nicht.

1. Fachbereiche pflegen das Entscheidungsmodell in Excel

Preisregeln, Validierungsregeln, Freigabekriterien, Klassifikationen und Berechnungen werden in Excel gepflegt.

Die Excel-Datei ist der Source Code des Entscheidungsmodells.
Der Dependency Graph ist das ausführbare Artefakt.

2. Die Anwendung sendet ein JSON-Objekt

POST /api/decision
Content-Type: application/json

[{
  "country": "Italy",
  "weight": 205,
  "currency": "EUR",
  "requestedQuantity": 300,
  "purchasePrice": 1.35
}]

Ihr ERP, CRM, PIM oder eine beliebige Anwendung übergibt ein bestehendes Business-Objekt an CLE.

3. CLE liefert ein JSON-Objekt zurück

Standardmäßig arbeitet CLE nach dem Prinzip JSON In / JSON Out.

Das ursprüngliche Business-Objekt bleibt erhalten und wird um die berechneten Entscheidungswerte ergänzt.

HTTP 200 OK
(annotated for clarity)

[{
  "country": "ITALY",       // standardized
  "iso_code": "IT",         // added
  "weight": 205,
  "weightClass": "heavy",   // added
  "currency": "EUR",
  "requestedQuantity": 300,
  "purchasePrice": 1.35,
  "purchaseTier": 3,        // calculated
  "marginFactor": 1.81481,  // calculated
  "salesPrice": 2.45        // calculated
}]

Für spezielle Anwendungsfälle kann CLE auch vollständig eigene Antwortstrukturen erzeugen.

CLE verwendet ein Bulk-orientiertes API-Modell.

Anfragen enthalten immer eine Sammlung von Business Objects. Diese Sammlung kann aus einem einzelnen Objekt oder aus Tausenden gleichartiger Objekte bestehen. Unabhängig vom Umfang bleibt das API-Muster identisch.

Alle Objekte einer Anfrage werden durch dasselbe Entscheidungsmodell verarbeitet. Dadurch können komplette Produktkataloge, Aufträge, Validierungen oder Benutzeroberflächenentscheidungen effizient in einem einzigen API-Aufruf ausgeführt werden.

Was passiert innerhalb von CLE?

Von außen betrachtet wirkt CLE einfach. Intern führt CLE jedoch keine Tabellenkalkulation aus.

CLE analysiert die Arbeitsmappe und kompiliert sie in einen ausführbaren Dependency Graph.

flowchart TD

    A["Excel-Datei<br/>(Source Code)"]
    B["Dependency-Analyse"]
    C["Kompilierung"]
    D["Dependency Graph<br/>Ausführbares Artefakt"]
    E["Decision Runtime"]
    F["REST APIs"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

    classDef source fill:#E3F2FD,stroke:#1976D2,color:#000;
    classDef runtime fill:#FFDFE5,stroke:#FF5978,color:#000;
    classDef artifact fill:#FFF9C4,stroke:#D4AF37,color:#000;

    class A source;
    class D artifact;
    class E,F runtime;

Warum ein Dependency Graph?

Geschäftsentscheidungen bestehen selten aus einer einzelnen Entscheidungstabelle.

Ein Preisermittlungsmodell kann Formeln, Lookup-Tabellen, Referenzdaten, Klassifikationen und zahlreiche Zwischenberechnungen enthalten.

CLE erkennt diese Abhängigkeiten und transformiert sie in einen ausführbaren Dependency Graph.

flowchart TD

    I1["Input"]
    I2["Lookup A"]
    I3["Lookup B"]

    C1["Berechnung 1"]
    C2["Berechnung 2"]

    D1["Entscheidung"]

    O1["Ausgabe A"]
    O2["Ausgabe B"]

    I1 --> C1
    I2 --> C1

    I1 --> C2
    I3 --> C2

    C1 --> D1
    C2 --> D1

    D1 --> O1
    D1 --> O2

CLE ist bewusst zustandslos

CLE ist eine stateless Decision Runtime.
CLE speichert keine Geschäftsdaten, benötigt keine Datenbank und verwaltet keine Benutzersitzungen.
Jede Anfrage wird unabhängig von vorherigen Anfragen ausschließlich auf Basis des übergebenen JSON-Objekts ausgewertet.

Vorteile:

  • horizontale Skalierbarkeit
  • deterministische Ausführung
  • Cloud-native Bereitstellung
  • Container-Deployment
  • vereinfachter Betrieb
  • vorhersehbare Performance

Die Anwendung besitzt die Daten. CLE kapselt die Entscheidungslogik.

Nach oben scrollen