Le protocole métier de votre message détermine le format du document. Le protocole métier influe sur les décisions à prendre lors de la planification de l'application dorsale. Le choix du protocole métier détermine la méthode de regroupement à utiliser, qui, à son tour, affecte le type de protocole de transfert des messages pouvant être utilisé.
Pour plus d'informations sur les protocoles métiers, voir le Guide de configuration du concentrateur. Cette section fournit des informations nécessaires à l'intégration spécifiques aux protocoles métiers suivants:
WebSphere Partner Gateway peut mettre les services Web suivants à la disposition des membres de la communauté du concentrateur :
Vous devrez fournir à votre participant de communauté le module WSDL public généré par WebSphere Partner Gateway. Il est important de noter que l'URL utilisée par le participant de communauté pour appeler le service Webcorrespond à l'URL publique du service Web spécifiée lors du téléchargement de ce dernier. WebSphere Partner Gateway agit en tant que proxy. Il reçoit un message SOAP en provenance du participant et détermine le service Web privé correspondant. Il appelle ensuite le service Web privé (fourni par le Gestionnaire de communauté) au moyen du même message SOAP. La réponse renvoyée par le Gestionnaire de communauté est ensuite transmise au participant.
Il est important de noter que la même interface de service Web peut être fournie par plusieurs partenaires. WebSphere Partner Gateway met le service Web à la disposition du Gestionnaire de communauté au niveau de l'URL du service Web spécifié dans la console lors du chargement du service Web. De plus, le Gestionnaire de communauté devra fournir le paramètre d'URL pour identifier la zone "Vers le partenaire". Pour plus d'informations, voir le Guide de configuration du concentrateur. WebSphere Partner Gateway agit en tant que proxy. Il reçoit un message SOAP en provenance du Gestionnaire de communauté et détermine le service Web correspondant et la spécification "Vers le partenaire". Il appelle ensuite le service Web fourni par le partenaire au moyen du même message SOAP. Le message de réponse renvoyé par le partenaire est ensuite transmis au Gestionnaire de communauté.
Pour plus d'informations, notamment sur la configuration des définitions de flot de documents pour les services Web, voir le Guide de configuration du concentrateur.
Vous pouvez envoyer ou recevoir des documents cXML en provenance ou à destination des participants de communauté. Lorsque WebSphere Partner Gateway reçoit un document cXML provenant d'un participant de communauté, il le valide et le convertit (le cas échéant) avant de l'envoyer à l'application dorsale du Gestionnaire de communauté. Notez que la conversion ne doit pas être utilisée pour les messages cXML synchrones. Dans le cadre d'un échange synchrone, l'application dorsale génère une réponse qui est renvoyée par la suite par WebSphere Partner Gateway au participant de communauté (si approprié au message).
Une application dorsale du Gestionnaire de communauté qui doit envoyer un document cXML peut procéder de deux manières:
Pour plus d'informations, notamment sur la configuration des définitions de flot de documents pour cXML, voir le Guide de configuration du concentrateur.
WebSphere Partner Gateway accepte les documents EDI émanant des participants de réseaux à valeur ajoutée et d'Internet.Les documents EDI envoyés à un réseau à valeur ajoutée ou reçus par celui-ci utilisent le transfert de script FTP. Ce transfert peut également être utilisé pour envoyer des documents à Internet ou en recevoir de ce dernier. Pour plus d'informations sur le transfert de scripts FTP, voir le Guide de configuration du concentrateur.
Un document EDI entre dans le concentrateur et quitte le concentrateur dans une enveloppe EDI, appelée Interchange. L'interchange contient des transactions ou des groupes de transactions EDI.
Dans le cas où l'interchange EDI sera transmis via le concentrateur(sans être désenveloppé), vous créez une connexion entre celui-ci et le Gestionnaire de communauté.
Cependant, dans le cas où l'interchange EDI sera désenveloppé, le processus de création d'interactions et de connexions est différent de celui d'autres protocoles de gestion. L'Interchange doit être désenveloppé et les transactions individuelles doivent être traitées. Les transactions sont généralement converties en un autre format, selon une mappe de transformation importée à partir du client Data Interchange Services. Si les transactions EDI sont converties en documents XML ou ROD (données orientées enregistrement), ces documents sont envoyés au Gestionnaire de communauté ou au participant. Si les transactions sont converties vers d'autres formats EDI, les transactions sont enveloppées avant d'être envoyées au Gestionnaire de communauté ou au participant.
Une application dorsale peut envoyer les types de document suivants :
WebSphere Partner Gateway désenveloppe les transactions EDI individuelles et les convertit. Si les transactions sont converties en EDI, elles sont enveloppées puis acheminées vers le participant. L'application dorsale peut n'utiliser aucun regroupement ou un regroupement dorsal et envoyer l'interchange sur divers protocole de transfert, comme cela est défini dans le tableau 13.
La figure 6 présente un interchange X12 consistant en le désenveloppement de trois transactions. Les transactions sont converties au format EDIFACT puis sont enveloppées et envoyées au participant.
Chacune des transactions est associée à une mappe de transformation qui spécifie comment la transaction est convertie. La transaction peut être convertie en une seule transaction ou, si le chaînage de mappes a été utilisé pour créer la mappe, en plusieurs transactions.
Si la transaction est convertie en un document XML ou ROD, elle est acheminée telle qu'elle est configurée dans la connexion du participant.
La figure 7 montre un interchange EDI X12 désenveloppé et converti en documents XML, qui sont envoyés au participant.
La transaction peut être convertie en un seul document ou, si le chaînage de mappes a été utilisé pour créer la mappe, en plusieurs documents.
WebSphere Partner Gateway convertit le document en une transaction EDI, l'enveloppe et l'envoie au participant. L'application dorsale peut n'utiliser aucun regroupement ou un regroupement d'intégration dorsale et peut envoyer le document sur divers protocoles de transfert, comme cela est défini dans le tableau 13.
La figure 8 montre un document XML converti en transactions X12, puis enveloppé.
Un document peut être converti en plusieurs transactions (si le chaînage de mappes a été utilisé pour créer la mappe) et les transactions peuvent être enveloppées dans différents interchanges.
La figure 9 montre un document XML converti en trois transactions X12. Deux d'entre elles sont enveloppées ensemble. Celle restante est placée dans une enveloppe distincte.
Si le document est converti en un autre document XML ou ROD, il est acheminé tel qu'il est configuré dans la connexion du participant.
WebSphere Partner Gateway divise les documents et les convertit. Si les documents sont convertis en transactions EDI, WebSphere Partner Gateway les enveloppe et envoie l'enveloppe au participant. Si des ID de lots ont été affectés aux documents XML ou ROD, WebSphere Partner Gateway tente d'envoyer les transactions EDI dans une enveloppe (comme un lot). L'application dorsale peut n'utiliser aucun regroupement ou un regroupement d'intégration dorsale et peut envoyer le document sur divers protocoles de transfert, comme cela est défini dans le tableau 13.
La figure 10 montre un ensemble de documents XML en cours de séparation. Des documents XML distincts sont donc obtenus. Les documents XML sont convertis en transactions X12 qui sont enveloppées.
La figure 10 montre comment les documents sont séparés et les transactions converties enveloppées. Afin que les documents puissent être divisés, vous devez configurer un gestionnaire de séparation (dans ce cas celui de XML) pour la cible utilisée afin d'envoyer les documents. Pour que ce scénario ait lieu, l'option BCG_BATCHDOCS du gestionnaire de séparation XML doit être activé (valeur par défaut). BCG_BATCHDOCS affecte un ID de lot aux documents XML de sorte que les transactions résultantes seront placées dans la même enveloppe. Pour plus d'informations sur le gestionnaire de séparation XML et l'attribut BCG_BATCHDOCS, voir leguide de configuration du concentrateur .
Si les documents sont convertis en autres documents XML ou ROD, ils sont acheminés tels que configurés dans la connexion du participant.
WebSphere Partner Gateway divise le fichier en interchanges individuels. Il désenveloppe alors les interchanges en transactions individuelles et les convertit. Si les documents sont convertis en transactions EDI, WebSphere Partner Gateway les enveloppe et envoie l'enveloppe au participant. L'application dorsale peut n'utiliser aucun regroupement ou un regroupement d'intégration dorsale et peut envoyer le document sur divers protocoles de transfert, comme cela est défini dans le tableau 13.
Si les documents sont convertis en documents XML ou ROD, ils sont acheminés tels que configurés dans la connexion du participant.
Un participant peut envoyer les types de document suivants :
WebSphere Partner Gateway désenveloppe les transactions EDI individuelles et les convertit. Si les transactions sont converties en EDI, elles sont enveloppées puis acheminées à l'application dorsale. L'application dorsale peut n'utiliser aucun regroupement ou un regroupement d'intégration dorsale et les transactions peuvent être envoyées via divers protocoles de transfert, comme cela est défini dans le tableau 14.
Si les transactions sont converties en documents XML ou ROD, elles sont acheminées telles que configurées dans la connexion du participant.
WebSphere Partner Gateway convertit le document en une transaction EDI, l'enveloppe et envoie l'enveloppe à l'application dorsale. Aucun regroupement ou un regroupement d'intégration dorsale peut être utilisé.
Si le document est converti en un autre document XML ou ROD, il est acheminé tel qu'il est configuré dans la connexion du participant.
WebSphere Partner Gateway divise les documents et les convertit. Si les documents sont convertis en transactions EDI, WebSphere Partner Gateway les enveloppe et envoie l'enveloppe à l'application dorsale. Si des ID de lots ont été affectés aux documents XML ou ROD, WebSphere Partner Gateway tente d'envoyer les transactions EDI dans une enveloppe (comme un lot). Aucun regroupement ou un regroupement d'intégration dorsale peut être utilisé.
Si les documents sont convertis en autres documents XML ou ROD, ils sont acheminés tels que configurés dans la connexion du participant.
WebSphere Partner Gateway divise le fichier en interchanges individuels. Il désenveloppe alors les interchanges en transactions individuelles et les convertit. Si les documents sont convertis en transactions EDI, WebSphere Partner Gateway les enveloppe et envoie l'enveloppe à l'application dorsale. Aucun regroupement ou un regroupement d'intégration dorsale peut être utilisé.
Si les documents sont convertis en documents XML ou ROD, ils sont acheminés tels que configurés dans la connexion du participant.
Un accusé de réception fonctionnel spécifie qu'un interchange EDI a été reçu. Il est toujours enveloppé avant d'être envoyé.
Pour les interchanges reçus par WebSphere Partner Gateway
Pour les interchanges générés par WebSphere Partner Gateway :
WebSphere Partner Gateway permet d'envoyer et de recevoir des documents conformes aux normes RosettaNet 1.1 et 2.0. Lorsqu'un participant envoie un message RosettaNet au concentrateur, l'intégration dorsale doit être spécifié à l'extrémité cible de la connexion du participant. Le concentrateur convertit les données utiles du message au format RNSC et envoie le message au système dorsal. En raison de l'utilisation du regroupement d'intégration dorsale, le concentrateur ajoute des en-têtes du niveau de transfert au message. Ce message est envoyé via le protocole de transfert HTTP ou JMS. L'en-tête du niveau de transfert conserve les méta-informations qui ne font pas partie du PIP et active WebSphere Partner Gateway afin qu'il achemine correctement le message.
De façon similaire, lorsque le système dorsal du Gestionnaire de communauté envoie un message RNSC au concentrateur, le regroupement d'intégration dorsale doit être spécifié à l'extrémité source de la connexion du participant et le système dorsal doit fournir les en-têtes du niveau de transfert.
Par exemple, imaginons qu'une application souhaite envoyer un message à un participant de communauté au moyen de RosettaNet sur HTTP. L'application fournit le contenu du service RosettaNet et ajoute l'en-tête du niveau de transfert. L'en-tête identifie le participant de communauté en charge de la requête, le PIP à envoyer et la version du PIP ainsi que d'autres informations. Ces informations permettent alors à WebSphere Partner Gateway d'envoyer le PIP approprié au participant de communauté.
Les informations relatives à la définition de la prise en charge de RosettaNet et à la configuration des PIP se trouvent dans le Guide de configuration du Concentrateur.
WebSphere Partner Gateway exécute des processus RNIF PIP avec les participants de communauté pour le compte des applications dorsales du Gestionnaire de communauté.Par conséquent, WebSphere Partner Gateway fournit une notification d'événement afin d'informer l'application dorsale des divers aspects de l'exécution du processus RNIF PIP. La notification d'événement permet à WebSphere Partner Gateway, par exemple, de notifier l'application si WebSphere Partner Gateway n'est pas en mesure d'envoyer un PIP au participant. L'application peut ainsi prendre en charge cet échec.
Un message de notification d'événement est un document XML qui comporte des informations sur les événements qui sont intervenus dans WebSphere Partner Gateway ou dans une application. Ces messages ont la même structure que tout autre message entrant ou sortant de WebSphere Partner Gateway : en d'autres termes, ils comportent un en-tête de niveau de transfert et des données utiles. WebSphere Partner Gateway peut être configuré pour envoyer ou non des messages de notification d'événement car ces messages sont facultatifs.
Le tableau 2 résume les messages de notification d'événements que WebSphere Partner Gateway est susceptible d'envoyer à une application dorsale.
Condition d'événement | Message de notification d'événement |
---|---|
WebSphere Partner Gateway fournit un document RosettaNet à un participant de communauté et reçoit un accusé de réception. |
Evénement 100 |
WebSphere Partner Gateway annule un PIP en générant un message 0A1 et en le transmettant au participant de communauté. |
Evénement 800 |
WebSphere Partner Gateway reçoit une exception d'accusé de réception ou une exception générale d'un participant de communauté. |
Evénement 900 |
WebSphere Partner Gateway peut envoyer des messages 0A1 à l'application cible comme il le ferait avec n'importe quel autre PIP, s'il a été configuré pour envoyer ces messages à l'aide de la Procédure de gestion des listes d'exclusion. Voir "Gestion des listes d'exclusion" dans le Guide de l'administrateur.
Une application peut envoyer un message de notification d'événement à WebSphere Partner Gateway pour annuler un PIP RosettaNet.
Tout message de notification d'événement dispose d'un en-tête de niveau de transfert standard et d'une zone x-aux-process-type définie par la valeur XMLEvent. Cependant, les données utiles du message ont une structure spécifique, comme le montre schéma XML dans la figure 11.
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification" xmlns:evntf= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification" elementFormDefault="qualified">
<!-- EventNotification version 1.0 document element --> <xsd:element name="EventNotification"> <xsd:complexType> <xsd:all> <xsd:element ref="evntf:StatusCode"/> <xsd:element ref="evntf:StatusMessage"/> <xsd:element ref="evntf:EventMessageID"/> <xsd:element ref="evntf:BusinessObjectID"/> <xsd:element ref="evntf:GlobalMessageID"/> <xsd:element ref="evntf:Timestamp"/> </xsd:all> </xsd:complexType> </xsd:element>
<!-- StatusCode element --> <xsd:element name="StatusCode"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="100"/> <xsd:enumeration value="800"/> <xsd:enumeration value="900"/> <xsd:enumeration value="901"/> <xsd:enumeration value="902"/> <xsd:enumeration value="903"/> <xsd:enumeration value="904"/> </xsd:restriction> </xsd:simpleType> </xsd:element>
<!-- StatusMessage element --> <xsd:element name="StatusMessage"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- EventMessageID element --> <xsd:element name="EventMessageID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- BusinessObjectID element --> <xsd:element name="BusinessObjectID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- GlobalMessageID element --> <xsd:element name="GlobalMessageID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- Timestamp element --> <xsd:element name="Timestamp"> <xsd:simpleType> <xsd:restriction base="xsd:dateTime"/> </xsd:simpleType> </xsd:element> </xsd:schema>
Le tableau 3 décrit chaque zone contenue dans les données utiles de l'événement.
La figure 12 présente un exemple de message de notification d'événement envoyé via le protocole HTTP.
POST /builderURL HTTP/1.1 Content-Type: application/xml Content-length: 250 x-aux-sender-id: 000000001 x-aux-receiver-id: 000000002 x-aux-third-party-bus-id: 000000003 x-aux-create-datetime: 2002-10-28T23:05:02Z x-aux-protocol: XMLEvent x-aux-protocol-version: 1.0 x-aux-process-type: XMLEvent x-aux-process-version: 1.0 x-aux-payload-root-tag: evntf:EventNotification x-aux-msg-id: 98732 x-aux-system-msg-id: 12345 x-aux-production: Production x-aux-process-instance-id: 3456 x-aux-event-status-code: 100 x-aux-transport-retry-count: 0
<?xml version="1.0" encoding="UTF-8"?> <evntf:EventNotification xmlns:evntf= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification"> <evntf:StatusCode>100</evntf:StatusCode> <evntf:StatusMessage>The message was delivered</evntf:StatusMessage> <evntf:EventMessageID>12345</evntf:EventMessageID> <evntf:BusinessObjectID>34234</evntf:BusinessObjectID> <evntf:GlobalMessageID>98732</evntf:GlobalMessageID> <evntf:Timestamp>2001-01-31T13:20:00Z</evntf:Timestamp> </evntf:EventNotification>