Regeln in Jitterbit App Builder verwalten
Einführung
Regeln werden auf der Seite Regeln verwaltet. Um sie zu öffnen, wählen Sie App Workbench > Regeln:
Von hier aus können Sie folgende Aktionen ausführen:
Regeln anzeigen
Wenn Sie die Seite Regeln öffnen, ist die Registerkarte Alle Regeln standardmäßig ausgewählt. Diese zeigt alle Regeln für die aktuelle App und die ausgewählte App-Datenquelle. Die anderen Registerkarten sind wie folgt:
- Nach Tabelle: Regeln basierend auf den Tabellen der ausgewählten Datenquelle anzeigen oder erstellen.
- Mit Reichweite: Regeln basierend auf den Reichweitenregeln für die Tabellen der ausgewählten Datenquelle anzeigen.
Die nächsten zwei Registerkarten verdeutlichen die enge Beziehung zwischen Regeln und Ereignissen:
- Alle Ereignisse: Alle Ereignisse für die aktuelle App anzeigen.
- Hintergrund-Ereignisse: Alle Hintergrund-Ereignisse für die aktuelle App anzeigen.
Tipp
Wenn Sie eine große Anzahl von Regeln in Ihrer App haben, verwenden Sie die Suchleiste, um nach Regeln zu suchen, klicken Sie auf das Symbol Filter anwenden, um den Tabelleninhalt zu filtern, oder klicken Sie auf eine Spaltenüberschrift Name, Ziel, Typ oder Geändert am, um die Tabelle nach dieser Spalte zu sortieren.
Regel erstellen
Um eine Regel zu erstellen, klicken Sie auf die Schaltfläche + Regel im Abschnitt Regeln. Dies öffnet die Seite Rule Builder:
Führen Sie folgende Schritte aus:
- Geben Sie im Feld Name einen Namen für Ihre Regel ein.
- (Optional) Geben Sie im Feld Technische Hilfe eine Beschreibung für die Regel ein. Dieser Text ist nur für App-Entwickler sichtbar.
-
Klicken Sie auf das Menü Zweck und wählen Sie eine der Zweckoptionen. Je nach Ihrer Wahl werden zusätzliche Einstellungen angezeigt. Die verfügbaren Optionen sind in der folgenden Tabelle dargestellt:
Kategorie Zweck Quell-Datenquelle Ziel-Datenquelle Ziel Ziel-Layer Aktion Diagrammtyp Liefermethode Basis Geschäftsobjekt CRUD Validierung Sichtbarkeit Berichterstellung Kalender Diagramm Gantt Karte Netzwerkgraph Bericht Pivot Sonderfall API-Aufruf Benachrichtigung Standard Liste Migration Reichweite Unterabfrage Webhook XP-Validierung XP CRUD -
Klicken Sie auf die Schaltfläche Erstellen.
- Verwenden Sie den Visual Rule Builder, um die Tabellen und Spalten hinzuzufügen, die Ihre Regel benötigt.
- Klicken Sie nach Abschluss auf die Schaltfläche Validieren, um die Regel zu überprüfen.
Tipp
Um mehrere Regeln auf einmal statt einzeln zu validieren, verwenden Sie die Schaltfläche Rule Validation auf der Seite Rules. Weitere Informationen finden Sie unter Validate rules in App workbench Rules tab.
Regel bearbeiten
Gehen Sie wie folgt vor, um eine Regel zu bearbeiten:
- Klicken Sie auf das Symbol Edit neben der Regel, die Sie bearbeiten möchten. Die Seite Rule Builder wird geöffnet.
- Bearbeiten Sie die Regel. Das Layout und die Steuerelemente sind identisch mit denen beim Erstellen einer Regel. Änderungen an der Regel werden sofort wirksam.
- (Optional) Klicken Sie auf die Schaltfläche Validieren, um die Regel zu überprüfen, bevor Sie die Seite schließen.
Visueller Regel-Builder
Wenn Sie eine Regel erstellen oder bearbeiten, wird die Seite Rule Builder in zwei Bereiche unterteilt: einen, in dem Sie den Namen und den Zweck der Regel festlegen, und einen anderen, der aus einer Reihe von Registerkarten besteht, in dem Sie die Regel selbst definieren. Die Standardregisterkarte ist die Registerkarte Tables (auch als Visual Rule Builder bekannt).
Die Registerkarte Tables ist eine Arbeitsfläche, auf der Sie mit grafischen Darstellungen der Tabellen, Spalten, Joins und anderen Regeln interagieren, die die Regel bilden, an der Sie arbeiten. Je nach Zweck der Regel kann eine Tabelle automatisch zur Arbeitsfläche hinzugefügt werden.
Sie können auf folgende Weise mit den Bildern auf der Arbeitsfläche interagieren:
- Klicken Sie auf die Beschriftung einer Tabelle und halten Sie sie gedrückt, um sie auf der Arbeitsfläche zu verschieben.
- Verwenden Sie die Viewport-Steuerelemente und , um die Arbeitsfläche zu vergrößern oder zu verkleinern.
- Ziehen Sie Spalten per Drag-and-Drop von einer Tabelle zu einer anderen, um Joins zu erstellen. Diese werden auf der Registerkarte Joins angezeigt.
- Klicken Sie auf die Schaltfläche + Tables, um Tabellen zur Regel hinzuzufügen.
- Klicken Sie auf die Schaltfläche + Column, um eine Spalte zur Regel hinzuzufügen.
- Klicken Sie auf das Symbol Remove, um eine Tabelle aus der Regel zu entfernen.
- Klicken Sie auf die Titelleiste der Tabelle, um eine Popup-Seite zu öffnen, auf der Sie folgende Aktionen ausführen können:
- Legen Sie die Reihenfolge der Tabelle in der Abfrage fest.
- Wählen Sie eine andere Tabelle aus.
- Legen Sie den Alias fest, der zum Verweisen auf die Tabelle in Abfragen verwendet wird.
- Wählen Sie alle Spalten aus.
- Bearbeiten Sie die Tabelle auf der Seite Table Definition.
- Sehen Sie sich die Ergebnisse der Abfrage für die Tabelle an.
Die übrigen Registerkarten haben folgende Funktionen:
- Columns tab: Eine Liste der von der Regel verwendeten Spalten.
- Where tab: Eine Liste der SQL-Klauseln
where, die von der Regel verwendet werden. - Joins: Eine Liste der von der Regel verwendeten Tabellen-Joins.
- SQL: Die SQL-Anweisung, die die Regel bildet.
- Results: Das Ergebnis der Ausführung der SQL-Anweisung. Klicken Sie auf das Symbol Save to CSV, um die Ergebnisse als
.csv-Datei herunterzuladen.
Regel löschen
Um eine Regel zu löschen, klicken Sie auf das Symbol Delete neben der Regel, die Sie löschen möchten, und klicken Sie dann auf die Schaltfläche Proceed, um zu bestätigen.
Regelzweck
Was eine Regel tun kann und wie sie konfiguriert wird, hängt von ihrem Zweck ab. Wenn Sie eine Regel erstellen, müssen Sie einen der folgenden Zwecke auswählen. In diesem Abschnitt wird jeder beschrieben.
API call
API-Call-Regeln definieren, wie Ihre Anwendung mit externen REST-API-Endpunkten interagiert. Sie geben die Parameter und die Struktur für das Senden von Anfragen an eine API und die Verarbeitung der Antworten an.
Ein primärer Anwendungsfall für API-Call-Regeln ist die Verwaltung komplexer, verschachtelter JSON-Datenstrukturen. Diese treten häufig bei der Arbeit mit verwandten Entitäten auf (z. B. ein Kunde mit mehreren Adressen). Sie werden durch die Funktion Drill Down verwaltet:
-
Bei Daten mit hierarchischen Beziehungen definieren Sie separate API-Call-Regeln für jede Ebene der JSON-Struktur. (Beispielsweise könnte eine „Root"-Regel die primären Kundendaten verarbeiten, während eine separate Unter-Regel das verschachtelte Array von Adressen verwaltet.)
-
Die erweiterte Einstellung Drill Downs wird auf der Root-API-Call-Regel konfiguriert. Diese Einstellung verlinkt auf die relevanten Unter-Regeln, die die verschachtelten Daten verarbeiten.
-
Binding verbindet Daten zwischen Root- und Sub-Rules. Dies erfolgt typischerweise durch die Verwendung einer gemeinsamen Kennung (z. B.
CustomerID), um verschachtelte Elemente (Adressen) mit ihrer übergeordneten Entität (dem Kunden) zu verknüpfen.
Dieser modulare Ansatz ermöglicht es App Builder, Daten aus APIs, die komplexe, mehrstufige JSON-Objekte und Arrays zurückgeben, effektiv zu verarbeiten und darzustellen. Der Prozess ist in zwei unterschiedliche Schritte unterteilt:
-
Eine API-Call-Aktion (die die Konfiguration der API-Call-Rules verwendet) wird zu einem Event hinzugefügt. Ihre einzige Aufgabe besteht darin, die API-Anfrage zu konstruieren und zu senden und alle erforderlichen Parameter zu definieren.
-
Unmittelbar nach der API-Call-Aktion im selben Event wird eine Standard-XP CRUD-Aktion ausgeführt. Diese nachfolgende Aktion verarbeitet dann die von der vorherigen API-Call zurückgegebenen Daten und führt Operationen wie CRAM oder UPDATE durch.
Diese Trennung verbessert die Flexibilität und ermöglicht es dir, präzise zu kontrollieren, wann der API-Call erfolgt und wie seine Ergebnisse durch nachfolgende Business-Logic und Datenoperationen innerhalb von App Builder Events verarbeitet werden.
Business Object
Eine beliebige Anzahl von Rule-Events oder Subqueries, die hauptsächlich zum Erstellen der UI-Schicht einer App verwendet werden. Source und List sind zwei häufige Beispiele für Business Objects:
-
Source: Zeigt alle Zeilen und Spalten aus einer Tabelle in der Datenschicht an. Verweist auf eine Tabelle und sollte keine Filter enthalten. Source-Objekte werden häufig verwendet, wenn du einen Ausdruck oder eine Funktion für die zugrunde liegenden Daten erstellen musst, um diese in der Anwendungs-UI-Schicht darzustellen.
-
List: Übersetzt den Primärschlüssel-ID-Wert in einen benutzerfreundlichen Spaltenwert. List-Objekte können verwendet werden, wenn du Daten für den Endbenutzer anzeigen möchtest, die möglicherweise nicht in der Tabelle verfügbar sind. List-Objekte präsentieren Informationen häufig in Form eines Dropdown-Menüs, aus dem ein Benutzer auswählen kann.
Calendar
Business Logic für einen Kalender in der UI-Schicht. Attribute werden auf Rule-Ebene über die folgenden Usage Type-Werte definiert:
- Color
- Description
- End
- Sort
- Start
Chart
Business Logic für ein Diagramm in der UI-Schicht. Attribute werden auf Rule-Ebene über die folgenden Usage Type-Werte definiert:
- Category
- Color
- Flag
- JSON Options Object
- Sort
- Value
CRUD
Daten aktualisieren, löschen oder einfügen. Die ausgewählte Aktion definiert, wie die Rule die Datensätze der Zieltabelle beeinflusst.
CRUD-Rules werden in der Business-Logic-Schicht ausgeführt und führen dazu, dass alle Aktionen und Validierungen für die Tabelle oder das Objekt, das du änderst, ausgeführt werden. (Verwende eine XP CRUD-Rule, wenn du CRUD zwischen zwei verschiedenen Datenquellen verwenden möchtest.)
Weitere Informationen
Default
Verwende eine Default-Rule, um die Benutzererfahrung zu verbessern, indem du Standardwerte in Feldern in der Daten-, Business- oder UI-Schicht festlegst. Ein häufiges Beispiel ist das Festlegen eines Datumsfelds für einen neuen Datensatz auf das heutige Datum.
Gantt
Business Logic für ein Gantt-Diagramm in der UI-Schicht. Attribute werden auf Rule-Ebene über die folgenden Usage Type-Werte definiert:
- Color
- Dependency
- End
- JSON Options Object
- Parent Task
- Sort
- Start
- Task
- Task Group
List
Füllt ausgewählte Listen in der UI-Schicht auf. List-Rules haben keine zugeordneten Aktionen oder Validierungen. Attribute werden auf Rule-Ebene über die folgenden Usage Type-Werte definiert:
- Key
- Title
- Subtitle
Map
Business Logic für eine Karte in der UI-Schicht. Attribute werden auf Rule-Ebene über die folgenden Usage Type-Werte definiert:
- Category
- Color
- JSON Options Object
- Value
Migration
Eine Migrationsregel wird ausgeführt, wenn ein Release auf einem neuen Server installiert wird. Ihr primärer Zweck besteht darin, Apps von der Entwicklung in die QA und von der QA in Produktionsumgebungen zu verschieben. Regeln werden zu den Änderungsverwaltungsschritten hinzugefügt, die beim Veröffentlichen eines LP in einer neuen Umgebung ausgeführt werden. Wenn eine Migrationsregel ausgeführt wird, erstellt App Builder einen Snapshot der Regel und bettet ihn in das Changeset ein. Die Migrationsregel wird nach der Ausführung gelöscht.
Netzwerkgraph
Geschäftslogik für einen Netzwerkgraph in der UI-Schicht.
Benachrichtigung
Sende eine Nachricht an einen Benutzer. Nachrichten können per E-Mail, Push-Benachrichtigungen, SMS (Textnachrichten) oder In-App-App-Builder-Warnungen versendet werden. Benachrichtigungen unterstützen Dateianhänge aller Dateitypen.
Pivot
Zeige eine Pivot-Tabelle (flacher Datensatz) an. Pivot-Regeln fassen verwandte Daten zusammen, die sich über mehrere Zeilen erstrecken, und präsentieren sie in einer einzelnen Zeile. Diese Ausgabe hilft dabei, die Aufmerksamkeit auf nützliche Informationen zu lenken.
Reach
Verwende eine Reach-Regel, um den Zugriff eines Benutzers auf Daten auf Seiten zu beschränken, ohne den Zugriff auf die Seiten selbst zu beschränken.
Bericht
Verwende diese Option, um Geschäftslogik ohne zugehörige Ereignisse zu konfigurieren. Dieser Regeltyp ist für verschiedene Berichtsanforderungen in der UI-Schicht vorgesehen (z. B. für ein Diagramm, ein Grid-Panel oder einen Pivot).
Unterabfrage
Unterabfrage-Regeln sind Regeln, die in anderen Geschäftsregeln enthalten sein können. Unterabfragen sind auf sich allein gestellt nicht der Anwendungs-UI-Schicht ausgesetzt und unterstützen keine Geschäftslogik-Ereignisse. Sie werden typischerweise verwendet, um Daten anzupassen, komplexere Logik auszuführen oder Berechnungen an Daten durchzuführen.
Tipp
Halte die Logik beim Entwerfen von Unterabfragen so flach und so einfach wie möglich.
Weitere Informationen
Validierung
Validierungsregeln schützen die Datenintegrität. Du kannst sie beispielsweise verwenden, um Geschäftslogik bei manuellen Eingaben durchzusetzen. Wenn eine CRUD-Regel definiert ist, werden Validierungen auch ausgeführt, wenn diese CRUD-Regel ausgeführt wird. Validierungsmeldungen, die Benutzern angezeigt werden, sind konfigurierbar und können dynamische Substitution verwenden, um die Benutzererfahrung zu verbessern.
Weitere Informationen
Sichtbarkeit
Bestimme den Status eines Steuerelements in der UI-Schicht: Welche Steuerelemente sind ausgeblendet, erforderlich oder zur Bearbeitung verfügbar. Sichtbarkeitsregeln vereinfachen das Seitendesign und verbessern die Benutzererfahrung. (Diese Regel kann nur für ein Formular-Panel konfiguriert werden.)
Webhook
Ermögliche einem separaten System, ein benutzerdefiniertes App-Builder-Callback-Ereignis aufzurufen. Ein Webhook ist ein benutzerdefinierter HTTP-Callback, der typischerweise durch ein Ereignis ausgelöst wird. Wenn ein Webhook in Form einer E-Mail oder Textnachricht verwendet wird, antwortet App Builder je nach Benutzerantwort entsprechend, indem das angegebene Ereignis aufgerufen wird.
XP CRUD
Führe eine CRUD-Regel über Datenquellen hinweg aus. XP-Regeltypen sind so konzipiert, dass Logik über verschiedene Datenquellen hinweg ausgeführt werden kann.
XP-Validierung
Führe eine Validierungsregel über Datenquellen hinweg aus. XP-Regeltypen sind so konzipiert, dass Logik über verschiedene Datenquellen hinweg ausgeführt werden kann.
Zusätzliche Einstellungen
Wenn du einen Regelzweck (#purpose) auswählst, werden eine oder mehrere der folgenden zusätzlichen Einstellungen angezeigt.
Aktion
Die Aktionsoptionen sind wie folgt:
- Cram: Ähnlich wie Einfügen, schlägt aber nicht fehl, wenn ein Primärschlüssel bereits vorhanden ist. Ein neuer Datensatz wird nur erstellt, wenn der PK nicht bereits in der Datenquelle vorhanden ist. Datensätze mit doppelten Schlüsseln werden übersprungen.
- Löschen: Lösche einen vorhandenen Datensatz in der Zieltabelle.
- Einfügen: Erstelle einen neuen Datensatz in der Zieltabelle.
- Aktualisieren: Ändere einen vorhandenen Datensatz in der Zieltabelle.
Diagrammtyp
Für den Regelzweck Diagramm sind die folgenden Diagrammtypen verfügbar:
- 3D-Balken
- 3D-Säule
- 3D-Donut
- 3D-Kreisdiagramm
- Fläche
- Balken
- Blase
- Säule
- Trichter
- Linie
- Marimekko
- Gemischt
- Prozentuale Fläche
- Kreisdiagramm
- Pyramide
- Halbkreis-Donut
- Spline
- Gestapelte Fläche
- Gestapelte Balken
- Gestapelte Säule
Zustellmethode
Zustellmethoden für eine Benachrichtigungsregel sind wie folgt:
- App Builder Alert
- Push Notification
- Text Message
Quellen-Datenquelle
Die Datenquelle, die die Regel auslöst.
Ziel-Datenquelle
Die Ziel-Datenquelle ist die Datenquelle, in der sich das Ziel befindet.
Ziel
Das Ziel ist das, was von der Regel betroffen ist.
Zielschicht
Die Optionen für die Zielschicht sind wie folgt:
- Datenschicht: Wählen Sie diese Option, um ein Ziel in der Datenschicht auszuwählen.
- Logikschicht: Wählen Sie diese Option, um ein Ziel in der Logikschicht auszuwählen.

