|
Pour ceux qui ne sont pas familiers à l’environnement ILE, il faut savoir qu’auparavant, il était impossible d’obtenir ce niveau de modularité car beaucoup trop pénalisant en terme de performance des applications. Aujourd’hui, grâce à ILE, on peut mixer du code natif et du code Java, on peut migrer en douceur vers une vraie architecture trois-tiers, on peut gérer proprement son spécifique, et le tout, sans altérer les performances de ses applications, n’est-ce pas merveilleux ?
Oui mais voilà ! Qui dit nouvelle architecture dit aussi nouveaux besoins pour les développeurs pour bien la maîtriser. C’est la raison pour laquelle nous avons régulièrement doté les suites ARCAD d’une batterie d’outillages spécifiques rendant la vie du développeur toujours plus simple. C’est évidemment le cas pour l’environnement ILE qui voit ARCAD se doter d’un référentiel de procédures, de références croisées spécifiques et d’outils de contrôle des passages de paramètres.
En bref, adopter les standards de l’environnement ILE, c’est au même titre que le standard SQL, moderniser pour longtemps ses applications System i.
LA SOLUTION ARCAD...
Objectif :
La gestion de l’ILE au sein d’ARCAD a comme objectif de permettre aux concepteurs et aux développeurs de profiter des avantages du développement modulaire que propose l’ILE, en déléguant à ARCAD le maximum des nouvelles contraintes techniques imposées par cet environnement.
Voici la liste des principaux points clés traités par ARCAD :
Documentation :
La documentation qu’ARCAD fournit pour l’ILE comprend :
- Les liens ILE : ils sont gérés sous forme de « source » de type ILEPGM ou ILESRVPGM (ou même directement sur les RPGLE, CBLLE, …). L’édition de lien est totalement assimilée à une compilation.
- Le référentiel Procédures : il liste (avec des critères de recherche) l’ensemble des procédures exportées, avec leurs paramètres. Des fonctionnalités peuvent être saisies (ou récupérées dans les sources) afin de mieux documenter l’objectif de chaque procédure, ainsi que chacun de ses paramètres.
- Les références croisées au niveau Procédures : elles permettent de visualiser les chaînes d’appel (appelants/appelés) par procédure, mais avec également les programmes OPM (car il est rare qu’une application soit totalement ILE).
- Pour chaque procédure, on peut visualiser la localisation de sa définition (code source), sa déclaration (prototype), son objet d’exécution (programme ou programme de service), son groupe d’activation ainsi que l’ensemble de ses utilisations (appels). De plus, il est possible d’exécuter la procédure de façon unitaire.
Développement :
Pour faciliter au maximum le travail des développeurs :
- Lorsqu’une compilation donne un module, tous les programmes et programmes de service qui l’incluent sont proposés à la recompilation.
- En ce qui concerne la modification de sources de procédures ou de leur prototype, il y a détection de la nature réelle de la modification effectuée par le développeur, afin d’optimiser les recompilations induites, en plus de la recompilation du module et du programme de service qui l’inclut :
- Si seul le corps de la procédure a été modifié, aucune autre recompilation.
- Si les paramètres de la procédure ont été modifiés, demande de recompilation uniquement pour les composants utilisant effectivement cette procédure
- Si de nouvelles procédures ont été ajoutées, génération éventuelle d’un source d’exportation (BND) par version permettant d’assurer la compatibilité ascendante des signatures, sans tout recompiler.
- Si des procédures ont été supprimées, il faut tout recompiler.
Mise en test / Mise en production :
Lors de l’intégration d’une version vers les environnements de tests ou la mise en production, les contrôles évoqués ci-dessus sont tous ré-effectués, mais pour tous les composants de la version. Ils s’assurent notamment que chaque compilation d’un source est bien postérieure à la dernière modification d’un source inclus qui décrit un prototype de procédure.
De plus, on peut demander également un contrôle de la cohérence des paramètres (utile lorsque les appels de procédures ne sont pas tous prototypés ou lorsque le prototype est dupliqué) avec éventuellement en plus un contrôle des paramètres pour les appels OPM.
L’ensemble des compilations est préalablement soumis à un ordonnancement automatique, qui permet de compiler les programmes de service dans un ordre précis.
|
