Alcance en Jitterbit App Builder
Reach es la despliegue de la seguridad a nivel de fila (RLS) de App Builder. Reach permite a los desarrolladores de aplicaciones restringir las filas disponibles para cada usuario.
Muchos sistemas de gestión de bases de datos relacionales (SGBDR) ofrecen compatibilidad nativa con RLS. Reach no es una abstracción de estas opciones nativas. En su lugar, Reach se implementa mediante el motor de negocio de App Builder. Como resultado, Reach es independiente de la base de datos.
Casos de uso
Los casos de uso comunes de Reach incluyen:
- Asignación: Los vendedores solo pueden gestionar los clientes potenciales que les han sido asignados directamente.
- Unidades organizativas: Reach puede restringir el acceso de los empleados a los datos por región geográfica o división.
- Multiinquilino: Si una aplicación admite varios clientes, Reach puede limitar el acceso de cada cliente a su segmento de datos.
Conceptos
El alcance se compone de los siguientes conceptos básicos:
- Regla de alcance
- Token de alcance
- Registro de alcance
Regla de alcance
Una regla de alcance es un tipo de regla de negocio similar a una regla predeterminada o de validación. Como todas las reglas de negocio, las reglas de alcance son fundamentalmente consultas mvSQL.
La regla de alcance determina a qué segmentos de datos puede acceder un usuario. En muchos casos, una regla de alcance utilizará... who() o session() Funciones mvSQL para correlacionar al usuario actual con los datos a los que puede acceder.
Token de alcance
Cada regla de alcance selecciona una única columna designada como token de alcance. Esta columna se identifica por el tipo de uso "Token de alcance".
El token de alcance identifica segmentos de datos accesibles para el usuario. Una regla de alcance puede devolver varias filas, cada una de las cuales identifica un segmento diferente. Si la regla no devuelve ninguna fila, el usuario no tendrá acceso a ningún dato.
Por razones de rendimiento, el token de alcance generalmente identifica un segmento de filas, no filas individuales. Por ejemplo, un token de alcance podría identificar una región geográfica. Un gerente de ventas solo podrá generar informes para los clientes de su región.
Normalmente, un token de alcance no identifica a clientes individuales. Sin embargo, existen excepciones. Al crear un sistema multi-inquilino, el token de alcance podría identificar la fila de cliente del usuario. En este caso, el cliente es el segmento.
Registro de alcance
Los desarrolladores deben registrar explícitamente una regla de alcance en un objeto de datos. Un objeto de datos puede tener varios registros. En este caso, la intersección de esas reglas de alcance determina las filas a las que puede acceder el usuario.
Un registro de alcance incluye lo siguiente:
- Regla de alcance: la regla que restringe los segmentos del objeto de datos accesibles para el usuario.
- Columna de enlace: la columna del objeto de datos enlazada por el token de alcance.
- Rol: el rol al que se aplica la regla de alcance. Si no está asociada a un rol, la regla se aplica a todos los usuarios.
- Activo: habilita o deshabilita la regla de alcance para fines de desarrollo y pruebas.
- Índice: orden de aplicación de las reglas de alcance.
¡!!! note "Nota" Tenga en cuenta que las reglas de alcance no se pueden registrar en objetos de datos arbitrarios. Las reglas de alcance se dirigen a una tabla o vista física. Solo se pueden registrar en objetos de datos que se dirijan a la misma tabla o vista.
Despliegue
Todas las reglas de App Builder admiten un conjunto de eventos intrínsecos. Filter El evento es responsable de recuperar filas. El alcance se aplica mediante el Filter Evento.
Por consiguiente, Reach es compatible con los siguientes escenarios:
- Paneles: Incluye paneles de varias filas y de una sola fila, gráficos, calendarios, etc.
- Controles: Incluye controles de lista y de opción.
- CRUD: Incluye solo reglas CRUD de negocio, no reglas CRUD directas a la base de datos.
Ejemplo
Dado el siguiente esquema de tabla:
| Tabla | Clave principal | Relaciones |
|---|---|---|
Region | RegionId | |
Customer | CustomerId | RegionId, clave externa a Region mesa. |
Employee | EmployeeId | RegionId, clave externa a Region mesa.UserId, referencia al usuario de App Builder. |
En este modelo:
- Tanto los empleados como los clientes pertenecen a una región.
- Cada empleado está asociado a un usuario de App Builder.
La siguiente regla de alcance restringe a los usuarios de modo que solo puedan acceder a los clientes de su propia región:
SELECT RegionId
FROM Employee
WHERE UserId = who('userid')
Suponiendo que la regla de alcance se centra en el Customer tabla, se puede registrar en la Customer (Source)objeto de datos. En ese momento, Reach se aplicará a todos los paneles vinculados al Customer (Source) objeto de datos.
En muchos casos, Reach solo debería aplicarse a algunos usuarios. Esto se puede lograr con la Seguridad Basada en Roles (RBS). Por ejemplo, supongamos que la fuente de datos define los siguientes roles:
- Administrador - Puede acceder a todos los clientes.
- Ventas - Solo puede acceder a clientes de su propia región.
Al registrar la regla de alcance, asóciela con el rol_Ventas_. Esto garantizará que el alcance solo se aplique a los usuarios con el rol_Ventas_: los usuarios con el rol Administrador tendrán acceso a todos los clientes.
Limitaciones
- Actualmente, Reach solo es compatible con fuentes de datos RDBMS.
- Actualmente, Reach no admite operaciones multiplataforma: la regla de Reach y el objeto de datos deben pertenecer a la misma fuente de datos de origen. Reach no es compatible con operaciones CRUD directas a la base de datos. El motor de negocio aplica Reach: las operaciones directas a la base de datos lo ignoran. Una regla de alcance solo puede tener una columna de token de alcance. Por lo tanto, los objetos de datos se vinculan a las reglas de alcance mediante una sola columna. Esto difiere de otros tipos de reglas, que permiten a los desarrolladores vincular objetos de datos a reglas mediante varias columnas.
- Actualmente, Reach no es compatible con el conector de App Builder. Copiar un objeto de datos no copia los registros de alcance. Esto es coherente con otros tipos de reglas: los valores predeterminados, las validaciones y las acciones tampoco se copian.