Das Verhalten der Funktion DataStoreRuleObjectCreator lässt sich am besten anhand eines Beispiels veranschaulichen. Dieses Beispiel basiert auf dem Modul "Universal Access".
Ein IEG-Script kann Einkommensdaten für einen Haushalt erfassen. Der Haushalt kann eine beliebige Anzahl von Personen umfassen und für jede Person kann es eine beliebige Anzahl von Einkommensdetails geben.
Die Struktur des Datenspeicherschemas ist nachfolgend vereinfacht dargestellt:
- Application:
- Person (0..n):
- firstName (Zeichenfolge)
- lastName (Zeichenfolge)
- Income (0..n):
- type (Code aus Codetabelle "IncomeType")
- amount (Zahl)
Ein Bürger (John) zeichnet im Rahmen eines Self-Screenings Angaben für seinen Haushalt (der aus ihm selbst und seiner Frau Mary besteht) sowie Einkommensdetails auf (John ist arbeitssuchend, Mary führt zwei Teilzeittätigkeiten aus). Johns Angaben werden im Datenspeicher als Datensätze gespeichert:
- Application #1234:
- Person #1235:
- firstName: John
- lastName: Smith
- Income: <keine Datensätze>
- Person #1236:
- firstName: Mary
- lastName: Smith
- Income #1237:
- type: Part-time
- amount: 25
- Income #1238:
- type: Part-time
- amount: 30
Das CER-Regelwerk, das für die Verwendung bei diesem Screeningtyp konfiguriert ist, enthält dieselben Regelklassen (Programmregelklassen sind nicht aufgeführt):
<?xml version="1.0" encoding="UTF-8"?> <RuleSet name="DataStoreMappingExample" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "http://www.curamsoftware.com/CreoleRulesSchema.xsd"> <!-- NB no rule class for the CDS entity type "Application"; the attributes stored directly on an Application are not required by rules, so no point creating a rule object which won't get used. --> <!-- The name of this rule class matches that of a CDS entity type --> <Class name="Person"> <!-- The name of this rule attribute matches that of an attribute on the CDS entity type, and so its value will be automatically specified by the DataStoreRuleObjectRetriever. --> <Attribute name="firstName"> <!-- The type of the rule attribute must agree with the type of the CDS attribute type, otherwise CER will issue a runtime error. --> <type> <javaclass name="String"/> </type> <derivation> <specified/> </derivation> </Attribute> <!-- NB no rule attribute for the CDS attribute for lastName. --> <!-- Rule attributes matching the "childEntities_<rule class name>" pattern will receive special treatment from the DataStoreRuleObjectRetriever. The DataStoreRuleObjectRetriever will specify the value of this attribute to be all the rule objects created from the child Income records which belong to this Person's record in the CDS. --> <Attribute name="childEntities_Income"> <!-- The type must be a list of Income rule objects --> <type> <javaclass name="List"> <ruleclass name="Income"/> </javaclass> </type> <derivation> <specified/> </derivation> </Attribute> </Class> <!-- The name of this rule class does not match any CDS entity type, so the DataStoreRuleObjectRetriever will not create any rule objects for this rule class. --> <Class name="Benefit"> <Attribute name="amount"> <type> <javaclass name="Number"/> </type> <derivation> <specified/> </derivation> </Attribute> </Class> <Class name="Income"> <!-- A rule attribute named "parentEntity" will receive special treatment from the DataStoreRuleObjectRetriever. The DataStoreRuleObjectRetriever will specify the value of this attribute to be the rule object created from the Person record which is the parent of this Income record in the CDS. --> <Attribute name="parentEntity"> <!-- The type must be a single Person rule object --> <type> <ruleclass name="Person"/> </type> <derivation> <specified/> </derivation> </Attribute> <Attribute name="type"> <type> <!-- The type of this attribute must specify the correct code table, matching the CDS domain definition. --> <codetableentry table="IncomeType"/> </type> <derivation> <specified/> </derivation> </Attribute> <Attribute name="amount"> <type> <javaclass name="Number"/> </type> <derivation> <!-- This derivation will never be executed, as the DataStoreRuleObjectRetriever will automatically "specify" the value from that on the CDS record; once a value is specified CER does not attempt to calculate it. In general, attributes which expect to be populated by the DataStoreRuleObjectRetriever should be marked as <specified/> to avoid any confusion between stand-alone testing of your rule sets and testing with the DataStoreRuleObjectRetriever. --> <Number value="123"/> </derivation> </Attribute> <!-- This attribute is not present on the CDS entity type, so will not be populated. This is exactly what we want, because its value is derived from other rule attributes in the normal CER way. --> <Attribute name="isCountable"> <type> <javaclass name="Boolean"/> </type> <derivation> <choose> <type> <javaclass name="Boolean"/> </type> <test> <reference attribute="type"/> </test> <when> <condition> <Code table="IncomeType"> <String value="Full-time"/> </Code> </condition> <value> <true/> </value> </when> <when> <condition> <Code table="IncomeType"> <String value="Part-time"/> </Code> </condition> <value> <true/> </value> </when> <otherwise> <value> <false/> </value> </otherwise> </choose> </derivation> </Attribute> <!-- This rule attribute is not calculated, nor does it correspond to an attribute on the CDS entity type. If the value of this attribute is referenced at runtime, CER will report a runtime error: "Value must be specified before it is used (it cannot be calculated)." --> <Attribute name="employerName"> <type> <javaclass name="String"/> </type> <derivation> <specified/> </derivation> </Attribute> </Class> </RuleSet>
Sobald John sein Self-Screening abgeschlossen hat, lädt das Modul "Universal Access" das obige CER-Regelwerk und erstellt eine CER-Sitzung.
Das Modul "Universal Access" ruft die Funktion DataStoreRuleObjectCreator auf und gibt den Stammdatensatz im Datenspeicher (Application #1234) an.
Die Funktion DataStoreRuleObjectCreator ruft alle untergeordneten Datensätze von "Application #1234" ab und verarbeitet sie folgendermaßen:
Wird übersprungen, da es im Regelwerk keine Regelklasse namens "Application" gibt.
Es wird eine Regelobjektinstanz der Regelklasse Person mit den folgenden Elementen erstellt:
Wird mit "John" angegeben.
Wird übersprungen, da es kein Regelattribut namens "lastName" in der Regelklasse Person gibt.
Wird als leere Liste angegeben, da es keine Datensätze des Typs "Income" für den Personendatensatz #1235 gibt.
Es wird eine Regelobjektinstanz der Regelklasse Person mit den folgenden Elementen erstellt:
Wird mit "Mary" angegeben.
Wird übersprungen.
Wird als Liste mit den beiden (nachfolgend erstellten) Regelobjekten des Typs "Income" für Mary angegeben.
Es wird eine Regelobjektinstanz der Regelklasse Income mit den folgenden Elementen erstellt:
Wird als (zuvor erstelltes) Regelobjekt des Typs Person für Mary aus dem Personendatensatz #1236 angegeben.
Wird mit dem Code "Part-time" angegeben.
Wird mit der Zahl "25" angegeben.
Wird nicht angegeben, da die Datenspeicherentität kein Attribut namens "employerName" enthält.
Es wird eine Regelobjektinstanz der Regelklasse Income mit den folgenden Elementen erstellt:
Wird als (zuvor erstelltes) Regelobjekt des Typs Person für Mary aus dem Personendatensatz #1236 angegeben.
Wird mit dem Code "Part-time" angegeben.
Wird mit der Zahl "30" angegeben.
Abschließend stellt das Modul "Universal Access" (Universalzugriff) dem Regelwerk die Standardfragen über Programme, Anspruchsberechtigung und Erläuterung. Die (im obigen Beispiel nicht dargestellten) Regelklassen für die Programme greifen bei der Beantwortung dieser Fragen auf die (von der Funktion DataStoreRuleObjectCreator erstellten) Regelobjekte zu.
Weitere Informationen zum Anwendungsdatenspeicher und seinen Schemas enthält das Handbuch Creating Datastore Schemas.