L'action commitTransaction est le point d'orgue de la gestion des autorisations dans SAS Cloud Analytic ServicesMoteur analytique distribué et en mémoire (in-memory) au cœur de SAS Viya. Il assure le traitement des données et l'exécution des modèles avec une très haute performance.. Sur le plan métier, elle permet de valider et de persister définitivement toutes les modifications de sécurité effectuées au sein d'une transactionUnité de travail logique regroupant une ou plusieurs opérations. Elle garantit l'intégrité des données en validant (commit) ou annulant (rollback) l'ensemble des modifications de manière atomique. de contrôle d'accèsMécanisme régissant l'accès aux ressources SAS Viya (données, rapports, dossiers) en évaluant l'identité de l'utilisateur par rapport aux règles d'autorisation pour autoriser ou bloquer une action.. Cela garantit que les politiques de gouvernance des donnéesEnsemble de règles, processus et outils (comme SAS Information Governance) assurant la qualité, la conformité, la sécurité et la disponibilité des actifs de données au sein de l'écosystème Viya. sont appliquées de manière groupée et atomique, évitant ainsi l'exposition de failles de sécurité temporaires causées par des mises à jour d'autorisations partielles ou inachevées sur vos plans de données.
Pourquoi l'action commitTransaction est-elle cruciale pour la sécurité de vos données sous SAS Viya ?
L'Atomicité de la Gouvernance CAS
Exemple de Code Additionnel
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* CASL Script : Sécurisation Transactionnelle d'une Caslib de Production
(c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
proc cas;
/* 1. Ouverture de la transaction de sécurité */
accessControl.startTransaction / ;
/* 2. Application de multiples modifications (non visibles immédiatement) */
accessControl.updACInfo /
caslib="SALES_DATA",
info=[
{identity="Marketing", identityType="Group", permission="ReadInfo", action="Grant"},
{identity="Marketing", identityType="Group", permission="Select", action="Grant"},
{identity="ExternalConsultants", identityType="Group", permission="Select", action="Deny"}
];
/* 3. Validation et persistance atomique */
accessControl.commitTransaction / ;
print "INFO: Les politiques de sécurité ont été déployées avec succès.";
quit;
(c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
proc cas;
/* 1. Ouverture de la transaction de sécurité */
accessControl.startTransaction / ;
/* 2. Application de multiples modifications (non visibles immédiatement) */
accessControl.updACInfo /
caslib="SALES_DATA",
info=[
{identity="Marketing", identityType="Group", permission="ReadInfo", action="Grant"},
{identity="Marketing", identityType="Group", permission="Select", action="Grant"},
{identity="ExternalConsultants", identityType="Group", permission="Select", action="Deny"}
];
/* 3. Validation et persistance atomique */
accessControl.commitTransaction / ;
print "INFO: Les politiques de sécurité ont été déployées avec succès.";
quit;
Exemples pour l'action commitTransaction
Validation simple de la transaction
Cet exemple montre comment finaliser les modifications en cours dans la session actuelle.
Cycle complet : Début, vérification et validation
Voici le workflow idéal : on commence une transaction, on ajoute une permission (optionnel ici pour l'exemple), on vérifie le statut de la transaction, puis on valide le tout.
Conseil de l'Expert
Ne manipulez jamais les droits d'accès directement règle par règle en production. Utilisez systématiquement le mode transactionnel (startTransaction) pour préparer vos changements. Cela permet de tester la validité de votre logique de sécurité "à blanc" et d'éviter qu'un utilisateur ne se connecte pendant que vous n'avez appliqué que 50% de vos restrictions.
Architecture Technique du Commit de Sécurité
- Isolation des Sessions : Tant que le commitTransaction n'est pas appelé, les modifications de l'Access Control List (ACL) résident dans un espace tampon isolé, invisible pour les autres sessions utilisateurs.
- Validation du Graphe de Permissions : L'action déclenche une vérification de la cohérence du graphe d'héritage avant la persistance, empêchant les conflits de priorité (Identity vs Group).
- Linéarisation des Mises à Jour : Elle force une écriture séquentielle dans le moteur de métriques de CAS, garantissant qu'aucune "race condition" ne survient lors de modifications simultanées sur une même Caslib.
- ersistance du Metadata Store : Le commit synchronise les règles en mémoire avec la couche de persistance de Viya (Consul/Infrastructure Data Server), assurant la survie des droits après un redémarrage des pods CAS.
- Point de Restauration (Rollback) : Elle marque la fin de la possibilité d'utiliser l'action rollbackTransaction, qui est votre unique filet de sécurité en cas d'erreur de syntaxe ou de logique durant l'assignation des droits.
Cette réponse vous a-t-elle aidé ?
