Déploiement des Web Services

Documents WSDL

Liste des services disponibles

L'URL suivante retourne une page HTML qui recense l'ensemble des services métiers (paquets de services et requêtes) disponibles.

http://localhost/myapp/server/soap.l1000?wsdl

Accès au fichier WSDL d'un service

Le serveur 1000 offre un point d’accès pour obtenir les fichiers WSDL :

Pour un paquet de service :

http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service

Pour une requête publiée :

http://localhost/myapp/server/soap.l1000?wsdl=query.Nom_de_la_requete.drp

La réponse est le document WSDL du paquet demandé ou une faute SOAP en cas d’échec.

Transformation des adresses de service

Lorsque vous implémentez des Services en utilisant des Web Services il est probable que leur adresse physique dépende de la configuration du déploiement chez votre client. Par exemple un service dont l’adresse en cours de développement est http://localhost/myapp/serveur/soap.l1000 sera déployé sur un serveur de production de votre client comme http://dupontsa/comptabilite/serveur/soap.l1000

Cependant, pour un client WS, l’adresse du service est l’adresse contenue dans son descriptif de service (WSDL) qu’il a obtenu lors de l'importation et stocké dans le paquet métier correspondant. Il est donc nécessaire de disposer d’un mécanisme permettant de transformer les adresses des services en adresses réelles de déploiement au moment de l’exécution.

Ce mécanisme est accessible dans l’administrateur.

Appel d’un serveur spécifique.

Dans certains cas il est possible de que vous souhaitiez appeler l’implémentation d’un serveur spécifique à la place du serveur défini dans le document WSDL ; pour cela utilisez la variable HostName définie sur les objets supportant les services distants :

var inst:ICinteropService;
begin
  inst := ICinteropService.Create;
  inst.HostName := 'http://marseille/comptaibilite/serveur/soap';
…
end ;

Le nom de serveur que vous définissez ainsi sera utilisé à la place de l’adresse défini dans la classe de service distant ; ce nom sera toutefois transformé suivant la liste d’alias de service définie dans l’administrateur. Il est donc préférable d’écrire :

var inst:ICinteropService;
begin
  inst := ICinteropService.Create;
  inst.HostName := 'Marseille';
…
end ;

et de définir l’adresse de Marseille dans l’administrateur.

Boucle local.

Si vous construisez une application métier qui expose des services métiers à travers des Web Services il est possible que votre code métier ait besoin d’appeler ces services. Lorsque l’implémentation de ces services est présente dans le modèle métier au moment de l’appel, il peut être souhaitable d’utiliser directement cette implémentation au lieu d’effectuer un appel externe sur un serveur implémentant ce Web Service.

Contrôle du mode de bouclage local

Le mode de bouclage local est défini globalement pour l’ensemble des services ; il est néanmoins possible de contrôler ce mode au moment de l’appel du service.

Utilisez pour cela la variable LoopMode définie sur les objets supportant les services distants :

var inst:ICinteropService;
begin
  inst := ICinteropService.Create;
  inst.LoopMode := mlmNone;
…
end ;

Les valeurs de LoopMode sont :

mlmDefault	Utilise le mode de bouclage défini par défaut.
mlmDirect	Appel l’implémentation locale.
mlmSOAP	Appel l’implémentation locale en utilisant la sérialisation SOAP
mlmNone	N’utilise pas l’implémentation locale.

Note : Le mode mlmSOAP n’est utile qu’a des fin de test de cohérence entre la sérialisation entrante et sortante.

Il est aussi possible d’agir sur le mode de bouclage par défaut ; ouvrez le concepteur de modèle puis l’option « Préférences » :

Note : Modifiez le mode par défaut n’est utile qu’à des fins de test ; cette modification n’est pas conservée lors de l’ouverture de l’application.

— Web Services (ws) — Développement DSM —