Principe de fonctionnement des SW Divalto ERP

Pour comprendre le fonctionnement des services web avec Divalto, voici un schéma illustré avec des notions simples sur le traitement d'un courrier papier.

Open

Courrier métier

1. Le demandeur rédige un message pour le service métier auquel il s'adresse, par exemple une lettre de réclamation adressée au service client de l'entreprise.

2. Ce message, portant un objet, est mis sous enveloppe et placé dans un colis de transport.

3. Le colis de transport va utiliser un moyen de transport pour entrer dans l'entreprise identifiée par son adresse, par exemple Cedex 1.

4. L'enveloppe est sortie de son colis pour être remis au service courrier de l'entreprise.

5. Le service courrier ouvre l'enveloppe, extrait l'objet et dépose le message au service métier selon l'objet de la lettre.

6. Le service métier exploite le message et effectue son traitement, et apporte une réponse au demandeur.

Formulaire de demande de données

1. Le demandeur remplit un formulaire de demande de données

2. Le formulaire va utiliser un moyen de transport pour entrer dans l'entreprise par un accès dédié RECORSQL

3. Le service RECORDSQL recherche les données, et renvoie les données au demandeur

et son parallèle sur le traitement d'un appel de service web

Open

Service web métier

1. Le demandeur construit un message pour le service web métier auquel il s'adresse, par exemple un message de création d'évènement CRM.

2. Ce message, portant une action, est enveloppé selon le protocole de transport cible par des balises XML ou JSON, et placé dans un flux complet XML ou JSON.

3. Le flux complet XML ou JSON va utiliser un protocole de transport via l'URL du serveur web pour entrer l'action de service web Harmony.

4. L'enveloppe XML ou JSON est sortie du flux complet pour être remis à l'action de service web, par exemple SYNCHRO_INFINITY_AGILEO.

5. L'action de service web extrait de l'enveloppe XML ou JSON l'action métier, et dépose le message au traitement Diva métier selon l'action.

6. Le traitement Diva métier exploite le message et effectue son traitement, et apporte une réponse au demandeur (format XML ou JSON selon le service métier).

Service API Recordsql

1. Le demandeur remplit une de demande de données au format JSON

2. Le flux JSON va utiliser un protocole de transport REST via l'URL du serveur API Recordsql pour un traitement natif

3. L'API RECORDSQL recherche les données en exécutant une requête SQL , et renvoie les données au demandeur (format JSON)

Il faut bien distinguer les 5 éléments qui entrent dans un dialogue service web ou API.

1. Le MESSAGE

Le MESSAGE doit être dans le format attendu pour l'exécution d'une ACTION METIER.

C'est l'écriture du traitement Diva (qui va gérer l'action métier) qui détermine

• le contenu possible de ce message : il est donc spécifique a chaque action métier, par exemple : interroger un stock, consulter des droits, déposer un dataset.

• le format : par exemple : balises HMP, texte XML, texte JSON

Pour connaître les messages, il faut consulter la documentation concernant les actions métier

2. Le MODE DE TRANSPORT

Le MODE DE TRANSPORT impose une technologie aux échanges, notamment tout ce qui enveloppe le message (authentification, format, styles, schémas)

Harmony permet l'utilisation de deux technologies

• mode de transport SOAP qui utilise un format XML

• mode de transport REST qui utilise un format JSON 

3. Le SERVICE IIS

Le SERVICE IIS est le composant qui permet d'exposer des services web sur internet ou sur le réseau de l'entreprise.

Le service IIS permet a un appelant d'avoir une URL (adresse internet sous la forme HTTP://monAdresse/serviceIIS) qui lui permet de faire une demande de service web ou API.

Harmony fournit deux service IIS

• un SOAP, sous la forme http://localhost:8080/WebServiceDiva/webservicediva.asmx

• un REST, sous la forme http://localhost:8080/DhsDivaltoServiceDivaApiRest/api/v1/WebService/

Chacun de ces services a son propre paramétrage, et nécessite une installation préalable.

Sur un poste Windows, Internet Information Service est une fonctionnalité a activer

4. Le SERVICE WEB HARMONY - Action de service web (pour un service métier uniquement)

Le SERVICE WEB HARMONY, ou action de service web, fait l'intermédiaire entre le SERVICE IIS et le traitement Diva indiqué dans le paramétrage harmony des actions de services web.

Il sert uniquement a aiguiller le MESSAGE de l'appelant vers le traitement Diva en fournissant un contexte d'exécution (droits ERP et implicites).

Ce service web va donc utiliser la partie ACTION du MESSAGE pour déterminer le traitement de l'action

Divalto propose de configurer deux services web harmony afin de bénéficier des services web métiers standard fournis avec l'ERP.

• Le service web harmony SYNCHRO_INFINITY_AGILEO, qui fait appel au traitement générique A5PPSWAGIL.DHOP, et qui a été développé historiquement en mode SOAP

• Le service web harmony WEB_SERVICE_INFINITY, qui qui fait appel au traitement générique A5PPSWINFINITY.DHOP, et qui a été développé en mode REST

Pour des raisons de cohérence :

• les services web métier passant par le service web standard SYNCHRO_INFINITY_AGILEO (qui a été fait pour du mode de transport SOAP) ont été développés pour recevoir des messages au format XML.

• les services web métier passant par le service web standard WEB_SERVICE_INFINITY (qui a été fait pour du mode de transport REST) ont été développés pour recevoir des messages au format JSON.

Les combinaisons sont possibles !

• on peut appeler un service web métier qui attend un message XML depuis un transport REST

• on peut appeler un service web métier qui attend un message JSON depuis un transport SOAP

5. Le TRAITEMENT DIVA / ACTION METIER

5.1 Pour un service métier

L'ACTION METIER est réalisée par un TRAITEMENT DIVA qui va exploiter la partie PARAM du MESSAGE.

Le traitement exploite donc directement le PARAM reçu pour effectuer le traitement métier demandé par l'appelant.

5.2 Pour un service API Recordsql

Le traitement est effectué directement par l'API RecordSql, avec exécution d'une requête SELECT dans la base de donneés.

Cette requête utilise la couche d'accès aux données que sont les RecordSql Diva.

5.3 Pour un service WebHook

Le WebHook est un autre mode d'exposition d’un service web. Toute la mise en œuvre des services web SOAP ou REST et d’une action de service sont donc requis au préalable.

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 et sécurisé. Aucune authentification n’est requise pour un WebHook, car le principe est de permettre facilement à un appelant de transmettre une information.