5.6 Regeln & Validierung — Datenqualität sicherstellen

5.6 Regeln & Validierung — Datenqualität sicherstellen

Konfigurieren Sie Validierungsregeln für Dialoge und Entitäten — von Pflichtfeldern über Wertebereiche bis hin zu komplexen Geschäftsregeln per DynamicCode.

1

Überblick

Validierungsregeln stellen sicher, dass Daten bestimmte Kriterien erfüllen, bevor sie gespeichert werden. UDM unterstützt dabei zwei Ebenen:

  • Dialog-Regeln (Client-Validierung) — werden direkt im Bearbeitungsdialog geprüft, noch bevor die Daten an den Server gesendet werden. Der Anwender erhält sofortiges Feedback.
  • Entity-Regeln (Server-Validierung) — werden serverseitig beim Speichern geprüft. Sie greifen unabhängig vom Dialog, z. B. auch bei Importen oder API-Zugriffen.

Typische Anwendungsfälle sind Pflichtfelder, Wertebereiche, Format-Prüfungen (E-Mail, IBAN), Eindeutigkeitsprüfungen und komplexe Geschäftsregeln per DynamicCode.

Unser Beispiel für diese Anleitung
Pflichtfelder und Plausibilitätsprüfung für Rechnungen

Ein Rechnungsdialog soll folgende Regeln erhalten: Das Rechnungsdatum darf nicht in der Vergangenheit liegen, der Betrag muss größer als 0 sein, und das Feld Kunde ist ein Pflichtfeld. Zusätzlich soll per DynamicCode geprüft werden, dass das Fälligkeitsdatum nach dem Rechnungsdatum liegt.

2

Schritt 1: Pflichtfeld-Eigenschaft setzen

Die einfachste Form der Validierung ist das Pflichtfeld. Sie können ein Feld auf zwei Wegen als Pflichtfeld markieren:

  • Auf Entity-Ebene — in der Spaltenkonfiguration der Entität. Gilt dann für alle Dialoge, die dieses Feld verwenden.
  • Auf Dialog-Ebene — im Dialog-Designer für ein einzelnes Dialogelement. Gilt nur für diesen spezifischen Dialog.

In unserem Beispiel: Öffnen Sie den Rechnungsdialog im Dialog-Designer, wählen Sie das Element „Kunde“ aus und aktivieren Sie die Eigenschaft „Pflichtfeld“ im Eigenschaftenpanel.

Tipp: Pflichtfeld vs. Required-Regel Die Pflichtfeld-Eigenschaft ist eine Kurzform für die Validierungsregel Required. Für erweiterte Szenarien — z. B. „Pflichtfeld nur bei Neuanlage“ (RequiredIfNew) oder „Wunschfeld“ (Wanted, nur Warnung) — verwenden Sie stattdessen eine explizite Validierungsregel.
3

Schritt 2: Validierungsregel definieren

Für Regeln, die über ein einfaches Pflichtfeld hinausgehen, wechseln Sie im Dialog-Designer auf den Tab „Regeln“ des ausgewählten Elements.

  1. Element im Dialog-Designer auswählen

    Klicken Sie auf das Dialogelement, für das Sie eine Regel definieren möchten — in unserem Beispiel das Feld „Betrag“.

  2. Tab „Regeln“ öffnen

    Unterhalb des Eigenschaftenpanels finden Sie den Tab „Regeln“. Die Zahl in Klammern zeigt die Anzahl aktiver Regeln.

  3. Neue Regel hinzufügen

    Klicken Sie auf „Regel hinzufügen“. Wählen Sie den Regeltyp aus der Dropdown-Liste — für den Betrag wählen wir PositiveOnly (nur positive Werte, größer 0).

  4. Parameter konfigurieren

    Je nach Regeltyp stehen ein oder zwei Parameter zur Verfügung. Bei PositiveOnly sind keine weiteren Parameter erforderlich. Bei einer Range-Regel würden Sie Minimum (Parameter 1) und Maximum (Parameter 2) angeben.

AdminClient → Tab „Regeln“ → PositiveOnly für Feld „Betrag“
Validierungsregel
Feld
Betrag
Regeltyp
PositiveOnly
Parameter 1
Parameter 2
Schweregrad
Error
Fehlermeldung
Der Rechnungsbetrag muss größer als 0 sein.
Aktiv
ja
Hinweis: Server-Regeln (UniqueInTable, DateRangeNoOverlap) werden ausschließlich auf Entity-Ebene konfiguriert.
4

Schritt 3: Fehlermeldung konfigurieren

Jede Regel erzeugt im Fehlerfall eine Meldung. UDM generiert automatisch eine Standardmeldung basierend auf dem Regeltyp. Sie können jedoch eine benutzerdefinierte Fehlermeldung hinterlegen, die für Ihre Anwender verständlicher ist.

In unserem Beispiel: Für die PositiveOnly-Regel am Feld „Betrag“ hinterlegen wir die benutzerdefinierte Meldung: Der Rechnungsbetrag muss größer als 0 sein.

Zusätzlich können Sie den Schweregrad festlegen:

Schweregrad Verhalten
Error Speichern wird blockiert. Der Anwender muss den Fehler korrigieren.
Warning Warnung wird angezeigt, Speichern ist dennoch möglich.
Info Hinweis wird angezeigt, keine Auswirkung auf das Speichern.
Tipp: Anwenderfreundliche Fehlermeldungen Formulieren Sie Fehlermeldungen aus Sicht des Anwenders. Statt „Wert muss > 0 sein“ schreiben Sie besser „Bitte geben Sie einen positiven Betrag ein.“ Vermeiden Sie technische Begriffe wie „Constraint“ oder „Validation“.
UserClient → Rechnungsdialog: Pflichtfeld leer, Betrag negativ — Validierung greift
Rechnung bearbeiten
Kunde *
— bitte auswählen —
Pflichtfeld — Bitte wählen Sie einen Kunden aus.
Rechnungsdatum
04.05.2026
Fälligkeit
18.05.2026
Betrag
-150,00
Der Rechnungsbetrag muss größer als 0 sein.
Notiz
💾 Speichern × Abbrechen
5

Schritt 4: Komplexe Validierung per DynamicCode

Für Geschäftsregeln, die über die deklarativen Regeltypen hinausgehen, steht DynamicCode zur Verfügung. Damit können Sie beliebige C#-Logik als Validierung hinterlegen.

In unserem Beispiel: Das Fälligkeitsdatum muss nach dem Rechnungsdatum liegen. Dafür verwenden wir entweder die eingebaute Regel DateGreaterThanField (mit Verweis auf das Vergleichsfeld) oder — bei komplexerer Logik — einen DynamicCode-Block.

Verweis Die Erstellung und Verwaltung von DynamicCode wird in der separaten Anleitung „Dynamischer Code“ ausführlich beschrieben. Dort finden Sie auch Beispiele für Validierungslogik mit Zugriff auf andere Felder und externe Datenquellen.
6

Übersicht der Validierungstypen

UDM bietet eine Vielzahl deklarativer Regeltypen, gruppiert nach Kategorie:

Wertpräsenz

Regeltyp Beschreibung Parameter
Required Feld muss einen Wert haben (blockiert Speichern)
Wanted Feld sollte einen Wert haben (nur Warnung)
RequiredIfNew Pflichtfeld nur bei Neuanlage eines Datensatzes

Text & Format

Regeltyp Beschreibung Parameter
MinLength / MaxLength Mindest- bzw. Maximalanzahl Zeichen Parameter 1: Zeichenanzahl
RegexPattern Wert muss einem regulären Ausdruck entsprechen Parameter 1: Regex-Pattern
EmailFormat Gültige E-Mail-Adresse
IbanFormat Gültige IBAN

Numerisch & Wertebereich

Regeltyp Beschreibung Parameter
Range Wert muss zwischen Minimum und Maximum liegen P1: Min, P2: Max
PositiveOnly Nur positive Werte (größer 0)
NonNegative Null oder positiv (größer gleich 0)
IntegerOnly Nur Ganzzahlen

Datum & Eindeutigkeit

Regeltyp Beschreibung Parameter
DateInFuture Datum muss in der Zukunft liegen
DateNotInPast Datum darf nicht in der Vergangenheit liegen (heute erlaubt)
DateGreaterThanField Datum muss größer als ein Vergleichsfeld sein Vergleichsfeld
UniqueInTable Wert muss in der Tabelle eindeutig sein Server
UniqueInScope Eindeutig innerhalb eines Scopes Server Vergleichsfeld (Scope)
UniqueComposite Kombination mehrerer Felder muss eindeutig sein (z. B. Datum + DienstId) Server Kombinierte Felder (kommagetrennt)
DateRangeNoOverlap Datumsbereich darf sich nicht mit bestehenden Datensätzen überschneiden Server Enddatum-Feld, optional Scope & Puffer
Filter „Prüfung bei“ — Alle vier Server-Regeln (UniqueInTable, UniqueInScope, UniqueComposite, DateRangeNoOverlap) bieten einen optionalen Filter „Prüfung bei“. Damit grenzen Sie ein, welche Datensätze überhaupt für die Prüfung herangezogen werden — z. B. nur aktive Datensätze, sodass stornierte oder archivierte Einträge die Eindeutigkeit nicht blockieren.

Benutzerdefiniert

Regeltyp Beschreibung Parameter
Expression Benutzerdefinierter C#-Ausdruck, der true (OK) oder false (Fehler) zurückgibt DynamicCode-Referenz
Achtung: Client- vs. Server-Validierung Regeln vom Typ UniqueInTable, UniqueInScope, UniqueComposite und DateRangeNoOverlap werden ausschließlich serverseitig geprüft, da sie Datenbankabfragen erfordern. Diese Regeln werden auf Entity-Ebene konfiguriert und greifen unabhängig davon, über welchen Dialog oder Kanal die Daten gespeichert werden.
7

Entity-Regeln (Server-Validierung)

Neben den Dialog-bezogenen Regeln können Sie Validierungsregeln auch direkt auf Entity-Ebene definieren. Diese gelten global und werden bei jedem Speichervorgang serverseitig geprüft — unabhängig davon, ob die Daten über einen Dialog, einen Import oder eine API-Schnittstelle eingehen.

Entity-Regeln konfigurieren Sie in der Entitäten-Verwaltung im Bereich „Server-Regeln“. Dort wählen Sie das Feld und den Regeltyp aus — die verfügbaren Regeltypen sind identisch mit den Dialog-Regeln.

8

Regeln aktivieren und deaktivieren

Jede Regel besitzt einen Aktiv-Schalter. Damit können Sie eine Regel temporär deaktivieren, ohne sie zu löschen. Dies ist nützlich bei:

  • Datenmigration — bestimmte Prüfungen vorübergehend aussetzen
  • Fehlerbehebung — gezielt einzelne Regeln testen
  • Stufenweiser Einführung — Regeln vorbereiten und später scharfschalten
9

Häufige Fragen

Frage Antwort
Wo sehe ich alle Regeln eines Dialogs? Im Dialog-Designer können Sie den Tab „Regeln“ für jedes Element einzeln öffnen. Die Zahl in Klammern zeigt die Anzahl aktiver Regeln. Zusätzlich gibt es in der Verwaltung unter „Regeln“ eine Gesamtübersicht aller Validierungsregeln.
Kann ich dieselbe Regel mehrfach anlegen? Ja. Sie können z. B. zwei Range-Regeln mit unterschiedlichen Schweregraden konfigurieren — eine als Warnung (0–100) und eine als Fehler (Minimum 0).
Werden Regeln auch bei Importen geprüft? Entity-Regeln (Server-Validierung) greifen bei jedem Speichervorgang, also auch bei Datenimporten. Dialog-Regeln gelten nur für den jeweiligen Bearbeitungsdialog.
Was passiert bei widersprüchlichen Regeln? Alle konfigurierten Regeln werden unabhängig voneinander geprüft. Widersprüchliche Regeln (z. B. „Wert muss > 100 sein“ und „Wert muss < 50 sein“) führen dazu, dass kein gültiger Wert eingegeben werden kann. Prüfen Sie Ihre Regelkombinationen daher sorgfältig.
Wie teste ich meine Regeln? Öffnen Sie den Dialog im Anwender-Client und versuchen Sie, ungültige Werte zu speichern. Die Fehlermeldungen erscheinen direkt am betroffenen Feld.
Kann ich die Prüfung auf bestimmte Datensätze einschränken? Ja. Server-Regeln (UniqueInTable, UniqueInScope, UniqueComposite, DateRangeNoOverlap) bieten den Filter „Prüfung bei“. Nur Datensätze, die diesem Filter entsprechen, werden für die Eindeutigkeits- bzw. Überlappungsprüfung herangezogen — z. B. Status = aktiv, um stornierte Einträge zu ignorieren.
10

AllowNull-Schalter

Der neue AllowNull-Schalter legt fest, ob ein Feld NULL-Werte (leere Werte) zulässt. Wenn deaktiviert, wird beim Speichern eine Validierungsmeldung angezeigt, falls das Feld leer ist.

Der AllowNull-Schalter ist eine einfachere Alternative zu einer Pflichtfeld-Validierungsregel und kann direkt in den Feldeinstellungen konfiguriert werden.