> Tech > Coder une UDTF externe

Coder une UDTF externe

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

Lors du codage d'une UDTF externe, trois points principaux doivent être bien compris : construire la liste des paramètres, répondre au paramètre CALL TYPE, et indiquer quand il n'y a plus de données à  renvoyer.
Commençons par la liste des paramètres. La figure 3 montre comment construire une telle liste

Coder une UDTF externe

pour une
UDTF. Pour les paramètres d’entrée et
de sortie, il faut que le type de données
SQL soit compatible avec le type de
données HLL. Pour savoir comment établir l’égalité entre les types de données SQL et les types de
données dans un HLL particulier, voir le manuel DB2
Universal Database for iSeries SQL Programming with Host
Languages (voir http://publib.boulder.ibm.com/
iseries/v5r2/ic2924/info/rzajp/rzajpmst.pdf). Par souci de
simplicité, c’est la liste des paramètres de base. Vous pouvez
transmettre des paramètres supplémentaires selon les autres
options spécifiées sur l’instruction CREATE FUNCTION. La
figure 4 montre la liste des paramètres RPG pour le programme
IFSDir.
Le deuxième point du coding consiste à  saisir le paramètre
« call type ». La figure 5 montre ses valeurs possibles.
Bien que le résultat de la fonction soit une table entière, le
programme UDTF est en réalité appelé plusieurs fois ligne à 
ligne. Par conséquent, la logique du programme s’articule
sur la valeur transmise au paramètre CALL TYPE. Voici le
pseudo-code pour la fonction principale de IFSDir :

IF CALLTYPE=-1 //OPEN
CALL OPENDIR
IF ERROR
RETURN ERROR
ENDIF
ELSEIF CALLTYPE=0 //FETCH
CALL READDIR
IF ENTRYFOUND
RETURN COLUMN DATA
ELSE
INDICATE EOT
ENDIF
ELSEIF CALLTYPE=1 //CLOSE
CALL CLOSEDIR
ENDIF

Le programme utilise trois
API principales : OpenDir pour
ouvrir un dossier, ReadDir pour
lire son contenu et CloseDir
pour le fermer. Pendant l’initialisation
de la fonction table
comme indiqué par le type d’appel
de -1, l’API OPENDIR est appelée
pour ouvrir le dossier demandé.
Les paramètres d’entrée
sont disponibles mais des données
ne devraient pas être renvoyées
à  ce stade.
Après l’initialisation, le gestionnaire
de base de données
transmettra une requête
« fetch » comme indiqué par le
type d’appel de 0. A ce momentlà ,
le programme appelle l’API
READDIR pour atteindre le nom
d’un fichier provenant du dossier
IFS spécifié. Après avoir lu
un nom de fichier, le programme
appelle le Qp0lGetAttr
pour extraire les attributs du fichier
comme la taille allouée, la taille réelle et la date de création.
Après avoir extrait l’information, le programme définit
les paramètres de sortie (c’est-à -dire, les données colonne
pour la table) et ajoute une ligne à  la table UDTF. SQL continue
à  appeler l’UDTF avec un type d’appel de of 0 (fetch) jusqu’à 
ce que le programme signale la fin de table (EOT, end of
table). Quand READDIR signale cela, il n’y a plus d’entrées à 
lire, le programme IFSDir définit le paramètre d’état SQL à 
‘02000’ pour indiquer qu’il n’y a plus de données (End of
Table).
Après avoir reçu le signal EOT, SQL appelle IFSDir une
fois de plus avec le type d’appel de 1 (cleanup) pour indiquer
au programme qu’il doit maintenant procéder aux activités
de nettoyage. Puis SQL appelle l’API CLOSEDIR, met *INLR à 
« on » pour préparer le programme à  se terminer en bon
ordre. Chaque programme UDTF externe suit la même structure
de base d’initialisation (open), d’extractions de lignes répétées (fetches) et de nettoyage (close), comme indiqué
par le paramètre type d’appel.

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

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT