Skip to main content

Datenvalidierung in Dev Studio

Datenvalidierung und Dev Studio

Sie können in App Studio Validierungsbedingungen konfigurieren, die einen True/False-Vergleich zwischen dem Wert eines Feldes und einem Festwert oder dem Wert eines anderen Feldes durchführen. Für komplexere Validierungsszenarien werden möglicherweise weitere Funktionen benötigt, die von Validierungsregeln in Dev Studio bereitgestellt werden.

Die folgenden Szenarien erfordern ein Verhalten, das nur in Dev Studio konfiguriert werden kann:

  • Wenn ein Kunde aus Kanada seine Adresse eingibt, muss die Postleitzahl im Standardformat für kanadische Postleitzahlen eingegeben werden.
  • Wenn ein Investor ein Investmentkonto eröffnet, wird er aufgefordert, einen Fragebogen auszufüllen, um seinen Erfahrungsstand zu bestimmen. Nur Personen mit umfassender Erfahrung im Investmentbereich können über ihr Konto Margenhandel betreiben.
  • Wenn jemand eine Krankenversicherung abschließen möchte, muss er vorab eine Einverständniserklärung hochladen, dass seine Gesundheitsdaten gegenüber Dritten offengelegt werden dürfen.

Validate – Validierungsregeln

Mit Validate-Regeln wird sichergestellt, dass die von Anwendern angegebenen Daten die für die Case-Fortführung erforderlichen Bedingungen erfüllen. Durch das Zuweisen von Validierungsregeln zu Ablaufaktionen können Sie verhindern, dass Benutzer Daten eingeben, die die Anwendung nicht verarbeiten kann, und so die Zahl der Verarbeitungsfehler verringern.

In Dev Studio können Sie die Validierungsregeln, die in App Studio automatisch erstellt werden, erweitern. Außerdem können Sie in der Kategorie „Process“ neue Validierungsregeln erstellen.

Edit Validate – Bearbeitungsvalidierungsregeln

Edit Validate-Regeln werden meistens auf Eigenschaften angewendet und bestehen aus Java-Code, der den Wert einer Eigenschaft mit einem definierten Muster vergleicht. Zum Beispiel kann eine Bearbeitungsvalidierungsregel prüfen, ob ein Eigenschaftswert aus sieben Zahlen besteht, wobei die dritte und vierte Zahl durch ein Leerzeichen getrennt sind. Stimmen die Muster überein, wird die Eingabe als gültig betrachtet. Andernfalls kennzeichnet das System die Eingabe als fehlerhaft.

Vorsicht: Da mit Bearbeitungsvalidierungsregeln benutzerdefiniertes Java in eine Anwendung eingeführt werden kann, stellen „Edit Validate“-Regeln ein potenzielles Sicherheitsrisiko für Ihre Anwendung dar.

Bearbeitungsvalidierungsregeln werden für die clientseitige Validierung verwendet. Das bedeutet, dass von Anwendern eingegebene Werte sofort validiert werden, ohne auf den Server zu referenzieren. Die Validierung erfolgt, wenn Anwender eine Änderung am eingegebenen Wert vornehmen. Um eine Bearbeitungsvalidierungsregel auf eine Eigenschaft anzuwenden, referenzieren Sie die Bearbeitungsvalidierungsregel im Eigenschaftsregelformular, Tab „Advanced“ im Feld Use validate.

Tipp: Sie können eine Bearbeitungsvalidierungsregel auch über eine Validierungsregel aufrufen. Wenn Sie eine „Edit Validate“-Regel von einer Validierungsregel aus aufrufen, erfolgt die Validierung, wenn das System die „Validate“-Regel ausführt, also sobald der Benutzer das Formular absendet. 

Anwendungsfall: Per Business-Logik gesteuerte Anforderungen an das Datenformat

Mit einer Business-Logik können Sie festlegen, dass die Benutzereingabe bestimmte Standards erfüllen muss. Beispiel: Eine Organisation muss sicherstellen, dass die von einem Benutzer eingegebenen Kontaktinformationen gültig sind, ehe sie die Informationen erfasst. Bevor eine Anwendung bestätigen kann, dass Postleitzahl, E-Mail-Adresse oder Telefonnummer eines Benutzers korrekt sind, muss sie bestätigen, dass die Eingabe des Benutzers einem bestimmten Format folgt, wobei dieses Format je nach Standort des Benutzers unterschiedlich sein kann.

Im folgenden Beispiel wird eine Bearbeitungsvalidierungsregel über eine Validierungsregel angewendet, um sicherzustellen, dass ein Benutzer eine Postleitzahl eingibt, die mit dem ZIP-Code-Format der USA übereinstimmt, das fünf numerische Zeichen verlangt.

Validate rule configured to validate a provided postal code against the United State ZIP Code standard of 5 numerical digits

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.

Anwendungsfall: Validierungsqualifizierung auf Basis eines Eingabewerts

Eine Business-Logik erfordert möglicherweise, dass Daten je nach vorliegender Bedingung, wie z. B. Benutzereingabe, Benutzeraktion, Case-Status oder Case-Stage, auf unterschiedliche Arten von einer Anwendung validiert werden. Dies kann mit einer Validierungsregel erreicht werden.

Stellen Sie sich einen Case-Typ zur Eröffnung eines neuen Investmentkontos vor. Ein Finanzdienstleister bietet seinen Kunden die Möglichkeit, Aktien auf Marge zu handeln. Zu diesem Zweck verleiht er Geld an die Kunden, damit sie Aktienkäufe oder andere zulässige Investitionen tätigen können. Um einen solchen Margenkredit zu erhalten, muss der Kunde ein bestimmtes Kredit-Sicherheiten-Verhältnis von z. B. 30 % vorweisen. Das Unternehmen möchte sicherstellen, dass der Kunde den Margenkredit verantwortungsbewusst nutzt, und das Risiko eines Margenausgleichs, einer Aufforderung zur Bereitstellung zusätzlicher Mittel oder eines Verkaufs von Investments zur Wiederherstellung des Kredit-Sicherheiten-Verhältnisses automatisch begrenzen. Investoren mit einschlägiger Erfahrung im Investmentbereich stellen ein geringes Risiko für einen Margenausgleich dar, während das Risiko bei Investoren mit nur wenig Erfahrung deutlich höher ist. Zudem ist es nicht möglich, Margenhandel über Konten mit jährlichen Beitragsgrenzen, wie beispielsweise Pensionskonten, zu betreiben. Um diese Anforderung zu erfüllen, können Sie die Validierungslogik auf Basis der Kontoart und des Erfahrungsstands konditionalisieren.

Für die Qualifizierung der Validierungslogik verwenden Sie den Tab Input der Validierungsregel und legen durch Auswahl einer der dort verfügbaren Optionen den Qualifizierungstyp fest.

Options available on the Input tab of a validate rule
  • Input property: Die Validierungsqualifizierung erfolgt auf Basis der vom Benutzer eingegebenen Daten. Im Beispiel mit dem neuen Investmentkonto werden die Felder „Experience Level“ und „Account Type“ verwendet, um die Validierungslogik zu spezifizieren.
  • Proposed work status: Die Validierungsqualifizierung erfolgt auf Basis des Status, den die Anwendung dem Case zuordnet. Beispiel: Die Beantragung einer Kreditkarte basiert zum Teil auf dem Bonitätswert des Kunden. Für den Status Pending-Qualification kann der Bonitätswert bei gerade einmal 600 liegen, während ein Statuswechsel zu Approved einen Bonitätswert von mindestens 725 erfordert.
  • Flow action: Die Validierungsqualifizierung erfolgt auf Basis der von einem Benutzer durchgeführten Aktion. Beispiel: In einem Formular mit Mitarbeiterinformationen muss das Einstellungsdatum angegeben werden. Wenn der Benutzer den Onboarding-Prozess für einen neuen Mitarbeiter ausführen möchte, muss das Einstellungsdatum in der Zukunft liegen. Möchte der Benutzer hingegen die jährliche Mitarbeiterbeurteilung durchführen, muss das Einstellungsdatum in der Vergangenheit liegen.
  • Stages: Die Validierungsqualifizierung erfolgt auf Basis der aktuellen Case-Stage. Beispiel: Um ein Hypotheken- oder Eigenheimdarlehen zu beantragen, muss der Kunde sein Jahreseinkommen angeben. Während der Stage Submission fordert die Anwendung den Benutzer zur Angabe seines geschätzten Einkommens auf. Bei der Stage Approval muss der Schätzwert durch einen bestätigten, konkreten Wert ersetzt werden.
Hinweis: Eine auf Basis einer Eingabe qualifizierte Validierung, die von der Case-Stage abhängig ist, kann in App Studio als Validierung für den Übergang in eine Stage konfiguriert werden. Die anderen Optionen einer auf Basis einer Eingabe qualifizierten Validierung können nur in Dev Studio konfiguriert werden.

Im folgenden Beispiel geht es um eine auf Basis einer Eingabe qualifizierte Validierung. Der in der Liste Experience level ausgewählte Wert für den Erfahrungsstand bestimmt die Validierungsbedingung, die beim Absenden des Formulars angewendet wird. Wenn der Benutzer Experienced oder Professional auswählt, ist der Margenhandel zulässig und das Kontrollkästchen zur Freischaltung des Margenhandels wird nicht validiert. Wählt der Benutzer hingegen Limited aus, wird eine Fehlermeldung angezeigt, wenn er die Checkbox zur Freischaltung des Margenhandels aktiviert.

Verschieben Sie in der Mitte des folgenden Bildes die vertikale Linie, um die Konfiguration der eingangsqualifizierten Validierung und das Ergebnis anzuzeigen.

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.

Anwendungsfall: Zusätzliche Vergleichsoperationen

App Studio unterstützt True/False-Vergleiche zwischen zwei Eigenschaftswerten oder einem Eigenschaftswert und einer Konstanten. In Fällen, in denen Sie diese Art des Vergleichs nicht konfigurieren können, können Sie in Dev Studio über das Formular der Validierungsregel auf eine Bibliothek mit Validierungsfunktionen zugreifen. Sie können beispielsweise eine Funktion verwenden, um zu prüfen, ob ein Datum in die letzten vier oder acht Wochen fällt, oder um zu prüfen, ob ein Benutzer einen bestimmten Anhang für einen Case hochgeladen hat. Jede Funktion stellt einen benutzerdefinierten Satz von Feldern dar, mit denen das Validierungsverhalten konfiguriert werden kann.

Das folgende Beispiel zeigt die Verwendung einer Funktion zur Konfiguration der Validierung. Die Regel Validate verwendet die Funktion A [attachment category] is [attached/not attached] to the current case, um sicherzustellen, dass der Benutzer beim Onboarding eines neuen Mitarbeiters ein Dokument als Identitätsnachweis an den Case anhängt.

Verschieben Sie in der Mitte des folgenden Bildes die vertikale Linie, um die Konfiguration der Anlagenüberprüfung und das Ergebnis anzuzeigen.

Prüfen Sie mit der folgenden Interaktion Ihr Wissen.


Dieses Thema ist in den folgenden Modulen verfügbar:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Fanden Sie diesen Inhalt hilfreich?

38% fanden diesen Inhalt hilfreich

Möchten Sie uns dabei helfen, diesen Inhalt zu verbessern?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice