> Tech > Ajouter de la logique et de la sécurité aux UDTF

Ajouter de la logique et de la sécurité aux UDTF

Tech - Par iTPro - Publié le 24 juin 2010
email

Les UDTF ont un point commun avec les SP : la possibilité de traiter des instructions logiques SPL. La figure 2 montre une table Employee Master et une table de référence croisée qui associe le profil utilisateur OS/400 d'un manager avec les enregistrements de ses employés dans la table Employee

Ajouter de la logique et de la sécurité aux UDTF

Master.
La figure 3 montre une UDTF qui
permet au manager d’un employé – et
à  personne d’autre – d’extraire des informations
en interrogeant la table
Employee Master. Cette UDTF contient
des instructions SPL entre les
mots-clés Begin et Return. En particulier,
cette UDTF fait un test Not Exists
pour s’assurer que l’utilisateur qui demande
les données est un manager
avec au moins un employé. Si ce test
ne trouve pas d’enregistrements, la
procédure stockée signale une exception
et se termine. (Pour plus d’informations
sur le coding des instructions
logiques SPL et le traitement des erreurs,
voir les références dans Autres
lectures.)
Deux options de cette instruction
Create Function de l’UDTF méritent une explication. La première est
« Cardinality 10 ». En spécifiant l’entier
Cardinality, on aide l’optimiseur de requêtes
à  déterminer comment exécuter
au mieux la requête qui référence
l’UDTF, et donc la valeur de cet entier
est la meilleure supposition du programmeur
quant au nombre de lignes
que l’UDTF renverra en moyenne. La
seconde option est USRPRF=*OWNER.
Ce paramètre de l’instruction Set
Option détermine si l’UDTF s’exécute
avec l’autorité de l’utilisateur ou, dans
ce cas, avec l’autorité du propriétaire
de l’UDTF.
Cette option est l’équivalent du paramètre
USRPRF que l’on trouve dans
les diverses commandes de création de
programme. L’option USRPRF est particulièrement
intéressante dans un environnement
client/serveur où la
connexion à  l’iSeries à  partir du système
client est supposée être établie
avec un profil utilisateur possédant
une autorité minimale. Dans l’idéal, les
profils utilisateur ne devraient jamais
avoir le droit d’interroger des tables directement.
Au lieu de cela, certains utilisateurs
ne devraient avoir qu’un accès
temporaire aux données via une procédure
stockée ou UDTF. En procédant
ainsi, un programme maîtrise toujours
la manière dont les utilisateurs
peuvent accéder aux données et les
modifier. En supposant que le propriétaire
de l’UDTF ait l’autorité de lecture
sur la table EmpMast et que l’utilisateur
demandeur ne l’ait pas, l’option
USRPRF=*OWNER accorde à  l’utilisateur
demandeur un accès en lecture
temporaire à  la table EmpMast.
Pour illustrer encore mieux en quoi
il est intéressant que les UDTF incluent
des instructions multiples, vous pourriez
ajouter une instruction Insert pour
enregistrer qui a accédé aux données,
et quand, dans une table d’audit. Voici
un exemple d’utilisation de Retrieve-
EmployeeInfo dans une instruction
Select :

Select EmpInfo.*
From Table(RetrieveEmployeeInfo())
As EmpInfo

Bien que cette UDTF n’ait pas de
paramètres, le couple de parenthèses
() reste nécessaire à  la fin du nom de la
fonction.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010