Contexto empresarial
Un administrador junior está configurando el acceso a un nuevo Data Mart. Inicia una transacción, pero se da cuenta de que aplicó los permisos al grupo equivocado. Este escenario prueba la capacidad del sistema para manejar una transacción descartada (rollback) seguida inmediatamente de una transacción correcta que sí se confirma (commit), validando la estabilidad del servidor ante flujos de trabajo erráticos.
Sobre el conjunto : accessControl
Gestión de derechos de acceso y seguridad de datos.
Descubrir todas las acciones de accessControl Preparación de datos
Creación del Data Mart simulado.
¡Copiado!
| 1 | PROC CAS; |
| 2 | caslib datamart datasource=(srctype="path") path="/tmp/dm"; |
| 3 | RUN; |
| 4 | QUIT; |
Étapes de réalisation
1
Intento fallido: Inicio de transacción y configuración errónea (simulada), seguida de un Rollback.
¡Copiado!
| 1 | PROC CAS; |
| 2 | ACCESSCONTROL.assumeRole / adminRole="superuser"; |
| 3 | ACCESSCONTROL.startTransaction; |
| 4 | ACCESSCONTROL.updSomeAcsCaslib / caslib="datamart" acs={{principal="Marketing", perm="FullControl"}}; |
| 5 | PRINT "Error detectado, revirtiendo..."; |
| 6 | ACCESSCONTROL.rollbackTransaction; |
| 7 | RUN; |
2
Intento correcto: Inicio de NUEVA transacción, configuración correcta y Commit.
¡Copiado!
| 1 | ACCESSCONTROL.startTransaction; |
| 2 | ACCESSCONTROL.updSomeAcsCaslib / caslib="datamart" acs={{principal="DataScientists", perm="Read"}}; |
| 3 | ACCESSCONTROL.commitTransaction; |
| 4 | RUN; |
| 5 | QUIT; |
Resultado esperado
El primer bloque de cambios (Marketing) se descarta completamente tras el rollback. El segundo bloque (DataScientists) se persiste correctamente tras el commitTransaction. Esto valida que el 'commit' funciona correctamente incluso inmediatamente después de una sesión abortada.