Action du service web

Action de service unique pour l’ERP

Infinity n'utilise qu'une seule action pour tous les Services Web en mode SOAP.

Pour paramétrer cette action, utiliser Harmony : Menu Paramétrage ⇒ Actions des services

Image Removed

Image Added

Le nom par défaut a utiliser est “SYNCHRO_INFINITY_AGILEO” ce qui permet aux services Web Diva d'être appelé automatiquement par des applications externes ou internes développées par Divalto (Exemple Agiléo ou Weavy)

Image Removed

Image Removed

Image Added

Image Added

Détails:

• Active / inactif

• Résident : Le programme est chargé en permanence si actif, sinon à la demande. Voir le chapitre plus bas pour les détails

• Programme à enchainer : Nom du programme Diva de traitement métier. Le service SYNCHRO_INFINITY_AGILEO fait appel a "a5ppswagil.dhop"

• Utilisateur : par défaut, c'est un utilisateur harmony (xlogf) $webservice qui sera pris pour les contrôles d'accès et recherche d'implicites. Il est possible de renseigner un autre utilisateur, qui devra respecter les règles indiquées plus bas

• Paramètres HMP : non utilisé en standard. Permet de donner des paramètres supplémentaires au traitement appelé

Restriction d’accès (Harmony 408)

Depuis la version 408 du runtime Harmony, il existe 3 nouvelles coches

• Active SOAP : coché par défaut. Indique que ce service web accepte des appels entrants en mode SOAP

• Active REST : coché par défaut. Indique que ce service web accepte des appels entrants en mode REST

• Active WebHook : coché par défaut. Indique que ce service web accepte des appels entrants en mode WEBHOOK

Ces options permettent par exemple d’interdire un accès en mode SOAP (qui ne bénéficie pas d’authentification)

Paramétrage de l'utilisateur $webservice utilisé par le service

L'utilisateur harmony $webservice est obligatoire (si non renseigné dans le paramétrage de l'action de service) et doit exister en tant qu’utilisateur ERP en possédant un implicite pointant au moins sur divalto/sys, mais pointant surtout sur les objets .DHOP appelés par les web services (par exemple a5ppswagil.dhop).

Par défaut, l'implicite de $webservice est : Implicites$webService.txt

Image Removed

Image Added

Dans l'exemple suivant, on utilise un implicite existant pour ne pas avoir à en recréer un.

Informations sur le mode Résident (Harmony 408)

Il existe 3 valeurs du mode Résident

• Non : le programme xrtDiva du service web n’est pas résident, il est invoqué et ouvert à l’appel de service web par un appelant, et se referme après traitement

• Résident : le programme xrtDiva est déjà en mémoire lors de l’appel (il est chargé au lancement du service). Il y a toujours autant d’instance créées que de demandes entrantes

• Résident avec pool :

  • Dans le mode "résident avec pool", le WebService, quand il est invoqué, reste en mémoire en attente d'une prochaine requête.
    On évite ainsi le temps de rechargement des modules fonctionnels.

  • Les prochaines requêtes peuvent également se faire sans passer par la phase d'initialisation du WebService (ex : chargement du contexte utilisateur).
    On évite ainsi ce temps et on peut alors directement appeler le code "métier" sans recréer systématiquement le contexte de travail.
    NB : cette partie requiert une légère adaptation du code métier du WebService pour conserver le contexte de travail (et uniquement lui) entre 2 appels successifs.

  • Ces WebServices peuvent être distribués sur plusieurs processus xrtDiva. Ainsi, on a un pool de processus qui peut répondre à plusieurs demandes en parallèle.
    Il peut être par exemple, plus efficace de demander 10 calculs de tarifs en parallèle que d'effectuer une requête qui calcule 10 tarifs, puisque le client n'a pas à attendre le calcul du 10ème tarif pour connaitre le premier.
    Les traitements sont donc distribuables en parallèle.

  • Un paramétrage permet de définir le nombre et la durée de vie de ces processus.
    Par exemple : Autoriser 4 processus simultanés et fermer les processus après 10 minutes d'activité.

  • Avec ce paramétrage, les requêtes consécutives, proche dans le temps sont donc distribués sur plusieurs processus de traitement et se font vers des objets "chauds" (après phase de démarrage "chauffe = contexte métier" dans chaque processus) qui répondront rapidement aux sollicitations ultérieures.