Tester certains SW via un utilitaire ERP

Un utilitaire développé en diva pour tester les services web est livré avec l’ERP.

Ce qu'il est

  • Il est destiné a un public technique

  • Il permet de tester certains services web métier

  • livré avec les sources publics

Ce qu'il n'est pas

  • n'est pas conçu pour un usage régulier par un utilisateur ERP

  • ne propose pas la liste complète des services web existants

  • n'est pas une règle ou norme d'écriture de source



Utilisation de l'utilitaire

L'utilitaire n'est pas au menu. Il convient d'abord de l'ajouter et de le lancer (clientswdhub.dhop) depuis l'IA.



Le premier onglet COMMUN est important et comporte des informations de paramétrage pour les appels des services :

  • un fichier (par défaut clientswdhub.txt) qui doit être crée dans le chemin implicite courant, pour tracer les demandes et réponses faites par l'utilitaire

  • l'URL du service web (par défaut pour un poste local en SOAP : http://localhost:8080/WebServiceDiva/WebServiceDiva.asmx )

  • le Dossier Divalto a utiliser (si le dossier est envoyé au service web)

  • les autres données nécessaire à l'appel d'un service web



Les onglets suivants permettent de faire appel a certains services web, regroupés par métier, par exemple en gestion commerciale:



Il faut remplir les champs du service web a tester, par exemple Interro de stock.

et cliquer sur le bouton adjacent pour appeler le service web



Déroulement

L'interface utilisateur est simplifiée.

Il n'y a pas de recherche de libellés et peu de contrôles à la saisie. Cela doit permettre de tester également des cas d'erreur, comme un champ manquant ou mal renseigné



C'est lors de l'appel au service web par clic sur le bouton noir que sont effectués certains contrôles, par exemple de champs obligatoires, mais ces contrôles sont assez réduits pour permettre de tester les cas aux limites, les cas d'erreurs ou les combinaisons de champs invalides.

SOAP ou REST

Le titre de l'onglet indique en général le mode d'appel SOAP ou REST. Il convient, selon le cas, de paramétrer les données (URL ou données d'authentification) avant de faire appel a un service web 

Exemple de paramétrage REST
Exemple de paramétrage SOAP



Un premier message indique soit une erreur de saisie importante, soit une validation de la demande de service web.

Exemple avec l'interro stock:

  • Si aucune référence article n'est saisie, le message donne une erreur "Référence obligatoire". L'appel au service web n'est pas effectué

  • Si la référence est invalide le message donne une validation "Demande interro stock validé"

    • L'appel au service web est effectué

    • C'est le service web métier qui effectue les contrôles métiers, et donne une erreur par exemple "Erreur code 2100 : Article abc inexistant"

  • Si la référence valide mais le dépôt non renseigné, le message donne une validation "Demande interro stock validé"

    • L'appel au service web est effectué

    • C'est le service web métier qui effectue les contrôles métiers, et donne une erreur par exemple "Erreur code 1117: Dépôt ' ' inexistant"

  • Si la référence est valide, et le dépôt renseigné, le message donne une validation "Demande interro stock validé"

Tant que le message d'indique pas une demande validée, aucun envoi n'a été fait au service web.



Un second message DEMANDE affiche a l'écran le message (total ou partiel) tel qu'il est envoyé au service web.



Un troisième message REPONSE affiche a l'écran le message tel qu'il est retourné par le service web.

Le code source de cet utilitaire est fourni : clientswdhub.dhsp et clientswdhub.dhsf