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 cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
