Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/PAI/pages/10516504893/Technique+et+surcharge+Services+web) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 8) afficher la version suivante »

Appel de service web en GraphQL

Le GraphQL est un langage de requêtes et un environnement d'exécution open-source qui propose une alternative aux API REST. Il est utilisé, notamment dans des services publics.

Les instructions Diva d'appel de services web permettent de traiter ce type de langage, car les interactions se font avec des couches de niveau basses par les instructions WebRequestxxxx.

Envoi de message GraphQL

Un token doit être stocké par ailleurs.

L’envoi se fait en méthode POST avec transmission du TOKEN et du type dans le Header et le corps du message est MESSAGEBODY dont on trouve deux exemples plus bas.

Exemple de message d’interrogation

Exemple de message de mise à jour/mutation

Modules en surcharge de service web

Tous les services web ont une partie du code plus ou moins importante surchargeable, soit pour le traitement métier ou le mapping de champs.

 

Modules pour SW REST - WEB SERVICE INFINITY

Code service web

Modules de surcharges

Remarques

Code service web

Modules de surcharges

Remarques

associer_fichier

a5tmswinfinity

Ouvertures

interrogation_encours

(aucun)

Appel du tunnel via RCPM000

integration_ecriture

cctmswinfinity

Ouvertures

integration_reglement

rctmswinfinity

 

interroger_stock

gttmswinfinity

 

gttmmapping

Ouvertures

Remplir_Interroger_Stock_Json fait le traitement

Mapping de champs existant

interrogation_ouvrage

(aucun)

 

integration_dtr

gttmdtr200

Ouvertures

interroger_resume_affaire

gatmmapping

Mapping de champs possible

interrogation_commande

gttmmapping

Mapping de champs existant

integration_piece

gttmswinfinity

gttmmapping

Ouvertures

Mapping de champs existant

integration_equipement

gttmswinfinity

gttmmapping

Ouvertures

Mapping de champs existant

 

 

Modules pour SW SOAP- SYNCHRO INFINITY AGILEO

Code service web

Modules de surcharges

Remarques

interroger_stock

gttmswdav

Remplir_Interroger_Stock fait le traitement

interroger_resume_affaire

gatmswagil

Remplir_interroger_resume_affaire fait le contrôle

 

Surcharge pour Agiléo

Entités Agiléo

Ajouter de nouvelles ENTITES disponibles dans le studio DS-agileo.
Pour rajouter des recordSQL à la liste des entités disponible dans le studio DS-agileo il faut déclarer en public les recordSQL dans une surcharge du module A5tmswagil.dhop

Et rajouter le traitement des recordSQL déclarés dans la fonction lire_ENTITES_SPE

Lecture de données de recordSQL déclarés en surcharge

La commande INFOS_INFINITY permet de lire les données d'un recordSQL déclaré en surcharge à condition de respecter les règles suivantes :
-La déclaration du recordSQL doit être faite dans une surcharge du module A5TMSWAGIL.dhop
-La fonction Desc_champ_spe doit être présente dans le module de surcharge
Attention : ne pas oublier l'option KeepDataNames


Surcharge pour nouvelles actions de service web

Pour créer de nouveaux services web, il est possible de développer directement un nouveau Service Web Harmony (action des services) qui fera appel a un nouveau traitement Diva.

Il est également possible de créer des actions spécifiques a l'intérieur du service web existant, par exemple SYNCHRO_INFINITY_AGILEO ou WEB_SERVICE_INFINITY.

La réalisation se fait en deux surcharges : une pour aiguiller la demande d'action métier vers un module, l'autre pour traiter la demande

Surcharge pour router vers le module traitement

Pour qu'elles soient traitées par les Web Service Diva existant, il existe une ouverture dédiée vers une fonction

  • 'A5TTSWAGIL / Traitement_specifique' pour a5ppswagil qui correspond a SYNCHRO_INFINITY_AGILEO 

  • 'A5TTSWINFINITY / SW_Infinity_JSON_Traitement_specifique' pour a5ppswinfinity qui correspond a WEB_SERVICE_INFINITY


Il faut donc ajouter dans ces fonctions les NOMS D'ACTION métier a traiter en complément du standard, et indiquer dans quel MODULE le traitement se fait.

Le nom d'action est nécessairement identique au nom de la fonction Diva qui effectue le traitement.

Exemple : on traite ici une nouvelle action métier MAFONCTIONXML qui va faire appel a la fonction MaFonctionXml dans le module A5UMSWAGIL.dhop

Surcharge pour le traitement

Le traitement prend en entrée la chaîne de paramètres reçus par le service web.

La chaine en retour doit indiquer le résultat du traitement, qu'il soit en réussite ou en échec, et pour quelles raisons.

Exemple : on traite ici la partie métier dans A5UMSWAGIL.dhop. La fonction reçoit un xml en entrée et construit un xml de sortie.



Paramétrage SW REST en cas de surcharge de recordSql

Le fichier DhsDivaltoServiceDivaApiRest_ParamERP.xml indique les options du traitement des appels REST de lecture par RecordSql .

RecordSql ERP

Pour un appel des recordSql standard ERP Infinity, ce paramétrage n'est pas utille, car le service web RecordSql va charger par défaut les compléments nécessaires.

Dans le cas d'une surcharge, il peut s'avérer nécessaire de compléter ce paramétrage


DhsDivaltoServiceDivaApiRest_ParamERP.xml.xml
<?xml version="1.0" encoding="utf-8"?>
<params>
  <commontables>
    <!-- <dhoq Name="gtrstab.dhoq" RecordSQL="TABLECOMMUNE" Read="1" /> -->
    <!--<dhoq Name="pprsdos.dhoq" RecordSQL="PDOSSIER" Read="1" RecordSQLbis="DOSSIER"/> -->
    <!--<dhoq Name="ccrsdos.dhoq" RecordSQL="DOSEXP" Read="1" /> -->
    <!--<dhoq Name="qursdos.dhoq" RecordSQL="EXPERT_QUAL" Read="1" /> -->
    <!--<dhoq Name="gmrsdos.dhoq" RecordSQL="EXPERT_GRM" Read="1" /> -->
    <!--<dhoq Name="corsdos.dhoq" RecordSQL="EXPERT_CONT" Read="1" /> -->
    <!--<dhoq Name="dorsdos.dhoq" RecordSQL="EXPERT_DDOC" Read="1" /> -->
    <!--<dhoq Name="gtrsdos.dhoq" RecordSQL="DOSSIERCRM" Read="1" /> -->
    <!-- <dhoq Name="wmrstab.dhoq" RecordSQL="TCOMMUN" Read="1" /> -->
  </commontables>
  <commonfields>
    <!--<field Name="DOS" /> -->
    <!--<field Name="DOSCPT" /> -->
    <!--<field Name="ETB" /> -->
    <!--<field Name="DEPO" /> -->
  </commonfields>
  <commonoptions>
    <!-- <namepathobjets  	 Value="Objets" />  -->
    <!-- <namefileimplicites Value="ImplicitesDefaut.xml"	/> -->
    <!-- <namefileconnexions Value="connexions.xml"	/> -->
    <!-- <userdhoq 	         Value="a5rsdos.dhoq"	/> -->
    <!-- <userrecordsql 	   Value="UTILISATEUR"	/> -->
    <!-- <userwhere  	       Value="Equal_User"	/> -->
    <!-- <userwherefield  	 Value="USERX"		/> -->
    <!-- <authdhoq   	       Value="a5rsdos.dhoq"	/> -->
    <!-- <authrecordsql 	   Value="APPLIAUTORIS"	/> -->
    <!-- <authwhere          Value="Equal_Userx"	/> -->
    <!-- <authwherefield 	   Value="USERX"		/> -->
    <!-- <authfieldapplic	   Value="APPLIC"		/> -->
    <!-- <namerecordmz   	   Value="MZ"		/> -->
  </commonoptions>
</params>



Balises COMMONTABLE

Après avoir chargé un utilisateur, le service web charge une liste de tables qui correspondent aux différents « flags et options  » de l’utilisateur. Cces flags et options servent dans les requêtes sql, par exemple pour savoir si une table doit être lu dans le dossier spécifique de l’entreprise ou dans le dossier général 999. Ces valeurs servent donc dans les clés de recherche des requêtes sql.


C’est une liste, on peut donc ajouter des lignes a cette liste.L’ordre de lecture se fait selon l’ordre de cette liste.

Le but est de garder en mémoire toutes les noms  «  table.nom du champs » avec la « valeur du champ », pour toutes les tables qui sont décrites dans cette liste .

Exemple si la clé de recherche d’un au record sql  est    where  TABLECOMMUNE .type001 = ‘1’     => on va pouvoir résoudre ce cas car on connait alors la valeur de TABLECOMMUNE .type001 pour cet utilisateur qui peut être 0 ou 1


Chaque ligne comporte :  

  • le nom du dhog,

  • le nom de la table

  • read

    • 1 => lire la table

    • 0 => il n’y a pas de lecture de la table, cela sert si on veut désactiver une ligne mais sans perdre l’information que contenait cette ligne

  • RecordSQLbis => selon la version de l’erp ,le nom de la table à changée, si la table recordsql n’existe pas alors le moteur fait la recherche sur la table record sql bis


Balises COMMONFIELDS

Liste des champs que l'on souhaite charger en plus dans les recordsql pour avoir la bonne valeur par exemple MZ.DOS = ‘xxx’

Dans les requêtes sql, les clés se basent sur ce type de champ, on charge donc directement leurs valeurs


Balises COMMONOPTIONS

Liste des informations nécessaires pour charger et traiter les dhoq. Usage réservé


Paramétrage SW REST des environnements

Le fichier DhsDivaltoServiceDivaApiRest_ListENV.xml concerne la gestion des environnements REST.

Le paramétrage dans ce fichier est optionnel. Par défaut lors d'un appel du service web (qui se fait avec indication de l'environnement), les données de description des environnements sont chargées à partir de la base de registre windows.

Il est possible de gérer les environnements en dehors du mode regedit en mettant les valeurs des description des environnements


La requête d’authentification indique un environnement et le service web REST charge les valeurs de l’environnement

en lisant la base de registre, mais on peut mettre ces valeurs directement dans le xml DhsDivaltoServiceDivaApiRest_ListENV.xml


<?xml version="1.0" encoding="utf-8"?>

<params>

  <envs>

    <env Name="ERP213"  Path="xxxxxxx,null,null, "  Default="0"  />

    <env Value="ERP214" Path="xxxxxxx,nul … etc "/>

    <env Value="ERP215"  Forcer="1"  />  

  </envs>

</params>


Name ou Value indique le nom de l’environnement

Path indique la ligne qui est comme celle qui est dans regedit au chapitre environnement

Avec on peut mettre

Default="1" ;indique l’environnement par défaut si la requête ne contient pas d’environnement

Ou bien ( mais pas les deux ca n’a pas de sens )

Forcer="1"   ;indique qu’on veut toujours forcer l’environnement, le champ qui provient de la requête est ignoré et il est toujours remplacer par celui qui est écrant dans Name ou Value .


DhsDivaltoServiceDivaApiRest_ListENV.xml
<envs>
    <!-- <env Name="ERP213"  Path="xxxxxxx,null,null," Default="0"  /> -->
    <!-- <env Name="ERP214"  Path="xxxxxxx,null,null," Default="1"  /> -->
</envs>


Développement WebHook

Depuis une exécutions sur le serveur, un programme diva peut connaitre des informations de paramétrage, comme le numéro de webhook pour une action de service et inversement.

public function char GetWebHookAction (action,&err)
;permet de récupérr le code webhook à partir d'un code action service web
1  action   A
1  err		X

public function char GetWebHookActionNext (&err)  
;permet de récupérer le suivant après un appel à GetWebHookAction lorqu'il y a plusieurs webhook pour la même action
1  err		X

public  function char GetActionWebHook(webhook,&err)
;permet de connaitre l’action qui est définie sur un numéro de webhook
1  webhook  A
1  err		X

public function char GetWebHookUrl(serveur,port,service,webhook,modehttps)
;construit le lien url en fonction du numéro de webhook et du paramétrage
1	serveur	A
1	port		6,0
1   service  A
1	webhook  A
1   modehttps x = FALSE

Il est possible d’appeler directement un webhook avec les instructions WebRequest

  • Aucune étiquette