Reichweite im Jitterbit App Builder

Reach ist die Implementierung der Sicherheit auf Zeilenebene (RLS) im App Builder. Mit Reach können Anwendungsentwickler einschränken, welche Zeilen jedem Benutzer zur Verfügung stehen.

Viele relationale Datenbankmanagementsysteme (RDBMS) bieten native Unterstützung für RLS. Reach ist keine Abstraktion dieser nativen Angebote. Stattdessen wird Reach von der Business Engine des App Builder implementiert. 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 einschränken.
• Mandantenfähigkeit - Wenn eine Anwendung mehrere Kunden unterstützt, kann Reach den Zugriff der Kunden auf ihren Datenbereich einschränken.

Konzepte

Reach besteht aus den folgenden Kernkonzepten:

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

Reichweitenregel

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

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

Reichweitentoken

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 für den Benutzer zugänglichen Daten. Eine Reichweitenregel kann mehrere Zeilen zurückgeben, wobei jede Zeile ein anderes Segment identifiziert. Gibt die Regel keine Zeilen zurück, hat der Benutzer keinen Zugriff auf die Daten.

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

Normalerweise identifiziert ein Reichweitentoken keine einzelnen Kunden. Es gibt jedoch Ausnahmen. Beim Aufbau eines mandantenfähigen Systems 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 den Zugriff des Benutzers auf die Segmente des Datenobjekts einschränkt.
• Bindungsspalte: Die durch das Reichweitentoken gebundene Datenobjektspalte.
• Rolle: Die Rolle, für die die Reichweitenregel gilt. Ist sie keiner Rolle zugeordnet, gilt die Regel für alle Benutzer.
• Aktiv: Aktivieren oder Deaktivieren der Reichweitenregel für Entwicklungs- und Testzwecke.
• Index: Reihenfolge, in der Reichweitenregeln angewendet werden.

Hinweis

Beachten Sie, dass Reach-Regeln nicht für beliebige Datenobjekte registriert werden können. Reach-Regeln zielen auf eine physische Tabelle oder Ansicht ab. Die Regeln können nur für Datenobjekte registriert werden, die auf dieselbe Tabelle oder Ansicht abzielen.

Umsetzung

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

Reach wird daher in folgenden Szenarien unterstützt:

• Panels - einschließlich mehrzeiliger und einzeiliger Panels, Diagrammen und Kalendern usw.
• Controls - einschließlich Listen- und Optionsfeldern.
• CRUD - einschließlich Business-CRUD-Regeln - keine datenbankbasierten CRUD-Regeln.

Beispiel

Gegeben sei das folgende Schema:

Tabelle	Primärschlüssel	Beziehungen
Region	RegionId
Customer	CustomerId	RegionId, Fremdschlüssel für Region Tisch.
Employee	EmployeeId	RegionId, Fremdschlüssel für Region Tisch. UserId, Verweis auf App Builder Benutzer.

In diesem Modell:

• Mitarbeiter und Kunden gehören beide einer Region an.
• Jedem Mitarbeiter ist ein App Builder Benutzer zugeordnet.

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 Reichweitenregel zielt auf Customer Tabelle kann es in der Customer (Source)Datenobjekt. An diesem Punkt wird Reach auf alle Panels angewendet, die an das Customer (Source) Datenobjekt.

In vielen Fällen sollte Reach nur für bestimmte Benutzer angewendet werden. Dies lässt sich mit rollenbasierter Sicherheit (RBS) erreichen. Angenommen, die Datenquelle definiert die folgenden Rollen:

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

Ordnen Sie die Reach-Regel beim Registrieren der Rolle„Vertrieb“ zu. Dadurch wird sichergestellt, dass Reach nur auf Benutzer mit der Rolle„Vertrieb“ 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 Vorgänge: Die Reach-Regel und das Datenobjekt müssen zur selben 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 Reichweitenregel kann nur eine Spalte für Reichweitentoken haben. Datenobjekte werden daher über eine einzelne Spalte an Reichweitenregeln 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 dem App Builder Connector unterstützt.
• Beim Kopieren eines Datenobjekts werden keine Reach-Registrierungen kopiert. Dies ist konsistent mit anderen Regeltypen: Standardwerte, Validierungen und Aktionen werden ebenfalls nicht kopiert.