Validierungstipps im Jitterbit App Builder

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

Dieser Artikel enthält einige bewährte Methoden und Empfehlungen für die Arbeit mit Validierungen in App Builder. Validierungen werden verwendet, um die Datenintegrität zu schützen. Sie können für manuell eingegebene Daten ausgeführt werden und verhindern, dass ein Benutzer Datensätze hinzufügt, die gegen die Geschäftslogik verstoßen (z. B. doppelte Datensätze). Validierungsregeln können auch in der Geschäftslogikebene verwendet werden. Wenn eine CRUD-Regel als Geschäftsebene festgelegt ist, werden Validierungen auch ausgeführt, wenn diese CRUD-Regel ausgeführt wird.

Den Endbenutzern angezeigte Validierungsnachrichten sind konfigurierbar und können dynamische Ersetzungen für eine verbesserte Benutzererfahrung nutzen.

Lernprogramm 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 verwendet (z. B. für eine REST- API). Explizite Bindung darf Ihre Validierung nicht unterbrechen.

2. Ihre Validierung sollte entweder auf die Tabelle oder das Panel-Datenobjekt abzielen. Wenn Sie sich auf Tabellenebene registrieren möchten, sodass die Registrierung jedes Mal ausgeführt wird, wenn ein Datensatz über ein beliebiges Datenobjekt gespeichert wird, dann würden Sie die Tabelle als Ziel festlegen und sich auf Tabellenebene registrieren. Wenn Sie sich für das Datenobjekt registrieren möchten, dann zielen Sie auf das Datenobjekt ab.

3. Der eigentliche Trick besteht darin, herauszufinden, wie in der Validierungsregel auf den temporären/neuen („Im Arbeitsspeicher“) Datensatz verwiesen wird, um ihn mit vorhandenen Zeilen abzugleichen. {{nm.ab}} 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 tatsächlich in der Reihenfolge, in der sie hinzugefügt wurden.
   2. Ersetzt alle Datenobjekte, die auf dieselbe Zieltabelle abzielen wie das Panel/Ereignis.
      • Siehe Abschnitt „Ersetzungsszenarien“ weiter unten.

   Wichtig

   Dies ist sehr wichtig, wenn Sie einen Datensatz anhand vorhandener Datensätze validieren möchten. Wenn Sie dies tun möchten, 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 für die Duplizierung von Email „im Arbeitsspeicher“.

5. Validierungen, die durch in Aktionen ausgeführte Geschäftsregeln ausgelöst werden, können keine Bestätigungen durchführen. Sie werden zu Fehlern gerundet. Es gibt keine Möglichkeit, Ihr Top-Level-Ereignis zur Hälfte auszuführen, etwas zu bestätigen und es dann weiter auszuführen.

6. {{nm.ab}} unterstützt dynamische Ersetzungen in den Nachrichten für Validierungen. Sie müssen lediglich den Wert angeben, den Sie im Datenobjekt des Panels ersetzen möchten, auf dem die Validierung ausgelöst wird, und dann {{Value}} im Nachrichtenfeld der Validierung.

Ersatzszenarien:

• Kunde, Kunde (Quelle A), Kunde (Quelle B): alles wird ersetzt
• Kunde, Kunde: Erster Kundentisch wird ersetzt
• 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 „In-Memory“ für doppelte Email:

Dieses Beispiel veranschaulicht den Validierungsansatz „In-Memory“, bei dem der vom Benutzer eingegebene Wert mit den aktuell in den Zeilen der Tabelle gespeicherten Werten verglichen wird. Alle Spalten in der Validierungsregel müssen im Geschäftsobjekt vorhanden sein, damit App Builder um die „In-Memory“-Werte erfolgreich in die Spalten der Regel zu platzieren, damit die Logik funktioniert.

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

  

• Beispielkonfiguration einer Validierungsregel:

  

• Where-Klausel für die Konfiguration der Validierungsregel:

  

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