CER-Sitzungen

Bei CER werden die folgenden Hauptdatenelemente verwendet:

Regelobjekte
Ein Regelobjekt ist eine Instanz einer Regelklasse aus einem CER-Regelwerk, beispielsweise das Regelobjekt für die Person "Thomas Schmidt".
Attributwerte
Ein Attributwert ist der Wert eines CER-Regelattributs für ein bestimmtes Regelobjekt, beispielsweise das Geburtsdatum von Thomas Schmidt.

Alle Interaktionen mit CER-Regelobjekten und -Attributwerten finden innerhalb einer CER-Sitzung statt. Zu diesen Interaktionen gehören das Erstellen, Abrufen und/oder Entfernen von CER-Regelobjekten sowie jede Berechnung oder Neuberechnung von Attributen für Regelobjekte.

Jede CER-Sitzung wird unter Verwendung der Klasse curam.creole.execution.session.Session_Factory erstellt.

Bei der Erstellung einer CER-Sitzung muss Folgendes angegeben werden:

Neuberechnungsstrategie
Die Strategie für die Verarbeitung einer Anforderung zur Neuberechnung eines CER-Attributwerts in einer CER-Sitzung.¹

Die Strategie für die Verarbeitung einer Anforderung zur Neuberechnung eines CER-Attributwerts. Beispielsweise kann angegeben werden, ob die Neuberechnung sofort erfolgen, in eine andere Transaktion zurückgestellt oder gänzlich unzulässig sein soll.
Datenspeicher
Der Speichermechanismus², der für persistente Regelobjekte verwendet werden soll; beispielsweise lediglich hauptspeicherintern (was bedeutet, dass die Daten nach Ablauf der Sitzungsgültigkeit nicht mehr vorhanden sind), Datenbankspeicher oder Momentaufnahmespeicher.

Die Implementierungen von Datenspeicher müssen wiederum eine zu verwendende Regelobjektfactory angeben. Diese Factory steuert, ob Regelobjekte streng typisiert oder lediglich interpretiert erstellt werden.

Die Anwendung umfasst die folgenden Implementierungen:

Neuberechnungsstrategie:
- curam.creole.execution.session.RecalculationsProhibited
  Löst einen Fehler aus, wenn in der CER-Sitzung versucht wird, eine Neuberechnung auszuführen.
- curam.core.sl.infrastructure.propagator.impl.ImmediateRecalculationStrategy
  Führt Neuberechnungen sofort (synchron in der derselben Datenbanktransaktion) aus.
- curam.core.sl.infrastructure.propagator.impl.DeferredRecalculationStrategy
  Stellt Neuberechnungen (für gespeicherte Attributwerte) in eine andere Datenbanktransaktion zurück.
  
  Stellt Neuberechnungen (für gespeicherte Attributwerte) in eine andere Datenbanktransaktion zurück.
Datenspeicher:
- curam.creole.storage.inmemory.InMemoryDataStorage
  Behält Regelobjekte lediglich im Hauptspeicher bei. Regelobjekte in diesem Datenspeicher sind nur solange verfügbar, wie der Datenspeicher gültig ist (normalweise nur für eine einzige Datenbanktransaktion).
- curam.creole.storage.database.DatabaseDataStorage
  Ruft externe³ Regelobjekte aus einer der folgenden Quellen ab:
- curam.creole.execution.session.RuleObjectsSnapshot.SnapshotDataStorage
  Erstellt ein XML-Dokument mit Details einer Gruppe von Regelobjekten, die an den Abhängigkeiten für eine oder mehrere Attributberechnungen beteiligt sind. Stellt ein Überprüfungsprotokoll der Daten bereit, die letztlich in dieser Berechnung verwendet werden. Das XML-Dokument kann normalweise in einer Datenbanktabelle gespeichert werden, damit die Momentaufnahme von Regelobjekten durch eine nachfolgende Datenbanktransaktion abgerufen (jedoch nicht geändert) werden kann.
  - Entweder ein Regelobjektkonverter, der beim Datenbankdatenspeicher registriert ist. Jeder Regelobjektkonverter benennt die von ihm verarbeiteten Regelklassen. Bei seinem Aufruf⁴ liest der Regelobjektkonverter die zugrunde liegenden Geschäftstabellen, um die entsprechenden Daten abzurufen, die Regelobjekte im Hauptspeicher zu füllen und sie anschließend an den Datenbankdatenspeicher zurückzugeben.
  - Oder eigene Datenbanktabellen von CER für die Speicherung von Regelobjekten, falls kein Regelobjektkonverter für die Verarbeitung der angeforderten Regelklasse registriert ist.
  Externe Regelobjekte sind für den Abruf und die Bearbeitung durch nachfolgende Datenbanktransaktionen verfügbar.
- curam.creole.storage.hybrid.HybridDataStorage
  Kombiniert Verhaltensaspekte der Implementierungen "InMemoryDataStorage" und "DatabaseDataStorage". Ist für die interne Verwendung durch Cúram reserviert.
Regelobjektfactory:
- curam.creole.execution.session.StronglyTypedRuleObjectFactory
  Erstellt Regelobjekte als Instanzen von Java-Klassen (bzw. ruft sie ab), die durch den CER-Testcodegenerator generiert wurden (siehe CER-Testcodegenerator). Darf nicht im Produktionscode verwendet werden.
- curam.creole.execution.session.InterpretedRuleObjectFactory
  Verwendet ein vollständig interpretiertes (und somit dynamisches) Verfahren, um Regelobjekte zu erstellen und abzurufen (siehe Regelwerkinterpreter).

Vorsicht:

Generell sollten nicht mehrere CER-Sitzungen in einer einzigen Datenbanktransaktion verwendet werden. Die im Hauptspeicher befindlichen Kopien der Regelobjekte in einer CER-Sitzung sind unabhängig von den im Hauptspeicher befindlichen Kopien von Regelobjekten in allen anderen CER-Sitzungen.

Das Verhalten kann nicht garantiert werden, wenn mehrere CER-Sitzungen (in derselben Transaktion) versuchen, dasselbe Regelobjekt aus der Datenbank abzurufen oder abzufragen.

Komponententests
Verwenden Sie (zur schnellen Ausführung) eine Implementierung des Typs "InMemoryDataStorage" mit "StronglyTypedRuleObjectFactory" (damit generierte Java-Klassen in Tests verwendet werden können) und mit "RecalculationsProhibited" (damit Daten nicht versehentlich auf halbem Weg durch Tests geändert werden).
Produktionslogik mit dynamischen Regelwerken
Verwenden Sie eine Implementierung des Typs "DatabaseDataStorage" (damit Regelobjekte transaktionsübergreifend verfügbar sind) mit "InterpretedRuleObjectFactory" (damit die Regelwerke vollständig dynamisch sind) und mit "RecalculationsProhibited" und verwenden Sie die vom Abhängigkeitsmanager bereitgestellten Funktionen (siehe Abhängigkeitsmanager), um alle Anforderungen zur Neuberechnung von CER-Werten in einer neuen (und unabhängigen) CER-Sitzung auszuführen.
Momentaufnahmen
Verwenden Sie eine Implementierung des Typs "SnapshotDataStorage" (damit die Regelobjekte aus einem nicht änderbaren XML-Dokument gelesen werden) mit "InterpretedRuleObjectFactory" (damit Regelwerke vollständig dynamisch sind) und "RecalculationsProhibited" (Änderungen werden von Momentaufnahmen nicht unterstützt).

¹ Die CER-Funktionalität für die direkte Ausführung von Neuberechnungen wird nun durch den Abhängigkeitsmanager abgelöst (siehe Abhängigkeitsmanager).

Die Schnittstelle und die Implementierungen für die CER-Neuberechnungsstrategie werden nur aus Gründen der Abwärtskompatibilität bereitgestellt.

² Seit Cúram Version 6 bietet CER eine Auswahl von Datenspeicherimplementierungen. Diese Datenspeicherimplementierungen wirken sich darauf aus, ob Regelobjekte, die in einer Transaktion erstellt oder geändert wurden, in anderen Transaktionen abgerufen und/oder geändert werden können.

Besonders wichtig ist in diesem Zusammenhang, dass die Auswahl des Datenspeichers keinen Einfluss auf die Semantik der Regelausdrücke hat. Dies bedeutet, dass Sie einen einfachen (hauptspeicherinternen) Datenspeicher für Ihre JUnit-Tests verwenden können (damit eine große Anzahl von JUnit-Tests schnell ausgeführt werden kann) und dass Sie einen persistenten Datenspeicher (Datenbank) für Ihre Produktionslogik einsetzen können (damit Regelobjekte transaktionsübergreifend persistent sind), ohne dass es Unterschiede in den zugrunde liegenden Berechnungen gibt.

³ Als Optimierung werden nur externe Regelobjekte und deren Attributwerte aus Daten in der Cúram-Datenbank abgerufen. Interne Regelobjekte und deren Attribute können naturgemäß zu einem späteren Zeitpunkt zuverlässig berechnet werden, während externe Regelobjekte normalerweise Daten aus externen Quellen enthalten und folglich nicht neu berechnet werden können.

⁴ Bitte beachten Sie, dass jeder Regelobjektkonverter Grenzwerte für seine Unterstützung von Ausdrücken "readall" (siehe readall, und readall) durchsetzen kann.

Beispielsweise unterstützen einige Regelobjektkonverter möglicherweise nicht die Ausführung eines Ausdrucks "readall" (siehe readall) ohne verschachtelte Angabe von match und/oder geben Einschränkungen für die Regelattribute vor, die im Wert für retrievedattribute des Ausdrucks match angegeben werden können.

Verstöße gegen die Einschränkungen des Regelobjektkonverters führen dazu, dass zur Laufzeit eine Ausnahmebedingung ausgelöst wird. Sie sollten sicherstellen, dass Ihre Regelwerktests Logik enthalten, mit denen die Regelobjektkonverter (also die für den Datenbankdatenspeicher ausgeführten Konverter) aufgerufen werden - im Gegensatz zur Mehrzahl der Regellogiktests, die den hauptspeicherinternen Datenspeicher nutzen und daher keine Regelobjektkonverter aufrufen.

Wissenswertes über die Einschränkungen, die eine Implementierung eines Regelobjektkonverters für die Unterstützung von Ausdrücken "readall" (siehe readall) vorgibt, finden Sie in der Dokumentation für die jeweilige Implementierung.