XMT_CALL - Les ouvertures
- Bertrand Littel
C’est quoi un Xmt_call
Le “Xml_call” est une fonction/procédure diva métier, présente partout dans les couches métier.
Elle permet ce qu’on appelle habituellement une “ouverture”, c’est à dire que le code diva standard “laisse une ouverture” dans du code de surcharge pour venir compléter ou modifier le codage standard.
Ces ouvertures sont placées
dans du code de programme principal (xxPP)
dans du code de module principal (xxPM)
plus rarement dans un traitement (xxTT, xxTE)
Il peut exister plusieurs formes d'écriture, car chaque module implémente une forme de xmt_call. On peut donc trouver
a5_xmt_call()
g3_xmt_call()
(etc…pour tous les modules)
xmt_call() mais qui n’est qu’une redéfinition de l’un des précédent
Principe d’un Xmt_call
Un Xmt_call a pour but d’appeler une ouverture, le nom de l’ouverture étant indiqué dans le xmt_call. Il va donc faire une recherche :
a partir du MZ.MTCLE courant. Cette variable de programmation indique le nom de l’objet compilé dans lequel sera cherché l’ouverture
en premier d’une PROCEDURE portant le nom indiqué. Si une procédure existe elle est appelée, et le Xmt_Call retourne 'O' dans tous les cas
en second d’une FONCTION portant le nom indiqué. Si une fonction existe elle est appelée, et le Xmt_call retourne la valeur retournée par la fonction
s’il n’y a ni l’un ni l’autre, Xmt_Call retourne 'O'
On voit ici ses caractéristiques principales :
l’xmt_call a pour vocation d’appeler une ouverture si elle existe
son absence n’est en aucun cas un problème, c’est une possibilité offerte
l’ouverture doit existe dans le MZ.MTCLE qui est, sauf rares exceptions, le xxTT du programme en cours de traitement
Le code qui fait appelle à un Xmt_call peut l'écrire de plusieurs manières
Code d’appel de l’ouverture | Usage | Remarques |
|---|---|---|
Xmt_call (nomDeLOuverture) | Ouverture sans exploitation du résultat | Si l’ouverture a besoin de variables, elles sont forcément publiques |
var = Xmt_call (nomDeLOuverture) | Ouverture avec exploitation du résultat | Le retour par défaut est 'O' |
On voit ici se caractéristiques secondaires
il n’y a pas de passage de variable dans un xmt_call
majoritairement ce sont des procédures qui sont appelées pour fournir des ouvertures/point de passage
l’ouverture utilisera les variables ou enregistrements publics (vu qu’il n’y a pas de variable transmise)
il n’y a jamais de problème à appeler une ouverture, puisque l’appelant en cas d’exploitation du retour considère 'O' comme la valeur normale
l’appelant traite ou non la réponse de l’ouverture. Cela dépend de la raison de l’ouverture
Il faut considérer que l’ouverture, si elle venait à disparaitre, ne remette pas en cause le fonctionnement normal
La valeur ‘normale’ de retour d’un xmt_call est ‘O' quel que soit son nom. Il faut donc prêter attention au nommage vs le comportement attendu, car si le comportement attendu par défaut est par exemple un blocage, la fonction portera un nom qui fait entendre ceci.
Par exemple une ouverture nommée “AccepterVentilation” a pour comportement par défaut de répondre ‘O' et donc implicitement le comportement attendu est d’accepter une ventilation. Si je supprime l’ouverture “AccepterVentilation”, le xmt_call retournera ‘O' ; la fonction d’ensemble doit continuer à fonctionner, et donc accepter par défaut toutes les ventilations.
A l’inverse une ouverture nommée “RejeterArticleFerme” est volontairement inversée dans son sens, pour indiquer que par défaut le comportement attendu est de rejeter un article fermé. Si je supprime l’ouverture “RejeterArticleFerme”, le xmt_call retournera ‘O' ; la fonction d’ensemble doit continuer à fonctionner, et donc rejeter les articles fermés. L’ouverture permet donc ici de tester des critères qui permettraient d’accepter un article fermé, et donc de retourner 'N' !!
Le Xmt_call_sql
Le Xmt_call_sql a été introduit avec l’apparition des RecordSql.
Le fonctionnemen est exactement le même, mais avec le passage obligé en variable du recordSql courant (le recordsql principale concerné par l’ouverture)
Exemples
Xmt_call_sql dans le CBN
Exemple pour la lecture des entrées forcées dans le CBN
On voit ici 2 ouvertures dans GTPP761:
VentilationEF_Selection_Stock_Av
placé juste après le placement des conditions WHERE
transmet le RecordSql Ventilation_Lire
but : permettre dans l’ouverture de compléter les conditions WHERE
le clauses where indispensables ne sont pas accessibles en surcharge
VentilationEF_Selection_Stock
placé dans la boucle de lecture
transmet le RecordSql Ventilation_Lire
but : ventilation par ventilation, permet de tester des critères qui ne seraient pas possibles en clauses WHERE
On voit ici les 2 implémentations des ouvertures dans GTTT761 :
VentilationEF_Selection_Stock_Av
reçoit le RecordSql Ventilation_Lire
positionne des conditions complémentaires
Procedure : aucun retour
VentilationEF_Selection_Stock
reçoit le RecordSql Ventilation_Lire
permet de tester des données de la ventilation courante
Fonction : retour ‘O' par défaut
Xmt_call dans un module PM
Exemple d’ouverture générique de haut niveau
On voit ici du code métier appelé pour initialiser ou modifier le titre d’une fenêtre. Ce code intermédiaire est appelé par tous les programme qui ont un visuel écran.
Cette procédure métier de niveau intermédiaire offre une ouverture générique : “Titre_fenetre_av”
Cette ouverture peut exister ou non
elle est par exemple présente dans le GGTT100 pour compléter le titre par défaut
elle est absente de la majorité des programmes, mais la possibilité est offerte de l’ajouter
Une ouverture placée dans un xxPM ou un xxTM est toujours appelée dans le xxTT ! Ce n’est pas parce l’ouverture est dans un xxPM que l’on fait appel au xxTM