Validierungstipps im Jitterbit App Builder

Validierungsregeln im App Builder schützen Ihre Daten vor unerwünschter oder unsachgemäßer Datenmanipulation. Validierungsregeln werden im Business-SQL-Bereich der Business-Logik-Schicht konfiguriert und können nach ihrer Konfiguration in der Anwendung verwendet werden, indem sie als Steuerelemente zu Seitenbereichen hinzugefügt werden.

Dieser Artikel enthält Best Practices und Empfehlungen für die Arbeit mit Validierungen im App Builder. Validierungen dienen dem Schutz der Datenintegrität. Sie können für manuell eingegebene Daten ausgeführt werden und verhindern, dass Benutzer Datensätze hinzufügen, die gegen die Geschäftslogik verstoßen (z. B. doppelte Datensätze). Validierungsregeln können auch in der Geschäftslogik-Schicht verwendet werden. Wenn eine CRUD-Regel als Geschäftsschicht festgelegt ist, werden Validierungen auch bei Ausführung dieser CRUD-Regel ausgeführt.

Den Endbenutzern angezeigte Validierungsnachrichten sind konfigurierbar und können zur Verbesserung der Benutzererfahrung dynamische Ersetzungen nutzen.

Tutorial zu Validierungsregeln

Bewährte Methoden und Empfehlungen

1. In 99 % der Fälle sollten Sie implizite Bindung verwenden. Explizite Bindung wird für XP-Validierungen (z. B. an eine REST- API) verwendet. Explizite Bindung darf Ihre Validierung nicht beeinträchtigen.

2. Ihre Validierung sollte entweder auf die Tabelle oder das Panel-Datenobjekt abzielen. Wenn Sie die Registrierung auf Tabellenebene durchführen möchten, sodass sie immer dann ausgeführt wird, wenn ein Datensatz über ein Datenobjekt gespeichert wird, müssen Sie die Tabelle als Ziel verwenden und sich auf Tabellenebene registrieren. Wenn Sie sich auf das Datenobjekt registrieren möchten, müssen Sie das Datenobjekt als Ziel verwenden.

3. Der eigentliche Trick besteht darin, herauszufinden, wie der temporäre/neue („In-Memory“) Datensatz in der Validierungsregel referenziert wird, um ihn mit vorhandenen Zeilen abzugleichen. App Builder ersetzt in den folgenden Szenarien jedes Geschäftsobjekt durch den neuen Datensatz:

   1. Ersetzt die erste Zieltabelle, die der Validierungsregel hinzugefügt wurde. Die zweite bleibt unberührt. Dies ist die Reihenfolge, in der sie hinzugefügt wurden.
   2. Ersetzt alle Datenobjekte, die auf dieselbe Zieltabelle abzielen wie das Panel/Ereignis.
      • Siehe Abschnitt „Ersatzszenarien“ weiter unten.

   Wichtig

   Dies ist besonders wichtig, wenn Sie einen Datensatz anhand vorhandener Datensätze validieren möchten. In diesem Fall müssen Sie die Zieltabelle zweimal hinzufügen oder ein Geschäftsobjekt hinzufügen, das nicht auf dieselbe Tabelle abzielt, auf die das Ereignis abzielt.

4. Wenn Sie eine Validierungsregel erstellen, die den „In-Memory“-Ansatz verwendet, muss das Geschäftsobjekt, von dem die Validierungsregel registriert wird, alle in der Validierungsregel referenzierten Spalten enthalten, um alle Spaltenwerte erfolgreich zu „ersetzen“.

   • Eine Beispielkonfiguration finden Sie weiter unten im Beispiel „Email-Duplikat „im Arbeitsspeicher“.

5. Validierungen, die durch in Aktionen ausgeführte Geschäftsregeln ausgelöst werden, können keine Bestätigungen durchführen. Sie werden als Fehler gewertet. Es ist nicht möglich, ein Top-Level-Ereignis nur halb auszuführen, etwas zu bestätigen und es dann weiter auszuführen.

6. App Builder unterstützt dynamische Ersetzungen in den Nachrichten für Validierungen. Sie müssen lediglich den zu ersetzenden Wert im Datenobjekt des Panels angeben, auf dem die Validierung ausgeführt wird. Anschließend {{Value}} im Nachrichtenfeld der Validierung.

Ersatzszenarien:

• Kunde, Kunde (Quelle A), Kunde (Quelle B): alles wird ersetzt
• Kunde, Kunde: Der erste Kundentisch wird ausgetauscht
• Kunde (Quelle A), Kunde (Quelle B): Alle werden ersetzt
• Kunde, Kunde (Quelle A), Kunde (ich ziele nicht auf Kunde ab): Kunde und Kunde (Quelle A) werden ersetzt

Beispiel für eine Validierungsregel für doppelte Email „im Arbeitsspeicher“:

Dieses Beispiel veranschaulicht den In-Memory-Validierungsansatz. Dabei wird der vom Benutzer eingegebene Wert mit den aktuell in den Tabellenzeilen gespeicherten Werten verglichen. Alle Spalten der Validierungsregel müssen im Business-Objekt vorhanden sein, damit App Builder die In-Memory-Werte erfolgreich in die Spalten der Regel einfügen kann, damit die Logik funktioniert.

• Beispiel für die Validierungsregistrierung für eine Validierungsregel für doppelte Email:

  

• Beispielkonfiguration einer Validierungsregel:

  

• Where-Klausel zur Konfiguration der Validierungsregel:

  

• Join-Logik für die Konfiguration der Validierungsregel: