Les webhook donnent des possibilités d’accès complémentaires aux services web
Les services web ont pour caractéristiques:
une exposition via une URL unique, qui identifie facilement le service web appelé
une exposition identique à tous les appelants potentiels
la totalité des fonctionnalités sont accessibles
les fonctionnalités sont exploitées par une URL courte et un message long
le traitement métier peut être complexe et un peu long, avec des données importantes
l’objectif principal est de faire un pont entre applications
Le webhook a une approche différente
une exposition via plusieurs URL, avec un masquage du service web appelé
une exposition différenciée par appelant
des fonctionnalités réduites sont accessibles
les fonctionnalités sont exploitées par une URL longue avec paramètres et un aucun message
le traitement métier doit être rapide et simple, synchrone, avec peu de données
l’objectif principal est de faire un lien d’accroche d’informations
Le webhook doit donc en principe permettre à une application externe de transmettre des informations, dans le sens “d’un fil d’informations continu synchrone” de l’appelant vers l’appelé, quitte à ce que cela déclenche un appel en retour vers l’appelant pour demander plus d’informations de manière asynchrone.Disponible depuis le Runtime Harmony 408
Consultez la page suivante Paramétrage SW WebHook pour plus d’informations, notamment sur les pré-requis.
(1) CODE WEBHOOK
L’appelant doit nécessairement connaître le code webhook (clé chaîne de caractères) à appeler.
Ce code est indiqué dans le paramétrage des WebHook, via le zoom dédié, accessible depuis le zoom des actions de services (Harmony : Paramétrage / Actions des services ou ERP : Administration / Paramètres / Action des services) en cliquant sur le bouton “Appel du zoom webhook”
A partir de la liste des WebHook, il existe plusieurs manières de récupérer le code webhook :
| |
|
Exemple : MONWEBHOOKACADEMY123456789012363F53
(2) URL WEBHOOK
L’URL d’un WebHook est constituée de 3 parties : URL de base de type REST + '/' + Code webhook + ‘?' + Paramètres du webhook selon le service appelé
Et est donc construite ainsi:
[TypeDeConnexion]://[Serveur]:[Port]/[ServiceWebHook]/[MonCodeWebHook]?[Parametres cle1=valeur&cle2=valeur2]
La section ServiceWebHook étant sous la forme : base commune de l'URL + '/api/v1/WebHook'
La section MonCodeWebHook étant le code webhook récupéré précédemment
La section Parametres étant la liste des paramètres envoyés au webhook sous la forme de paramètres Http : cle=valeur ou cle1=valeur1&cle2=valeur2
Voici un exemple d’appel d’un webhook qui reçoit 2 paramètres : dos et refreshCustomer
Exemple sur un poste local :
http://localhost:8080/DhsDivaltoServiceDivaApiRest/api/v1/Webhook/MONWEBHOOKACADEMY123456789012363F53?dos=998&refreshCustomer=C0000001
Exemple en Divalto cloud :
https://api.divaltocloud.com/123456/TEST1/api/v1/WebHook/MONWEBHOOKACADEMY123456789012363F53?dos=998&refreshCustomer=C0000001
Remarque |
---|
La réponse à un webhook se limite en général à un “400” ou “200” ou “0” pour indiquer que “le message est bien parvenu”, avec un message complémentaire indiquant soit la réussite ou la raison de l'échec. Un webhook n’a pas pour vocation a retourner des informations |
Exemple de réponse à cet appel sous Postman (démonstration) :
...