Geschäftsregeln im Jitterbit App Builder

Einführung

Auf dieser Seite erhalten Sie einen allgemeinen Überblick über die verschiedenen im App Builder verfügbaren Geschäftsregeln, was sie sind und warum Sie sie verwenden.

API Aufruf

API-Aufruf ist ein Regeltyp, der im App Builder für den Aufruf eines API Endpoint verfügbar ist. Durch Auswahl dieser Regel werden die Target-Ergebnisse ausschließlich auf REST API Endpoints beschränkt.

Geschäftsobjekt

Business Object ist der am häufigsten verwendete Geschäftsregeltyp in App Builder-Anwendungen. Dieser Regeltyp ermöglicht die Verwendung von Ereignissen und die Einbindung einfacher oder komplexer Logik über Aktionen und Validierungen. Business Objects dienen hauptsächlich zum Erstellen der UI-Schicht einer Anwendung. Business Objects können Unterabfragen als Teil ihrer Logik verwenden.

Source Und List Zwei gängige Beispiele für Geschäftsobjekte sind:

• Source: Zeigt alle Zeilen und Spalten einer Tabelle in der Datenschicht an. Referenziert eine Tabelle und sollte keine Filter enthalten. Quellobjekte werden häufig verwendet, wenn Sie einen Ausdruck oder eine Funktion für die zugrunde liegenden Daten erstellen müssen, um diese in der Anwendungs-UI-Schicht darzustellen.

• List: übersetzt den Primärschlüssel-ID-Wert in einen benutzerfreundlichen Titelspaltenwert. Listenobjekte können verwendet werden, wenn Sie dem Endbenutzer Daten anzeigen möchten, die möglicherweise nicht in der Tabelle verfügbar sind. Listenobjekte präsentieren Informationen häufig in Form eines Dropdown-Menüs, aus dem der Benutzer auswählen kann.

Kalender

Kalender-Geschäftsregeln dienen zur Erstellung der Geschäftslogik für einen Kalender, der auf der UI-Ebene angezeigt wird. Der Vorteil einer Regel mit Kalendertyp besteht darin, dass Sie alle erforderlichen Kalenderattribute auf Regelebene konfigurieren und organisieren können, indem Sie den Verwendungstyp definieren.

Werte für den Verwendungstyp:

• Color- Description- End- Sort- Start

Diagramm

Diagramm-Geschäftsregeln dienen zur Erstellung der Geschäftslogik für ein Diagramm, das auf der UI-Ebene der Anwendung angezeigt wird. Der Vorteil einer Regel mit dem Typ „Diagramm“ besteht darin, dass Sie alle erforderlichen Diagrammattribute auf Regelebene konfigurieren und organisieren können, indem Sie den Verwendungstyp definieren.

Werte für den Verwendungstyp:

• Category- Color- Flag- JSON Options Object- Sort- Value

CRUD

CRUD-Regeln werden verwendet, wenn Sie Daten in einer Anwendung aktualisieren, löschen oder einfügen möchten. Die zugehörigen Aktionen, die Sie bei der Konfiguration auswählen (Cram, Delete, Insert, Update) definieren, wie sich die Regel auf die Datensätze der Zieltabelle auswirkt. CRUD-Geschäftsregeln werden in der Geschäftslogik-Schicht erstellt und definiert.

CRUD-Geschäftsschicht-Regeln führen Ihre Regel in der Geschäftslogik-Schicht aus, d. h. sie führen alle Aktionen und Validierungen für die Tabelle oder das Objekt aus, das Sie bearbeiten.

XP CRUD-Regeln stehen für plattformübergreifendes CRUD und werden verwendet, wenn Sie CRUD zwischen zwei verschiedenen Datenquellen verwenden möchten.

Aktion muss für eine CRUD-Regel definiert werden, je nachdem, was Sie erreichen möchten.

• Update - Vorhandene Datensätze in der Zieltabelle ändern
• Delete - löscht vorhandene Datensätze in der Zieltabelle
• Insert - Erstellt neue Datensätze in der Zieltabelle
• Cram - Ähnlich wie „Einfügen“, schlägt aber nicht fehl, wenn bereits ein Primärschlüssel vorhanden ist. Das bedeutet, dass nur dann ein neuer Datensatz erstellt wird, wenn der Primärschlüssel in der Datenquelle nicht vorhanden ist. Gefundene doppelte Schlüsseldatensätze werden übersprungen.

Standard

Standardobjekte dienen dazu, Informationen in Feldern der UI-Ebene einer Anwendung standardmäßig festzulegen. Sie können auch auf der Daten- und Geschäftslogikebene verwendet werden. Ziel von Standardregeln ist es, dem Benutzer Zeit zu sparen und ein besseres Benutzererlebnis zu bieten. Ein gängiges Beispiel ist die Standardisierung eines Datumsfelds für einen heute hinzugefügten neuen Datensatz.

Gantt

Gantt-Geschäftsregeln dienen zur Erstellung der Geschäftslogik für ein Gantt-Diagramm, das auf der UI-Ebene angezeigt wird. Der Vorteil einer Regel mit Gantt-Typ besteht darin, dass Sie alle erforderlichen Gantt-Diagrammattribute auf Regelebene konfigurieren und organisieren können, indem Sie den Verwendungstyp definieren.

Werte für den Verwendungstyp:

• Color- Dependency- End- JSON Options Object- Parent Task- Sort- Start- Task- Task Group

Liste

Liste-Geschäftsregeln dienen zum Füllen von Auswahllisten aus der UI-Ebene einer Anwendung. Listenregeln haben keine zugehörigen Aktionen oder Validierungen. Der Vorteil beim Erstellen einer Regel mit dem Typ „Liste“ besteht darin, dass Sie beliebige Listenattribute auf Regelebene konfigurieren und organisieren können, indem Sie den Verwendungstyp definieren.

Werte für den Verwendungstyp:

• Key- Title- Subtitle

Karte

Karten-Geschäftsregeln dienen zur Erstellung der Geschäftslogik für eine Karte, die auf der UI-Ebene angezeigt wird. Der Vorteil einer Regel mit dem Kartentyp besteht darin, dass Sie alle Kartenattribute auf Regelebene konfigurieren und organisieren können, indem Sie den Verwendungstyp definieren.

Werte für den Verwendungstyp:

• Category- Color- JSON Options Object- Value

Migration

Migrationsregeln werden ausgeführt, wenn eine neue Version auf einem neuen Server installiert wird. Sie werden wie CRUD-Regeln definiert und in der Umfeld ausgeführt. Mithilfe von Migrationsregeln kann ein Benutzer die Datenbank mit den Aktionen Aktualisieren, Einfügen, Löschen oder Cram ändern. Diese Regeln werden den Änderungsverwaltungsschritten hinzugefügt, die der Reihe nach ausgeführt werden, wenn ein LP im App Builder in einer neuen Umfeld veröffentlicht wird. Wenn eine Migrationsregel ausgeführt wird, erstellt App Builder einen Snapshot der Regel und bettet ihn in das Änderungsset ein. Die Migrationsregel wird nach der Ausführung als Migrationsregel gelöscht. Diese Regeln werden hauptsächlich beim Verschieben von Apps von der Entwicklung über die Qualitätssicherung in die Produktion verwendet.

Netzwerkdiagramm

Netzwerkgraph-Geschäftsregeln dienen zur Erstellung der Geschäftslogik für die Anzeige eines Netzwerkgraphen in der UI-Schicht einer Anwendung. Der Vorteil dieses Regeltyps besteht darin, dass ihm die für den Netzwerkgraphen geeigneten Spaltennutzungstypen zugeordnet sind. Bei Verwendung in der UI-Schicht werden die Werte basierend auf den Nutzungstypen standardmäßig übernommen.

Benachrichtigung

Eine Benachrichtigungs-Geschäftsregel ermöglicht es dem App Builder, Nachrichten an einen Benutzer zu senden. Nachrichten können per Email, Push-Benachrichtigung, SMS oder App Builder Benachrichtigungen (In-App-Benachrichtigungen) gesendet werden. Benachrichtigungen unterstützen Dateianhänge aller Dateitypen.

Drehpunkt

Pivot-Regeln dienen zur Anzeige einer Pivot-Tabelle in einer Anwendung. Mit diesem Regeltyp können Sie eine Datensatztabelle vereinfachen. Pivot-Regeln fassen zusammengehörige Daten, die sich über mehrere Zeilen erstrecken, in einer einzigen Zeile zusammen. Diese Ausgabe hilft, die Aufmerksamkeit auf nützliche Informationen zu lenken.

Bericht

Bericht-Geschäftsregeln ermöglichen die Konfiguration von Geschäftslogik ohne zugehörige Ereignisse. Dieser Regeltyp ist für verschiedene Berichtsanforderungen in der UI-Ebene vorgesehen und kann beispielsweise für Diagramme, Raster oder Pivot-Diagramme verwendet werden.

Erreichen

Mit Reach-Geschäftsregeln können Sie den Datenzugriff bestimmter Benutzer in einer Anwendung einschränken. Benutzer können zwar zu denselben Seiten navigieren, die auf jeder Seite angezeigten Daten werden jedoch so angepasst, dass nur die Daten angezeigt werden, auf die der jeweilige Benutzer Zugriff hat. Sie können Reach beispielsweise nutzen, um einem Vertriebsbenutzer nur Zugriff auf Daten entsprechend seiner zugewiesenen Region zu gewähren.

Unterabfrage

Unterabfragen sind Geschäftsregeln, die sich innerhalb anderer Geschäftsregeln, wie z. B. Geschäftsobjekten, befinden. Unterabfragen selbst sind nicht mit der Anwendungs-UI-Schicht verbunden und unterstützen keine Geschäftslogik-Ereignisse. Sie werden typischerweise verwendet, um Daten anzupassen, komplexere Logik auszuführen und/oder Berechnungen durchzuführen. Achten Sie beim Entwurf von Unterabfragen darauf, die Logik so einfach und übersichtlich wie möglich zu halten.

Validierung

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 bei der Ausführung dieser CRUD-Regel auch Validierungen ausgeführt.
Die den Benutzern angezeigten Validierungsmeldungen sind konfigurierbar und können dynamische Substitutionen für ein verbessertes Benutzererlebnis nutzen.

Sichtbarkeit

Sichtbarkeit-Geschäftsregeln bestimmen den Status eines Steuerelements in der UI-Ebene, d. h., welche Steuerelemente ausgeblendet, obligatorisch oder bearbeitbar sind. Der Mehrwert einer Sichtbarkeitsregel besteht darin, das Seitendesign und die Benutzerfreundlichkeit zu vereinfachen. Diese Typregeln können nur für Formularfelder konfiguriert werden.

Webhook

Ein Webhook ermöglicht es jedem System, benutzerdefinierte Rückrufereignisse im App Builder auszulösen. Ein Webhook ist ein benutzerdefinierter HTTP-Rückruf und wird typischerweise durch ein Ereignis ausgelöst. Wird ein Webhook in Form einer Email oder Textnachricht verwendet, reagiert App Builder je nach Benutzerantwort entsprechend, indem das angegebene Ereignis ausgelöst wird.

XP CRUD

Eine XP CRUD-Regel dient zum Erstellen und Ausführen einer CRUD-Regel über mehrere Datenquellen hinweg. XP-Regeln ermöglichen die Ausführung von Logik über verschiedene Datenquellen hinweg.

XP-Validierung

Eine XP-Validierungsregel dient zum Erstellen und Ausführen von Validierungsregeln für verschiedene Datenquellen. XP-Regeln ermöglichen die Ausführung von Logik über verschiedene Datenquellen hinweg.