QA pour webMethods
Outil de vérification des développements / paramétrages sous webMethods
Description :
L’objectif de l’outil QA (Quality Assurance) est d’automatiser la détection de problèmes recurrents lors des phases de développement et de configuration sous webMethods.
La vérification s’effectue sur les éléments suivants :
- Paramètres des Packages
- Erreurs de développement dans les Flow services
- Erreurs de développement dans les Java services
- Configuration des Adapter services
- Configuration des Broker document
- Configuration des Triggers
- Configuration des Extended Settings
De manière générale, les packages suivants ne sont pas pris en compte dans QA :
- Adapter SAP webMethods (SAP)
- Tous les packages webMethods (Commencent pas Wm)
- Le code de QA (Quality Assurance)
Pour vérifier la qualité du code et le paramétrage des Integration Server, l’outil QA utilise des fichiers de règles qui se situent dans <INTEGRATION_SERVER_DIR>/packages/QA/config. Une fois les règles définies, l’analyse se fait à partir d’une IHM.
Installation :
Le package QA s’installe comme un package webMethods :
- Il faut déposer dans le répertoire <INTEGRATION_SERVER_DIR>/replicate/inbound le fichier QA.zip
- Dans Packages/Management, cliquer sur Install Inbound Release
- Choisir le fichier QA.zip et sélectionner l’option Activate upon installation, puis cliquer sur Install Release
- Dans Packages/Management, demander à activer le package QA
Accès à QA :
Pour accèder à QA, il suffit de cliquer dans le menu Solutions sur QA Manager
Pour masquer l’affichage de QA dans le menu Solutions, il suffit d’écrire un fichier vide HIDDEN dans <INTEGRATION_SERVER_DIR>/packages/QA/config
Il est aussi possible de lancer QA, en appelant directement une URL.
Exemple d’exécution sur le serveur <mon_serveur> sur le port 5555 :
http://<mon_serveur>:5555/QA/index.dsp
Paramétrage :
Pour accèder au paramétrage de QA, il suffit de cliquer dans la rubrique Configuration
Structure des fichiers de règles
Trois types d’informations sont paramétrés dans ces fichiers :
- L’analyse du développement, c’est-à-dire du code qui est précisée par le prefixe content-
- L’analyse du paramétrage d’un composant qui est précisée par le prefixe config-
- L’analyse des propriétés d’un composant / de l’Integration Server qui n’est pas prefixé
Paramétrage du fichier de règles pour les Packages
Le paramétrage, pour l’analyse des Packages, est enregistré dans le fichier package.conf. Ce fichier contient les éléments suivants :
- config-successors : Lorsque des services d’un package dépendent des services d’autres packages, il est nécessaire de référencer ces packages en tant que dépendance (Package dependancies). La valeur true indique qu’il faut faire cette vérification
- loaderr : Indique s’il faut vérifier les erreurs de chargements des packages
- loadwarning : Indique s’il faut vérifier les avertissements lors du chargement des packages
- listACL : ACL par défaut pour avoir le droit de lister les packages
- publisher : Nom du publicateur d’un package
Paramétrage du fichier de règles pour les Flow services
Le paramétrage, pour l’analyse du contenu des Flow services, est enregistré dans le fichier flowservice.conf. Ce fichier contient les éléments suivants :
- content-restorePipeline : Permet de vérifier s’il y a des appels au service pub.flow:restorePipeline
- content-restorePipelineFromFile : Permet de vérifier s’il y a des appels au service pub.flow:restorePipelineFromFile
- content-savePipeline : Permet de vérifier s’il y a des appels au service pub.flow:savePipeline
- content-savePipelineToFile : Permet de vérifier s’il y a des appels au service pub.flow:savePipelineToFile
- content-tracePipeline : Permet de vérifier s’il y a des appels au service pub.flow:tracePipeline
- content-debugLog : Permet de vérifier s’il y a des appels au service pub.flow:debugLog
- config-stateless : Les services doivent-ils être configurés en stateless
- config-caching : Les résultats d’exécution doivent-ils être mis en cache
- config-prefetch : Le cache du service doit-il être rafraîchi automatique quand il expire
- config-auditoption : Configuration de l’audit des services (0: Never, 1: Alaways, 2: When top-level service only)
- config-retry_max : Nombre d’essais pour exécuter un service qui ne s’est pas terminé correctement
- config-retry_interval : Attente entre chaque essais
- config-svc_in_validator_options : Les paramètres d’entrée des services doivent-ils être vérifiés
- config-svc_out_validator_options : Les paramètres de sortie des services doivent-ils être vérifiés
Par défaut, les éléments suivants sont analysés :
- Les étapes désactivées et non supprimées dans les Flow services
- Les Flow services sans contenu
- L’utilisation au sein des Flow services de services qui n’existent plus
Paramétrage du fichier de règles pour les Java services
Le paramétrage, pour l’analyse du contenu des Java services, est enregistré dans le fichier javaservice.conf. Ce fichier contient les éléments suivants :
- check-deadcode : Analyse s’il y a du code, développé dans la partie Shared / Source d’un java service, qui n’est pas utilisé
- content-java.io.PrintStream.print : Le code contient-il des appels à System.out.println()
- content-java.lang.System.out.print : Le code contient-il des appels à System.out.println()
- config-stateless : Les services doivent-ils être configurés en stateless
- config-caching : Les résultats d’exécution doivent-ils être mis en cache
- config-prefetch : Le cache du service doit-il être rafraîchi automatique quand il expire
- config-auditoption : Configuration de l’audit des services (0: Never, 1: Alaways, 2: When top-level service only)
- config-retry_max : Nombre d’essais pour exécuter un service qui ne s’est pas terminé correctement
- config-retry_interval : Attente entre chaque essais
- config-svc_in_validator_options : Les paramètres d’entrée des services doivent-ils être vérifiés
- config-svc_out_validator_options : Les paramètres de sortie des services doivent-ils être vérifiés
Pour ajouter d’autres classes à rechercher dans les Java service, il faut ajouter dans le fichier javaservice.conf, le nom de la classe à rechercher prefixée par content-, exemple :
- Pour analyser l’utilisation de la classe Vector, il faut mettre dans le fichier de configuration : content-java.util.Vector
Par défaut, les éléments suivants sont analysés :
- Les Java service qui ne peuvent pas être compilés
- Les Java service qui n’ont pas de contenu
Paramétrage du fichier de règles pour les Adapters services
Le paramétrage, pour l’analyse du contenu des Adapter services, est enregistré dans le fichier adpservice.conf. Ce fichier contient les éléments suivants :
- config-stateless : Les services doivent-ils être configurés en stateless
- config-caching : Les résultats d’exécution doivent-ils être mis en cache
- config-prefetch : Le cache du service doit-il être rafraîchi automatique quand il expire
- config-auditoption : Configuration de l’audit des services (0: Never, 1: Alaways, 2: When top-level service only)
- config-retry_max : Nombre d’essais pour exécuter un service qui ne s’est pas terminé correctement
- config-retry_interval : Attente entre chaque essais
- config-svc_in_validator_options : Les paramètres d’entrée des services doivent-ils être vérifiés
- config-svc_out_validator_options : Les paramètres de sortie des services doivent-ils être vérifiés
Paramétrage du fichier de règles pour les Brokers documents
Le paramétrage, pour l’analyse des Brokers documents, est enregistré dans le fichier documents.conf. Ce fichier contient les éléments suivants :
- config-timeToLive : Vérifie la durée de vie du document sur le broker
- config-storageType : Vérifie le type des documents (guaranteed, volatile)
Les problèmes de nommage des documents entre le broker et l’IS, sont aussi analysés par défaut.
Un service complémentaire QA.QARepair:RepairPackageDocument est utilisable pour corriger les problème de nommage des broker document.
En paramètre du service, il faut indiquer le nom du package contenant des documents ayant des problèmes de nommage.
Paramétrage du fichier de règles pour les Triggers
Le paramétrage, pour l’analyse des Triggers, est enregistré dans le fichier trigger.conf. Ce fichier contient les éléments suivants :
- processingSuspended : Vérifie les triggers qui sont en pause
- retrievalSuspended : Vérifie les triggers qui ne récupère pas de document sur le broker
- concurrent : Traitement en parallèle au pas des documents
- deliverEnabled : Vérifie si le trigger est activé
- executeEnabled : Vérifie si le trigger est activé
- maxConcurrentThreads : Vérifie le nombre document qui peuvent être traîtés en parallèle
Paramétrage du fichier de règles pour les Extended settings
Le paramétrage, pour l’analyse des Extended settings, est enregistré dans le fichier settings.conf.
Il suffit d’indiquer dans ce fichier, l’ensemble des paramètres à vérifier, avec leur valeur.
Utilisation :
Pour accèder à l’analyse du code / de la configuration d’un IS, il suffit de cliquer dans la rubrique Analyse
Exemple de résultat :
Téléchargement v1.1.6 :
- Binaires (532 Ko)
jvm 1.4.2 minimum
fonctionne sur webMethods Integration Server 6.x et 7.x
Utilisation des classes du projet Byte Code Engineering Library (BCEL) : http://bcel.sourceforge.net/
Utilisation des classes du projet Regular Expressions for Java (gnu.regexp) : http://nlp.stanford.edu/nlp/javadoc/gnu-regexp-docs/
