Reichweite im Jitterbit App Builder

Reichweite ist App Builder Implementierung von Row-Level Security (RLS). Reach ermöglicht Anwendungsentwicklern, einzuschränken, welche Zeilen jedem Benutzer zur Verfügung stehen.

Viele relationale Datenbankmanagementsysteme (RDBMS) bieten native Unterstützung für RLS. Reach ist keine Abstraktion für diese nativen Angebote. Stattdessen wird Reach von der App Builder Business-Engine. Daher ist Reach datenbankunabhängig.

Anwendungsfälle

Häufige Anwendungsfälle für Reach sind:

• Zuweisung - Vertriebsmitarbeiter können nur ihnen direkt zugewiesene Leads verwalten.

• Organisationseinheiten - Reach kann den Datenzugriff von Mitarbeitern nach geografischer Region oder Abteilung beschränken.

• Mandantenfähigkeit - Wenn eine Anwendung mehrere Kunden unterstützt, kann Reach den Zugriff des Kunden auf seinen Datenabschnitt beschränken.

Konzepte

Reach besteht aus den folgenden Kernkonzepten:

• Reach-Regel
• Reach-Token
• Reach-Registrierung

Reichweitenregel

Eine Reichweitenregel ist eine Art Geschäftsregel wie eine Standard- oder Validierungsregel. Wie alle Geschäftsregeln sind Reichweitenregeln grundsätzlich mvSQL-Abfragen.

Die Reichweitenregel bestimmt, auf welche Datensegmente ein Benutzer zugreifen kann. In vielen Fällen verwendet eine Reichweitenregel die who() oder session() mvSQL-Funktionen zum Korrelieren des aktuellen Benutzers mit den Daten, auf die er zugreifen kann.

Token erreichen

Jede Reichweitenregel wählt genau eine Spalte aus, die als Reichweitentoken bezeichnet wird. Diese Spalte wird durch den Spaltenverwendungstyp „Reichweitentoken“ identifiziert.

Das Reichweitentoken identifiziert Segmente der Daten, auf die der Benutzer zugreifen kann. Eine Reichweitenregel kann mehrere Zeilen zurückgeben, wobei jede Zeile ein anderes Segment identifiziert. Wenn die Regel keine Zeilen zurückgibt, hat der Benutzer keinen Zugriff auf Daten.

Aus Leistungsgründen identifiziert das Reichweitentoken im Allgemeinen ein Zeilensegment - nicht einzelne Zeilen. Beispielsweise kann ein Reichweitentoken eine geografische Region identifizieren. Ein Vertriebsleiter kann nur Berichte für Kunden innerhalb seiner Region erstellen.

Normalerweise identifiziert ein Reichweitentoken keine einzelnen Kunden. Es gibt jedoch Ausnahmen. Beim Erstellen eines Systems mit mehreren Mandanten kann das Reichweitentoken die eigene Kundenzeile des Benutzers identifizieren. In diesem Szenario ist der Kunde das Segment.

Reichweitenregistrierung

Entwickler müssen eine Reichweitenregel explizit für ein Datenobjekt registrieren. Ein Datenobjekt kann mehrere Registrierungen haben. In diesem Fall bestimmt die Schnittmenge dieser Reichweitenregeln, auf welche Zeilen der Benutzer zugreifen kann.

Eine Reichweitenregistrierung umfasst Folgendes:

• Reichweitenregel - Die Regel, die einschränkt, auf welche Segmente des Datenobjekts der Benutzer zugreifen kann.

• Bindungsspalte - Die durch das Reichweitentoken gebundene Datenobjektspalte.

• Rolle - Die Rolle, für die die Reichweitenregel gilt. Wenn sie keiner Rolle zugeordnet ist, gilt die Regel für alle Benutzer.

• Aktiv - Aktivieren oder deaktivieren Sie die Reichweitenregel für Entwicklungs- und Testzwecke.

• Index - Reihenfolge, in der Reichweitenregeln angewendet werden.

Umsetzung

Alle App Builder Regeln unterstützen eine Reihe von intrinsischen Ereignissen. Die Filter Ereignis ist für das Abrufen von Zeilen verantwortlich. Reach wird angewendet durch Filter Ereignis.

Daher wird Reach in den folgenden Szenarien unterstützt:

• Panels - Umfasst mehrzeilige und einzeilige Panels, Diagramme und Kalender usw.
• Steuerelemente - Umfasst Listen- und Radiosteuerelemente.
• CRUD - Umfasst nur Business-CRUD-Regeln - keine datenbankdirekten CRUD-Regeln.

Beispiel

Gegeben sei das folgende Schema:

In diesem Modell:

• Mitarbeiter und Kunden gehören beide zu einer Region.
• Jeder Mitarbeiter ist verbunden mit an App Builder Benutzer.

Die folgende Reichweitenregel schränkt Benutzer so ein, dass sie nur auf Kunden in ihrer eigenen Region zugreifen können:

SELECT RegionId
FROM Employee
WHERE UserId = who('userid')

Angenommen, die Reach-Regel zielt auf die Customer Tabelle kann es in der Customer (Source)Datenobjekt. An diesem Punkt wird Reach auf alle an das Customer (Source) Datenobjekt.

In vielen Fällen sollte Reach nur für einige Benutzer angewendet werden. Dies kann mit rollenbasierter Sicherheit (RBS) erreicht werden. Nehmen wir beispielsweise an, dass die Datenquelle die folgenden Rollen definiert:

• Administrator - Kann auf alle Kunden zugreifen.
• Verkauf - Kann nur auf Kunden in der eigenen Region zugreifen.

Ordnen Sie die Reach-Regel beim Registrieren der Rolle_Sales_ zu. Dadurch wird sichergestellt, dass Reach nur auf Benutzer mit der Rolle_Sales_ angewendet wird: Benutzer mit der Rolle Administrator haben Zugriff auf alle Kunden.

Einschränkungen

• Reach wird derzeit nur für RDBMS-Datenquellen unterstützt.
• Reach unterstützt derzeit keine plattformübergreifenden Operationen: Die Reach-Regel und das Datenobjekt müssen zur gleichen Quelldatenquelle gehören.
• Reach wird für datenbankdirekte CRUD-Operationen nicht unterstützt. Reach wird von der Business Engine angewendet: datenbankdirekte Operationen umgehen die Business Engine.
• Eine Reach-Regel kann nur eine Reach-Token-Spalte haben. Folglich werden Datenobjekte über eine einzelne Spalte an Reach-Regeln gebunden. Dies unterscheidet sich von anderen Regeltypen, die es Entwicklern ermöglichen, Datenobjekte über mehrere Spalten an Regeln zu binden.
• Reach wird derzeit nicht in Verbindung mit der unterstützt. App Builder Connector.
• Beim Kopieren eines Datenobjekts werden keine Reach-Registrierungen kopiert. Dies ist konsistent mit anderen Regeltypen: Standardwerte, Validierungen und Aktionen werden ebenfalls nicht kopiert.