par James Hoopes - Mis en ligne le 24/06/02
Quand vos applications Domino interagissent
avec la base de données
iSeries, vous souhaitez des transactions
sûres, fiables et rapides. Mais pour accéder
aux données iSeries depuis
Domino, on utilise en principe ODBC ...
... qui n'est pas toujours rapide ou fiable.
Traiter des transactions qui demandent
de multiples mises à jour de fichiers,
avec ODBC, n'est ni fiable ni facile.
Supposons, par exemple, qu'on veuille
mettre à jour quatre fichiers pour effectuer
une transaction, mais que seules
les deux premières mises à jour réussissent.
Que faire alors ?
Pour régler ce problème, et
d'autres aussi, songez à utiliser les procédures
cataloguées de vos applications
Domino qui accèdent aux données
iSeries. Une procédure
cataloguée peut réduire le volume de
communications entre votre application
et l'iSeries, améliorant du même
coup les performances. Vous pouvez
aussi écrire des procédures cataloguées
cataloguées
qui traitent de multiples transactions
dans une procédure. Et réduire
du même coup le code de traitement
d'erreurs dans les applications.
Pour éclairer le concept des procédures
cataloguées, nous allons suivre
un exemple simple d'application
Domino utilisant une telle procédure.
(Pour plus d'informations sur les procédures
cataloguées, voir l'encadré
« Autres lectures ») Commençons par
quelques généralités sur les procédures
cataloguées.
Vous avez peut-être déjà exécuté des
instructions SQL à partir d’applications
Domino en utilisant ODBC. Mais une
procédure cataloguée est une autre affaire.
On peut assimiler une procédure
cataloguée à une application SQL compilée.
Au lieu de transmettre une
instruction SQL, on appelle une instruction précompilée. D’ailleurs, la
plupart des outils et des langages qui
utilisent SQL ou une technologie
connexe (JDBC, par exemple) peuvent
utiliser des procédures cataloguées.
De plus, une procédure cataloguée
n’est pas forcément SQL. D’ailleurs,
l’exemple utilisé dans cet article appelle
un programme CL. ODBC et
votre application Domino se soucient
peu de ce qui est appelé pourvu que
cela traite les paramètres correctement.
Si l’on transmet deux paramètres
à la procédure, le programme
de procédure cataloguée doit attendre
deux paramètres des types de données
appropriés.
J’ai dit plus haut que les procédures
cataloguées améliorent les performances
des applications en réduisant
le volume de communications.
Supposons que pour consulter le
contenu d’une commande, il faille accéder
au fichier maître client et au fichier
des commandes ouvertes. Sans
procédures cataloguées, l’application
Domino doit exécuter deux instructions
SQL pour accéder à ces données.
Chaque instruction SQL représente les
données transmises à , et traitées par,
l’iSeries puis retransmises à l’application
Domino. Dans cet exemple,
l’usage d’une procédure cataloguée réduit
la communication de moitié.
La procédure cataloguée peut aussi
être un programme RPG ILE. Dans ce
cas, on transmet à la procédure un numéro
de client et un numéro de commande
; elle accède aux deux fichiers
et renvoie des données comme le nom
du client, la date de la commande, et le
total de la commande. Cette tâche ne
demande qu’un appel à l’iSeries au lieu
de deux, ce qui améliore à nouveau la
performance.
L’autre intérêt des procédures cataloguées
est une meilleure fiabilité. Si
un client appelle et modifie une commande,
il faudra peut-être accéder au
fichier maître client, au fichier des entêtes
de commandes, et au fichier de
détail des commandes. Il faudra donc
exécuter trois ou plus SQL Updates, Deletes et/ou Inserts. Mais qu’en est-il
si l’on peut mettre à jour le détail des
commandes mais pas leur en-tête ?
Comme on ne peut pas laisser ces fichiers
désynchronisés, il faut annuler
les modifications apportées au fichier
de détail des commandes et informer
l’utilisateur que la mise à jour a
échoué. L’application Domino doit par
conséquent tester le code de renvoi de
chaque instruction SQL et, si l’une
échoue, supprimer les modifications
précédentes réussies.
Là encore, si l’on utilise une procédure
cataloguée pour traiter les mises à
jour, il suffit de transmettre un seul ensemble
de données et de tester un code de renvoi. La procédure cataloguée
peut annuler toute modification
effectuée si une mise à jour échoue.
Par conséquent, le programme frontal
est plus facile à écrire et plus fiable.
Entrons maintenant dans mon
exemple de procédure cataloguée.
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.