Im Checkservice können pro Datenmodell benutzerdefinierte Regeln angegeben werden. Die benutzerdefinierten Regeln müssen in einer speziellen Excel Konfigurationsdatei eingetragen werden (<Modellname>.xls). In diesem Kapitel ist der Aufbau der Regeldatei beschrieben.
Die Regeldatei im Microsoft Excel 97 Format (.xls) muss wie folgt aufgebaut sein:
Der Name der Datei muss <Modellname>.xls sein (z.B.
DM01AVCH24D.xls).Die Regeldatei muss vollständig sein, d.h. alle Regeln zum Modell enthalten.
Die Excel-Datei muss die Tabellen
RULES,<MODEL>_DEFund<MODEL>_TXTenthalten.Der Aufbau und Inhalt der Tabellen muss den nachfolgenden Beschreibungen genügen.
Alle Tabellen oder Attribute welche hier nicht spezifiziert sind, werden beim Import der Regeldatei ignoriert, d.h. werden beim erneuten Bezug vom Server nicht mehr geliefert.
Die Tabelle RULES enthält alle
Regeldefinitionen für ein bestimmtes Datenmodell und muss folgende
Kolonnen enthalten:
default_ProfileStandardprofil. Alle Regeln welche zum Standardprofil gehören sollen, müssen mit einem grossen
Xmarkiert werden. Falls das Profil vom Benutzer ausgewählt wurde (implizit oder mitquote site set param profiles default), werden nur die mitXmarkierten Regeln ausgeführt.<user>_Profile(optional)Benutzerprofil. Es können beliebig viele Benutzerprofile pro Modell definiert werden. Der Checkservice Benutzer kann ein oder mehrere Profile mit dem Befehl
quote site set param profiles <user1>,<user2>,..,<userN>selektieren.ModellnameModellname (z.B.
DM01AVCH24D). Das Modell muss auf dem Server installiert und für den Checkservice aktiviert sein. Pro Regeldatei können nur zu einem Modell Regeln definiert bzw. auf dem Server gespeichert werden. Sind in der Regeldatei auch Regeln zum Basismodell enthalten, dann werden von diesen Regeln nur die Profilinformationen auf dem Server gespeichert.TopicnameTopicname. Der Topicname muss ein gültiger Topicname innerhalb des Modells sein.
TablenameTablename. Der Tablename muss ein gültiger Tabellennamen innerhalb des Topics sein.
ConditionBedingung für die Tabelle. Die Checkservice Regel gilt nur für die Objekte der Tabelle, für welche die Bedingung erfüllt ist (s.a. Formulierung von Bedingungen).
OperatorName eines Operators. Die Regel erzeugt eine Fehlermeldung, wenn der Operator auf den aktuellen Daten nicht erfüllt ist. Alle verfügbaren Operatoren sind im Anhang zusammen gestellt.
UserIdBenutzerdefinierbare Bezeichnung der Regel. Hinweis: Normalerweise sollten die ersten zwei Buchstaben den Kanton bezeichnen (z.B.
BE100001).CategoryFehlerkategorie. Es sind folgende Werte zulässig:
error,warningundinfo.Message_de(optional)Fehlermeldung auf Deutsch.
Message_fr(optional)Fehlermeldung auf Französisch.
Message_it(optional)Fehlermeldung auf Italienisch.
Message_en(optional)Fehlermeldung auf Englisch.
Modify_date(optional)Datum der letzten Änderung an der Regel im Format
YYYYMMDD(z.B.20081205).Modify_user(optional)Benutzer, welcher die Regel erstellt oder verändert hat (z.B.
swisstopo/rb).Comment(optional)Kommentar zur Regel.
Die Regeln müssen wie folgt erfasst werden:
Alle obligatorischen Felder müssen erfasst werden.
Pro Regel muss mindestens eine Fehlermeldung (Deutsch, Französisch, Italienisch oder Englisch) definiert werden.
Leere Zeilen sind in der Tabelle
RULESnicht erlaubt.Die Tabelle RULES muss durch eine Zeile abgeschlossen werden, welche für jede Kolonne den Wert
END_RULESenthält.
Die Tabelle <MODELNAME>_DEF enthält
alle Listen bzw. Listenbereiche zum Modell und muss folgende Kolonnen
enthalten:
DefinitionsListendefinitionen gemäss folgender Syntax:
<Liste> := LIST <Listenname> <Zeichenkette>* END_LIST <Listerange> := LISTRANGE <Listerangename> (<Zeichenkette> <Zeichenkette>)* END_LISTRANGE
Beispiel:
Die Zeilen müssen wie folgt erfasst werden:
Die Zeilen müssen der Syntaxregel entsprechen.
Die erste Zeile nach
Definitionsdarf nicht leer sein, sonst sind leere Zeilen erlaubt.Die letzte Zeile muss den Wert
END_<MODEL>_DEFenthalten.
Die Tabelle <MODELNAME>_TXT enthält
Kommentare zum Modell und muss folgende Kolonnen enthalten:
CommentsBeliebige Kommentarzeilen.
Die Zeilen müssen wie folgt erfasst werden:
Die erste Zeile nach
Commentsdarf nicht leer sein, sonst sind leere Zeilen erlaubt.Die letzte Zeile muss den Wert
END_<MODEL>_TXTenthalten.
Zur Laufzeit wird die Regeldatei wie folgt ausgewertet:
Allen Regeln, welche nicht zu einem ausgewählten Profil gehören, werden ignoriert.
Zu jedem gelesenen INTERLIS Objekt werden die zu
Modelname,TopicnameundTablenamepassenden Regeln in der TabelleRULESgesucht.Für alle gefundenen Regeln wird geprüft, ob die Vergleiche in
Conditionfür das gegebenen INTERLIS Objekt erfüllt sind.Für alle durch die Regeln selektierten Objekte wird der
Operatorder Regel mit den Argumenten ausArgumentsausgeführt.Falls das Objekt den Test nicht erfüllt, wird die Fehlermeldung in der vom Benutzer gewählten Sprache ausgegeben.
Manchmal ist es notwendig, dass ein Test nur für eine bestimmte
Teilmenge von Objekten einer Tabelle gilt. Die Teilmengen kann mit der
Angabe einer Condition gebildet werden.
Beispiel:
Topicname Tablename Condition Operator
Liegenschaften ProjLiegenschaft Qualitaet_TXT=AV93 GRUNDSTUECK
Die obige Regel wird z.B. nur für Objekte der Tabelle
ProjLiegenschaft ausgeführt, wenn für die Objekte das
Attribut Qualitaet den Wert AV93
hat. Die Kombination von mehreren Bedingungen ist ebenfalls möglich.
Dazu müssen die einzelnen Bedingungen durch Komma getrennt angegeben
werden. Als Vergleichsoperatoren stehen = (gleich)
und # (ungleich) zur Verfügung. Der Test auf
Undefiniert ist via =NULL oder
#NULL möglich.
Beispiel für mehrere Vergleiche in der gleichen Bedingung:
Condition Punktzeichen_TXT=Stein,Begehbarkeit_TXT=ja
Bei Aufzählungstypen ist es erlaubt, den textuellen Wert des
Attributs in Regeln oder Bedingungen zu verwenden. Dazu muss jedoch der
Attributname des Aufzählungsattributs mit dem Postfix
_TXT ergänzt werden (z.B.
Punktzeichen_TXT).
Beispiel:
Condition Punktzeichen_TXT=Stein
Falls zwischen zwei Tabellen eine 1:1,
1:m oder 1:mc Beziehung besteht,
kann man in Regeln oder Bedingungen des Unterobjekts auf Attribute des
Oberobjekts via das Beziehungsattribut zugreifen. Dazu muss der
Attributname aus
<Referenzattribut>.<Oberobjektattribut>
gebildet werden. Es ist auch möglich über mehrere Stufen zu verweisen
(z.B. Zugriff auf Attribute des Oberoberobjekts).
Beispiel:
Topicname Tablename Condition
Liegenschaften Liegenschaft Liegenschaft_von.Vollstaendigkeit_TXT=Vollstaendig
Für jede Regel kann die Fehlermeldung in mehreren Sprachen in den
Feldern Message_de, Message_fr,
Message_it und Message_en
angegeben werden. Die Sprache der Fehlermeldungen kann vom Benutzer des
Checkservice mit quote site set param language
<Sprachcode> gewählt werden.
Falls das gleiche Modell in mehreren Sprachen vorliegt (z.B.
DM01AVCH24D und MD01MOCH24F), muss
die Regeldatei nur für die Hauptsprache (z.B. de)
konfiguriert werden. Es kann aber sein, dass einzelne Tests trotzdem nur
für ein bestimmtes Modell formuliert werden können (z.B. der Vergleich
von Textattributwerten).
Beispiel:
Modelname Topicname Tablename Operator
DM01AVCH24D Liegenschaften LSNachfuehrung LIST,Beschreibung,GRUDA_Geschaeftstyp_de
MD01MOCH24F Liegenschaften LSNachfuehrung LIST,Beschreibung,GRUDA_Geschaeftsyp_fr
Im Beispiel, wird das Textattribut Beschreibung
mit einer vordefinierten Liste verglichen (s.a. Operator
LIST). Für das französische Modell soll eine andere
Liste als für das deutsche Modell verwendet werden.
![[Anmerkung]](images/note.png) | |
Der Test wird trotzdem nur mit den Topic-, Tabellen- und Attributnamen des Hauptmodells definiert. Falls die Benutzer des französischen Modells die Fehlermeldungen dennoch auf Deutsch erhalten möchten, muss man die Fehlermeldungen in beiden Sprachen formulieren. |