HCL Commerce en tant que consommateur de services
Invocation de service
Lorsque HCL Commerce agit comme consommateur de services, une API de client de composant doit être appelée depuis votre instruction de tâche. L'API de client utilise le service d'invocation, qui nécessite un fichier de configuration déployé pour déterminer comment communiquer avec le composant distant. A chaque composant est associé un fichier de configuration distinct, qui sert à configurer l'API de client correspondante. Chaque magasin peut aussi avoir sa propre version du fichier de configuration, qui est prioritaire sur la configuration par défaut. Cela permet au magasin de remplacer tout ou partie de la configuration sans pour autant changer la configuration par défaut.
Pour plus d'informations, voir Personnalisation du fichier XML d'invocation du client de service Web
Système de messagerie
HCL Commerce utilise son sous-système de messagerie pour invoquer des services Web sur des systèmes externes. L'API de client utilise un type de messages HCL Commerce qui véhicule la requête de service jusqu'à sa destination en empruntant le transport spécifié. Des mappages entre types de messages et requêtes de service sont fournis par défaut ; pour plus de détails, voir Points d'intégration sortants orientés services.
Connecteur Service Web sur HTTP
Ce connecteur permet l'envoi des demandes de service Web sur HTTP. Reposant sur l'architecture de connecteurs JCA (J2EE Connector Architecture), il encapsule le message de demande de service Web dans une enveloppe SOAP et permet de joindre à ce message les justificatifs de sécurité nécessaires. D'autres informations sont ajoutées à l'en-tête SOAP ; il s'agit des propriétés de spécification d'interaction associées à la configuration JCA du service Web. Le connecteur JCA définit ces propriétés au moment de la construction du message SOAP. Ce connecteur peut aussi émettre des exceptions si des défauts (faults) SOAP sont renvoyés dans le cadre de la demande de service.
Ce connecteur possède une caractéristique qui lui est propre : lorsqu'une exception se produit pendant l'exécution de la demande en fonction des propriétés de la connexion, le connecteur attend un certain temps avant d'autoriser l'exécution de la même demande. Cela évite de submerger le système d'arrière-plan de demandes s'il n'est pas disponible ou ne répond pas. Certaines exceptions de communication sont interceptées et mises en cache ; parallèlement, un délai d'attente leur est attribué. Si une nouvelle demande basée sur les mêmes informations de connexion est émise, l'exception mise en cache est lancée et la demande n'est pas exécutée. Une fois le délai d'attente expiré, la demande est émise normalement. Le but de ce mécanisme est de fournir une exception à l'appelant tout en évitant l'envoi répété de demandes à un système d'arrière-plan temporairement indisponible.
Connecteur Service Web sur JMS
Reposant sur l'architecture de connecteurs JCA (J2EE Connector Architecture), le connecteur Service Web sur JMS est une extension de l'actuel connecteur JCA sur messagerie JMS ; il encapsule le message de demande de service Web dans une enveloppe SOAP et permet de joindre à ce message les justificatifs de sécurité nécessaires. Il émet des exceptions si des défauts (faults) SOAP sont renvoyés dans le cadre de la demande de service.
Autres recommandations
Pour des définitions de services complexes, telles que les documents BOD OAGIS exploitant les caractéristiques XSD de la spécification XML, l'approche recommandée pour le développement d'un client de services Web est de tirer parti de l'infrastructure de modélisation EMF (Eclipse Modeling Framework) et des capacités offertes par l'outil Rational Application Developer. Une démonstration de l'utilisation de cette alternative pour le développement de clients de services Web est décrite dans cet article, .