Reach in Jitterbit App Builder

Reach ist ein Regel-Zweck, der Row-Level Security (RLS) in App Builder implementiert und einschränkt, welche Datenzeilen für jeden Benutzer verfügbar sind. Es kann verhindern, dass ein Vertriebsmitarbeiter Konten außerhalb seines zugewiesenen Gebiets sieht, einen Mitarbeiter daran hindern, Daten außerhalb seiner Region oder Abteilung zu sehen, oder verhindern, dass ein Kunde in einer Multi-Tenant-Anwendung die Datensätze eines anderen sieht.

Viele relationale Datenbankmanagementsysteme (RDBMS) bieten native Unterstützung für Row-Level Security, aber Reach ist nicht als Wrapper um diese Unterstützung aufgebaut. Stattdessen wird es direkt von der App Builder-Business-Engine implementiert, sodass es sich unabhängig davon gleich verhält, welche Datenbank darunter liegt.

Diese Seite definiert, wie die Funktion funktioniert, einschließlich Schritte zum Erstellen und Registrieren einer Reach-Regel. Dann gibt es Best Practices, einige praktische Beispiele und eine Liste der aktuellen Einschränkungen der Funktion.

Eine vollständige Anleitung, die eine Reach-Regel mit Demodaten erstellt und auf einem Business-Objekt registriert, finden Sie im Abschnitt Reach von Introduction to App Builder - Appendix D: Security.

Definition

Um die Reach-Funktion zu nutzen, sind drei Schritte erforderlich: Erstellen einer Reach-Regel, Festlegen, welches Token sie zurückgibt, und Registrieren dieser Regel für ein Datenobjekt.

• Erstellen einer Reach-Regel: Eine Reach-Regel ist eine Business-Regel, die mit dem Reach-Zweck erstellt wird. Wie andere Regeltypen, z. B. Default oder Validation, sind Reach-Regeln im Grunde mvSQL-Abfragen. Die Aufgabe einer Reach-Regel besteht darin, zu bestimmen, auf welche Datensegmente ein bestimmter Benutzer zugreifen kann, normalerweise durch Aufrufen der who()- oder session()-mvSQL-Funktionen, um diesen Zugriff an den aktuell angemeldeten Benutzer zu binden. Siehe unten, wie man eine Reach-Regel erstellt.

• Token der Reach-Regel festlegen: Jede Reach-Regel wählt genau eine Spalte aus, die als ihr Reach Token fungiert. Dies wird über das Feld Column Usage Type dieser Spalte festgelegt. Jede von der Regel zurückgegebene Zeile ist ein Datensegment, auf das der aktuelle Benutzer zugreifen kann. Wenn keine Zeilen zurückgegeben werden, hat der Benutzer überhaupt keinen Zugriff. Siehe unten, wie man das Token der Reach-Regel festlegt.

  Token identifizieren normalerweise eine breite Gruppe (z. B. eine geografische Region) statt eines einzelnen Datensatzes, da die Überprüfung des Zugriffs Segment für Segment viel günstiger ist als Zeile für Zeile. Das Token eines Vertriebsleiters könnte die ID seiner Region sein, sodass er Berichte für jeden Kunden in diesem Gebiet abrufen kann, statt nur für einen. Multi-Tenant-Anwendungen sind eine häufige Ausnahme: Dort kann das Token auf die eigene Kundenzeile des Benutzers verweisen, da der Kunde selbst das eingeschränkte Segment ist.

  Das Token muss nicht in der eigenen Zieltabelle der Reach-Regel vorhanden sein. Es kann von weiter oben in einer Beziehungskette über einen Join eingezogen werden, solange es immer noch ein Segment identifiziert, mit dem das eingeschränkte Datenobjekt verknüpft werden kann.

• Registrieren einer Reach-Regel für ein Datenobjekt: Eine Reach-Regel hat keine Auswirkung, bis sie für ein Datenobjekt registriert wird. Ein Datenobjekt kann mehr als eine Registrierung haben. In diesem Fall sieht ein Benutzer nur Zeilen, die alle gleichzeitig erfüllen. Siehe Registrieren einer Reach-Regel unten für Anweisungen.

Erstellen einer Reach-Regel

So erstellen Sie eine neue Reach-Regel von Grund auf:

1. Klicken Sie in App Workbench > Rules auf + Rule. Der Rule Builder wird geöffnet.

2. Benennen Sie die Regel nach App Builders Namenskonventionen mit dem Muster TableName (Reach) Descriptor.

3. Scrollen Sie im Feld Purpose nach unten zu Reach unter Edge Case und wählen Sie es aus.

4. Wählen Sie im Feld Target die Tabelle aus, die die Regel abfragen soll.

5. Klicken Sie auf Create.

Token der Reach-Regel festlegen

Nach dem Erstellen einer Reach-Regel müssen Sie deren Token festlegen. Das Token identifiziert die Datensegmente, die einem Benutzer angezeigt werden.

1. Öffnen Sie den Rule Builder der Reach-Regel.

2. Fügen Sie auf der Registerkarte Where eine Klausel hinzu, die den aktuellen Benutzer mit den Daten verknüpft, auf die er zugreifen kann, normalerweise mit der Funktion who(). Falls die Tabelle noch keine Spalte hat, die eine Zeile mit einem App Builder-Benutzer verknüpft, fügen Sie eine hinzu, zusammen mit einem Steuerelement, damit diese über die Benutzeroberfläche festgelegt werden kann.

3. Fügen Sie auf der Registerkarte Columns die Spalte hinzu, die das zugängliche Segment identifiziert, doppelklicken Sie darauf und legen Sie deren Column Usage Type auf Reach Token fest.

4. Klicken Sie im Bereich Rule auf Results, um zu bestätigen, dass die Regel die erwarteten Segmente zurückgibt.

Reach-Regel registrieren

Nach dem Erstellen der Regel fügen Sie sie an das Datenobjekt an, das Sie einschränken möchten:

1. Navigieren Sie zum Bereich Rule des Geschäftsobjekts, das Sie einschränken möchten.

   Hinweis

   Eine Reach-Regel kann nur bei einem Geschäftsobjekt registriert werden, das auf derselben physischen Tabelle oder Ansicht basiert, auf die sie abzielt – nicht direkt bei einer Tabelle. Im Abschnitt Best practices and recommendations unten finden Sie ein Muster, das eine Reach-Regel auf eine gesamte Tabelle anwendet.

2. Klicken Sie auf More > Edge Case. Das Dialogfeld Edge Case Settings wird geöffnet.

3. Klicken Sie auf Reach. Das Dialogfeld Reach Registration wird geöffnet.

4. Klicken Sie auf Create. Das Dialogfeld zeigt nun ein Formular mit den folgenden Feldern an:

   

   • Unter Reach Information:

     • Rule: Wählen Sie die Reach-Regel aus, die Sie erstellt haben.

     • Binding Column: Wählen Sie die Spalte aus, die dem Reach Token entspricht.

     • Role: (Optional) Wählen Sie die Rolle aus, auf die die Einschränkung angewendet werden soll, oder lassen Sie das Feld leer, um die Einschränkung auf alle anzuwenden, während Sie bestätigen, dass sich die Regel wie erwartet verhält. Siehe Best practices and recommendations unten.

   • Unter Position:

     • Index: (Optional) Geben Sie eine Nummer ein, um die Reihenfolge dieser Regel im Verhältnis zu anderen Reach-Regeln festzulegen, die beim selben Objekt registriert sind.

     • Active: Lassen Sie diese Option aktiviert, um die Regel durchzusetzen, oder deaktivieren Sie sie, um die Einschränkung auszuschalten, ohne die Registrierung zu löschen.

     • Technical Help: (Optional) Geben Sie beschreibende Informationen ein, um andere Entwickler zu unterstützen.

5. Klicken Sie auf Save.

Aktualisieren Sie die Seite, um die Einschränkung in Kraft treten zu sehen.

Sobald ein Geschäftsobjekt mindestens eine registrierte Reach-Regel hat, wird auch eine Reach-Schaltfläche direkt im Bereich Rule neben Events und Roles angezeigt, mit einem Badge, das anzeigt, wie viele Reach-Regeln registriert sind. Klicken Sie darauf, um Registrierungen anzuzeigen, zu bearbeiten oder hinzuzufügen, ohne erneut More > Edge Case aufzurufen.

Best Practices und Empfehlungen

Die folgenden Best Practices können Zeit beim Erstellen von Reach-Regeln sparen:

• Lassen Sie das Feld Role beim Registrieren einer neuen Reach-Regel leer, bis Sie bestätigt haben, dass es funktioniert. Nach der Überprüfung verknüpfen Sie es mit der Rolle, die es einschränken soll, damit administrative Rollen wie Superuser vollständigen Zugriff behalten.

• Registrieren Sie die Regel bei jedem Geschäftsobjekt, das die Daten verfügbar macht, die Sie einschränken. Eine Registrierung wirkt sich nur auf das spezifische Objekt aus, an das sie angehängt ist, nicht auf jede andere Regel, die auf derselben zugrunde liegenden Tabelle basiert. Das Einschränken von Customer (Source) hat daher keine Auswirkung auf ein separates Customer (List)-Objekt, das auf derselben Customer-Tabelle basiert, es sei denn, Sie registrieren die Regel auch dort.

• Bevorzugen Sie ein Token, das ein Segment von Zeilen identifiziert, z. B. eine Region oder einen Kontotyp, gegenüber einem Token, das einzelne Zeilen identifiziert. Eine so breit gefasste Regel hat bei jedem Filter-Ereignis deutlich weniger Zeilen zu überprüfen.

• Um zu sehen, welche Regeln in einer App bereits Reach angewendet haben, gehen Sie zu App Workbench > Rules und überprüfen Sie die Spalte Reach, oder klicken Sie auf die Registerkarte With Reach, um das Raster auf nur diese Regeln zu filtern.

• Um zu sehen, welche Seiten für eine bestimmte Rolle durch Reach eingeschränkt sind, gehen Sie zu App Workbench > Roles und wählen Sie diese Rolle aus. Das Seitendiagramm markiert jede eingeschränkte Seite mit einem -Handsymbol.

• Da eine Reach-Regel nicht direkt auf einer Tabelle registriert werden kann, erstellen Sie ein Geschäftsobjekt, das jede Spalte aus der Tabelle auswählt, nach dem Benennungsmuster TableName (With Reach), und registrieren Sie die Reach-Regel stattdessen darauf. Überall dort, wo eine andere Regel sonst auf die zugrunde liegende Tabelle verweisen würde, verweisen Sie stattdessen auf TableName (With Reach): Da Reach von den Objekten geerbt wird, auf die eine Abfrage verweist, wird die Einschränkung überall dort angewendet, wo dieses Geschäftsobjekt verwendet wird, ohne es immer wieder zu registrieren.

Beispiele

Regionenbasierter Zugriff

Stellen Sie sich eine App mit folgendem Tabellenschema vor:

In diesem Modell gehören Mitarbeiter und Kunden beide zu einer Region, und jeder Mitarbeiter ist an einen App Builder-Benutzer gebunden.

Die folgende Regel beschränkt Benutzer so, dass sie nur Kunden in ihrer eigenen Region sehen:

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

Da diese Regel auf die Tabelle Customer abzielt, kann sie auf das Datenobjekt Customer (Source) registriert werden, und von dort aus gilt sie für jeden auf diesem Datenobjekt erstellten Bereich.

Allerdings sollten Reach-Regeln normalerweise nicht für alle gelten. Verwenden Sie sie stattdessen zusammen mit rollenbasierter Sicherheit. Angenommen, die Datenquelle definiert eine Rolle Administrator, die jeden Kunden sehen kann, und eine Rolle Sales, die nur Kunden in ihrer eigenen Region sehen sollte. Wenn Sie die Regel für die Rolle Sales registrieren, bleiben Administratoren unbeeinträchtigt, während Sales-Benutzer nur die Kunden ihrer eigenen Region sehen.

Mehrere Attribute mit einer Brückentabelle kombinieren

Ein Reach Token muss nicht aus einer einzelnen, direkten Beziehung stammen. Wenn der Zugriff von einer Kombination von Attributen abhängt, z. B. ein Mitarbeiter, der nur Kunden in bestimmten Regionen und bestimmten Kundensegmenten sehen darf, kann eine Brückentabelle diese Kombination auf die einzelnen Datensätze auflösen, die ein Benutzer sehen kann.

Fügen Sie eine Brückentabelle hinzu, z. B. EmployeeAccess, mit einer Spalte EmployeeID, RegionID und CustomerTierID, die eine Zeile für jede Region- und Tier-Kombination speichert, auf die ein Mitarbeiter zugreifen darf. Die folgende Regel verknüpft diese Tabelle, um jede CustomerID zurückzugeben, die der aktuelle Benutzer sehen kann:

SELECT c.CustomerID
FROM EmployeeAccess ea
JOIN Employee e ON e.EmployeeID = ea.EmployeeID
JOIN Customer c ON c.RegionID = ea.RegionID AND c.CustomerTierID = ea.CustomerTierID
WHERE e.UserID = who('userid')

Hier ist CustomerID das Reach Token: Anstatt ein breites Segment zu identifizieren, löst die Regel die Schnittmenge jeder Region und jedes Tiers, auf die der Benutzer Zugriff hat, auf die spezifischen Kundendatensätze auf, die übereinstimmen. Dieses Muster verarbeitet Viele-zu-Viele-Beziehungen, z. B. Mitarbeiter, die mehreren Regionen oder Tiers zugeordnet sind, und benutzerbasierte Ausnahmen, die ein einfacheres Token mit einer einzelnen Spalte nicht ausdrücken kann.

Implementierung

Jede App Builder-Regel verbindet sich mit einem gemeinsamen Satz intrinsischer Ereignisse, und Reach verbindet sich speziell mit dem Filter-Ereignis, das für das Abrufen von Zeilen zuständig ist. Aus diesem Grund wird Reach nur dort wirksam, wo ein Filter-Ereignis tatsächlich ausgeführt wird:

• Panels: Grid- und Form-Panels, Chart- und Calendar-Panels und ähnliche.
• Controls: List- und Radio-Controls.
• CRUD: Nur Business-CRUD-Regeln, keine datenbankgesteuerten CRUD-Regeln, da diese die Business Engine vollständig umgehen.

Einschränkungen

Die folgenden Einschränkungen gelten bei der Implementierung von Reach:

• Reach funktioniert nur mit RDBMS-Datenquellen.
• Reach unterstützt keine plattformübergreifenden Operationen: Die Regel und das Datenobjekt, bei dem sie registriert ist, müssen zur gleichen Datenquelle gehören.
• Reach hat keine Auswirkung auf datenbankgesteuerte CRUD-Operationen, da diese die Business Engine umgehen, die sie erzwingt.
• Eine Reach-Regel kann nur eine Reach Token-Spalte haben, daher bindet sich ein Datenobjekt über eine einzelne Spalte daran, anders als andere Regeltypen, die die Bindung an mehreren Spalten ermöglichen.
• Reach wird derzeit nicht zusammen mit dem App Builder Connector unterstützt.
• Das Kopieren eines Datenobjekts überträgt seine Reach-Registrierungen nicht, genauso wie Default-, Validation- und Action-Regeln.