Ü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.
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.
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.
Required. Für erweiterte Szenarien — z. B. „Pflichtfeld nur bei Neuanlage“ (RequiredIfNew) oder „Wunschfeld“ (Wanted, nur Warnung) — verwenden Sie stattdessen eine explizite Validierungsregel.
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.
-
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“.
-
Tab „Regeln“ öffnen
Unterhalb des Eigenschaftenpanels finden Sie den Tab „Regeln“. Die Zahl in Klammern zeigt die Anzahl aktiver Regeln.
-
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). -
Parameter konfigurieren
Je nach Regeltyp stehen ein oder zwei Parameter zur Verfügung. Bei
PositiveOnlysind keine weiteren Parameter erforderlich. Bei einerRange-Regel würden Sie Minimum (Parameter 1) und Maximum (Parameter 2) angeben.
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. |
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.
Ü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 |
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 |
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.
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.
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
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. |
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.