Prüfregeln

Pflicht, Typ und Werteliste prüft jedes Feld für sich. Was mehrere Felder zusammen betrifft, prüfen Prüfregeln im Reiter Validierung: Das Ende liegt nach dem Beginn, der Rabatt übersteigt nicht den Betrag, eine abgelehnte Entscheidung hat eine Begründung. Eine Regel gilt als erfüllt, wenn ihr Ausdruck wahr ist; sonst lehnt Pantarey das Speichern ab, mit der Meldung, die hier hinterlegt wird.

Reiter „Validierung“ mit einer Regel für den Urlaubsantrag.

Regel anlegen

1. Im Daten Designer das Schema öffnen, Reiter Validierung, Regel hinzufügen.
2. Sprache: JSONata oder JavaScript.
3. Ausdruck, der wahr oder falsch ergibt. JSONata etwa bis >= von; JavaScript als Funktionskörper mit return, etwa return $.betrag > 0; mit $, obj und root als Datensatz.
4. Fehlermeldung (Deutsch) und Fehlermeldung (Englisch). Feldwerte werden mit $(feldname) eingesetzt: „Bis $(bis) darf nicht vor Von $(von) liegen.“
5. Optional Beschreibung als interne Notiz. Änderungen speichert der Reiter von selbst.

Der Schalter Aktiv / Inaktiv schaltet eine Regel ab, ohne sie zu löschen; der Papierkorb entfernt sie.

Wo geprüft wird

Wo	Wann	Was passiert
Datenbank, Dialoge „anlegen“ und „Daten ändern“	JSONata-Regeln bei jeder Eingabe, alle Regeln beim Speichern	Banner „Bitte Eingaben prüfen“ mit den Meldungen; Speichern gesperrt
Startformular eines Prozesses	bei jeder Eingabe auf dem Server	Start gesperrt, solange eine Regel verletzt ist
Benutzeraufgabe im Prozess	beim Schreiben über das Datenbank-Element	der Schritt scheitert mit der Meldung
Prozesse, Importe, KI-Assistenten	beim Speichern	Ablehnung mit den Meldungen

Die Regeln gelten also überall gleich; nirgends kommt ein Datensatz vorbei, der sie verletzt. Berechnete Felder und Ersatzwerte sind beim Prüfen schon gesetzt und dürfen in Regeln vorkommen.

Leere Felder absichern

Ein JSONata-Ausdruck über ein leeres Feld liefert kein Ergebnis. Live im Formular wird das übersprungen, beim Speichern gilt es als Fehler der Regel und das Speichern scheitert. Deshalb leere Felder ausdrücklich erlauben:

$not($exists(ende)) or ende >= beginn

status != 'abgelehnt' or $length($trim(begruendung)) > 0

rabatt = null or rabatt <= betrag

Beispiele

Regel	JSONata	Meldung
Zeitraum stimmt	bis >= von	Bis $(bis) darf nicht vor Von $(von) liegen.
Ablehnung begründen	status != 'abgelehnt' or $exists(begruendung)	Eine Ablehnung braucht eine Begründung.
Summe der Positionen	$count(positionen) > 0	Mindestens eine Position angeben.
Fälligkeit nach Rechnungsdatum	faellig_am >= rechnungsdatum	Fällig am $(faellig_am) liegt vor dem Rechnungsdatum.
Höchstens 30 Tage	$fn('date_workdays', von, bis) <= 30	Mehr als 30 Arbeitstage am Stück sind nicht vorgesehen.

Mit dem KI-Assistenten

Ein verbundener Assistent legt Prüfregeln im Entwicklermodus an und muss dafür Testdatensätze mitgeben, die die Regel bestehen und verletzen sollen; so wird eine Regel nie blind gespeichert. Er kann außerdem einen Datensatz prüfen, ohne ihn zu speichern, und meldet dann die verletzten Regeln.

Beispiel

Der Urlaubsantrag der Musterfirma bekommt die Regel bis >= von mit der Meldung „Bis $(bis) darf nicht vor Von $(von) liegen.“ Wer im Startformular den 20.3. als Von und den 18.3. als Bis einträgt, sieht die Meldung sofort unter dem Formular; der Prozess startet erst, wenn die Daten stimmen.

Häufige Fragen

Die Regel meldet im Formular nichts, aber das Speichern scheitert.

JavaScript-Regeln laufen nur auf dem Server. Für eine Live-Meldung die Regel in JSONata schreiben.

Alte Datensätze verletzen eine neue Regel.

Sie bleiben gespeichert und lesbar. Beim nächsten Bearbeiten greift die Regel. Einträge aktualisieren im Reiter Aktionen speichert alle neu und bricht bei Verstößen ab; vorher die Daten bereinigen.

Gilt die Regel auch für abgeleitete Schemas?

Nein, jedes Schema hat seine eigenen Regeln. Für gemeinsame Regeln die Regel in jedem abgeleiteten Schema anlegen.

Nächster Schritt

Formulare: was das automatische Formular kann und welche besonderen Felder eigene Formulare haben.