Validierungsregeln in Jitterbit App Builder

Validierungen sind eine Regel Zweck, die zum Schutz der Datenintegrität verwendet wird. Sie können gegen Daten ausgeführt werden, die Endbenutzer manuell eingeben, und lehnen Datensätze ab, die gegen Geschäftslogik verstoßen (z. B. doppelte Datensätze). Wenn eine CRUD-Regel für ein Geschäftsobjekt definiert ist, werden ihre Validierungen auch automatisch ausgeführt, wenn diese CRUD-Regel ausgeführt wird. Validierungsmeldungen, die Benutzern angezeigt werden, sind konfigurierbar und unterstützen dynamische Substitution für ein besseres Benutzererlebnis.

Wie andere Regeln wird eine Validierungsregel in der Geschäftsschicht erstellt und wird erst wirksam, wenn sie bei einem Ereignis registriert wird. Eine vollständige Anleitung zum Erstellen einer Validierungsregel und deren Registrierung bei einem intrinsischen Ereignis finden Sie unter Validierungsregeln in Einführung in App Builder - Lektion 7: Mehr über Regeln und Validierungen in Anhang B für ein fortgeschritteneres Beispiel. Diese Seite behandelt die Felder des Dialogs Validierung im Detail sowie Best Practices, die bei der Arbeit mit Validierungsregeln zu beachten sind.

Validierung bei einem Ereignis registrieren

Sobald die WHERE-Klausel einer Validierungsregel die Daten definiert, die sie erfassen soll, registrieren Sie sie bei einem intrinsischen oder benutzerdefinierten Ereignis, damit sie ausgeführt wird. Klicken Sie im Panel Validierungen des Ereignisses auf Registrieren, um den Dialog Validierung zu öffnen:

Der Dialog Validierung enthält die folgenden Felder:

• Typ: Wählen Sie Regel, um eine Geschäftsregel als Validierung auszuführen, oder Plugin, um stattdessen ein vorgefertigtes Validierungs-Plugin zu verwenden, z. B. das Regex-Validierungs-Plugin.

• Regel: Wählen Sie die auszuführende Validierungsregel aus. Wird nur angezeigt, wenn Typ auf Regel eingestellt ist.

• Bindung: Wählen Sie Implizit oder Explizit. Siehe Implizite und explizite Bindung, um zu entscheiden, welche verwendet werden soll.

• Fehler: Wählen Sie Fehler bei zurückgegebenen Daten, wenn die Regel zum Auffinden fehlerhafter Daten geschrieben ist (der häufigste Ansatz). Wählen Sie Fehler bei keinen zurückgegebenen Daten, wenn die Regel stattdessen zum Auffinden guter Daten geschrieben ist, sodass keine zurückgegebenen Daten auf einen Fehler hindeuten.

• Schweregrad: Wählen Sie Fehler, um den Speichern vollständig zu blockieren, Warnung, um dem Benutzer die Wahl zu lassen, ob er fortfahren möchte, oder Information, um eine Meldung anzuzeigen, ohne den Workflow zu unterbrechen.

• Meldung: Geben Sie die Meldung ein, die dem Benutzer angezeigt wird, wenn die Validierung ausgelöst wird. Dieses Feld unterstützt dynamische Substitution mit {{ ColumnName }}-Platzhaltern. Jede ersetzte Spalte muss auch im Geschäftsobjekt verfügbar sein, bei dem das Ereignis registriert ist.

• Bezeichnung: (Optional) Geben Sie eine Bezeichnung ein, die im Ereignisdiagramm angezeigt werden soll. Verwendet den Regelnamen, wenn leer gelassen.

• Position: Legen Sie Reihenfolge fest, um die Ausführungsreihenfolge mehrerer Validierungen zu steuern, und Aktiv, um die Validierung zu aktivieren oder zu deaktivieren, ohne sie zu löschen.

• HTTP-Statuscode: (App Builder 4.65 und später) (Optional) Geben Sie den HTTP-Statuscode ein, der an den Aufrufer zurückgegeben werden soll, wenn diese Validierung fehlschlägt, während sie im Kontext eines Webhook-Aufrufs aufgerufen wird. Dieses Feld hat keine Auswirkung auf Validierungen, die im Kontext eines REST-API-Aufrufs (SNAPI) aufgerufen werden.

  Hinweis

  Wenn mehr als eine Validierung in derselben Ereigniskette mit einem konfigurierten HTTP-Statuscode fehlschlägt, wird nur der Wert aus der ersten ausgelösten Validierung in der Kette an den Aufrufer zurückgegeben. Wenn das Feld leer gelassen wird, gibt eine fehlgeschlagene Validierung normalerweise standardmäßig 400 (Bad Request) zurück; siehe Response Body Envelope für andere Standard-Statuscodes.

• Technische Hilfe: (Optional) Geben Sie eine Beschreibung der Validierung für andere Entwickler ein.

Best Practices und Empfehlungen

1. Verwenden Sie implizite Bindung für die meisten Validierungsregeln, da diese die Daten überprüft, die sich derzeit im Speicher auf dem Bildschirm des Benutzers befinden, bevor sie gespeichert werden. Reservieren Sie explizite Bindung für Fälle, in denen die Validierung Daten überprüfen muss, die bereits in der Datenbank gespeichert sind, z. B. eine XP-Validierungsregel, die Daten über eine andere Datenquelle hinweg validiert. Weitere Informationen finden Sie unter Implizite und explizite Bindung.

2. Wählen Sie das richtige Ziel für die Validierung, je nachdem, wo diese ausgeführt werden soll:

   • Wählen Sie die Tabelle als Ziel und registrieren Sie die Validierung auf ihrem Table Event Detail, wenn diese immer dann ausgeführt werden soll, wenn ein beliebiger Datensatz über ein beliebiges Geschäftsobjekt gespeichert wird, das auf diese Tabelle verweist.

   • Wählen Sie das Geschäftsobjekt als Ziel und registrieren Sie die Validierung auf seinem Rule Event Detail, wenn diese nur ausgeführt werden soll, wenn dieses spezifische Geschäftsobjekt verwendet wird.

   Weitere Informationen finden Sie unter Wo Events konfiguriert werden und Tabelle vs. Geschäftsobjekt.

3. Wenn eine Validierungsregel implizite Bindung verwendet, muss das Geschäftsobjekt, auf dem sie registriert ist, jede in der Regel referenzierte Spalte enthalten. App Builder benötigt diese Spalten, um ihre In-Memory-Werte erfolgreich zu ersetzen. Ein Beispielkonfiguration finden Sie im Duplikat-E-Mail-Validierungsbeispiel unten.

4. Der Schweregrad Warnung einer Validierung funktioniert nur, wenn die Validierung direkt durch das Panel oder UI-Event ausgelöst wird. Wenn eine Regel mit der Validierung stattdessen als Aktion innerhalb der Ausführung eines anderen Events ausgeführt wird (z. B. von einer übergeordneten Regel weiter oben in einer Event-Kette), steht an diesem Punkt keine Benutzeroberfläche zur Verfügung, um dem Benutzer eine Aufforderung zum Fortfahren oder Abbrechen anzuzeigen. Der Schweregrad der Validierung wird daher auf Fehler erhöht.

5. Verwenden Sie dynamische Ersetzung, um Validierungsmeldungen für Endbenutzer nützlicher zu gestalten. Fügen Sie den zu ersetzenden Wert als Spalte auf dem Geschäftsobjekt hinzu, auf dem das Event registriert ist, und verweisen Sie dann im Feld Nachricht der Validierung mit der Syntax {{ ColumnName }} darauf.

6. Wenn Sie eine Validierungsregel erstellen, die mehr als einmal auf eine Tabelle oder mehrere Geschäftsobjekte verweist, die auf derselben Tabelle basieren, z. B. eine Regel, die überprüft, ob die E-Mail-Adresse eines neuen Datensatzes eine bereits in dieser Tabelle gespeicherte E-Mail-Adresse dupliziert (wie im Beispiel unten), fügen Sie die Zieltabelle ein zweites Mal hinzu. Tun Sie dies auf der Registerkarte „Tabellen" der Regel, während Sie die Regel im Rule Builder erstellen. Dies stellt sicher, dass der neue Datensatz tatsächlich validiert wird, da die implizite Bindung von App Builder automatisch nur die erste Instanz dieser Tabelle durch den bearbeiteten In-Memory-Datensatz ersetzt. Ohne eine zweite unveränderte Instanz hätte die Regel keine echten gespeicherten Daten zum Vergleich mit dem neuen Datensatz, und die Validierung würde das Duplikat, das sie erkennen soll, nie erfassen.

   Hinweis

   Das gleiche Risiko tritt auf, wenn eine Validierungsregel mehr als ein Geschäftsobjekt verwendet, die alle auf dieselbe Tabelle wie das Panel oder Event verweisen, das die Validierung auslöst. Im Gegensatz zu einer zweimal hinzugefügten Tabelle, bei der nur die erste Instanz ersetzt wird, wird jedes dieser Geschäftsobjekte durch den In-Memory-Datensatz ersetzt, da App Builder keine Möglichkeit hat, zwischen ihnen zu unterscheiden. Wenn Sie benötigen, dass eines von ihnen die echten gespeicherten Daten widerspiegelt, z. B. um die gleiche Art von Duplikatprüfung auszuführen, wählen Sie stattdessen eine andere Tabelle als die vom Panel oder Event verwendete. Da diese nicht übereinstimmt, ersetzt App Builder sie nie.

Beispiel: Duplikat-E-Mail-Validierungsregel

Dieses Beispiel zeigt eine Validierungsregel, die den oben beschriebenen „In-Memory"-Ansatz verwendet und eine vom Benutzer eingegebene E-Mail-Adresse gegen die bereits in der Tabelle für andere Konten gespeicherten Werte überprüft. Da die Regel implizite Bindung verwendet, müssen alle ihre referenzierten Spalten im Geschäftsobjekt vorhanden sein, auf dem sie registriert ist, damit App Builder die In-Memory-Werte in die Logik der Regel einfügen kann:

1. Eine Validierungsregel namens tcAccount (Validation) (Duplicate Email) wird im Rules-Tab der App Workbench erstellt.

2. Die Validierungsregel zielt zweimal auf die Tabelle tcAccount ab: einmal als TA (der In-Memory-Datensatz, der ersetzt wird) und einmal als TA2 (die vorhandenen gespeicherten Datensätze zum Vergleich).

   

3. Die WHERE-Klausel der Validierungsregel wird so konfiguriert, dass die Spalten Email und AccountTypeID zwischen den beiden Tabelleninstanzen verglichen werden, um ein Duplikat zu erkennen.

   

4. Im Joins-Tab der Regel werden die beiden tcAccount-Instanzen auf AccountID verknüpft, wobei Übereinstimmungen zwischen einem Datensatz und sich selbst ausgeschlossen werden.

   

5. Abschließend wird die Regel mit impliziter Bindung an ein Ereignis angehängt, wobei der Schweregrad auf Fehler eingestellt ist.