Cette section fournit les informations nécessaires à la planification de votre intégration dorsale avec WebSphere Business Integration Connect:
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 Administrateur. Cette section fournit des informations nécessaires à l'intégration spécifiques aux protocoles métiers suivants:
Business Integration Connect peut mettre les services Web suivants à la disposition des membres du concentrateur :
Vous devrez fournir à votre participant de communauté le module WSDL public généré par Business Integration Connect. Il est important de noter que l'URL utili sé par le participant de communauté pour appeler le service Web correspond à l'URL du service Web spécifié lors du chargement du service Web. Business Integration Connect 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. Business Integration Connect 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. Business Integration Connect agit en tant que proxy. Il reçoit un message SOAP en provenance du Gestionnaire de communauté et détermine le service Web privé correspondant ainsi que la zone "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 Business Integration Connect 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 Business Integration Connect 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 du flot de documents cXML, voir le Guide Administrateur.
Business Integration Connect prend en charge RosettaNet versions 1.1 et 2.0, à condition que les messages RosettaNet disposent du regroupement d'intégration dorsale (en d'autres termes, ils doivent avoir des en-têtes de niveau de transfert.) Ces messages doivent utiliser 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 Business Integration Connect afin qu'il achemine correctement le message.
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 à Business Integration Connect 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.
Dans la mesure où Business Integration Connect sépare l'application du participant de communauté correspondant au fournisseur du service RosettaNet, Business Integration Connect fournit la notification d'événement. La Notification d'évènement permet à Business Integration Connect, par exemple, de notifier l'application si Business Integration Connect 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 Business Integration Connect ou dans une application. Ces messages ont la même structure que tout autre message entrant ou sortant de Business Integration Connect: en d'autres termes, ils comportent un en-tête de niveau de transfert et des données utiles. Business Integration Connect peut être configuré pour envoyer ou non des messages de notification d'événement car ces messages sont facultatifs.
Le Tableau 1 résume les messages de notification d'évènements que
Business Integration Connect est susceptible d'envoyer à une application
dorsale.
Tableau 1. Notification d'évènement envoyé à l'application dorsale
Condition d'évènement | Message de notification d'évènement |
---|---|
Business Integration Connect fournit un document RosettaNet à un
participant de communauté et reçoit un accusé de réception.
| Evènement 100 |
Business Integration Connect annule un PIP en générant un message 0A1 et en
le transmettant au participant de communauté.
| Evènement 800 |
Business Integration Connect reçoit une exception d'accusé de
réception ou une exception générale d'un participant de
communauté.
| Evènement 900 |
Business Integration Connect peut envoyer un message 0A1 à l'application cible comme il le ferait avec n'importe quel autre PIP, s'il a été configuré pour envoyer des 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 à Business Integration Connect 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. Toutefois, les données utiles du message ont une structure spécifique, comme le montre l'exemple de schéma XML dans la Figure 2.
Figure 2. Exemple de schéma XML pour un message d'événement
<?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 2 décrit chaque zone contenue dans les données utiles de
l'événement.
Tableau 2. Zones de la notification d'événement XML
Zone | Description |
---|---|
StatusCode | Type de message. Les valeurs correctes sont :
|
StatusMessage | Description alphanumérique de ce message de notification d'événement |
EventMessageID | ID alphanumérique de ce message de notification d'événement particulier |
BusinessObjectID | Identificateur x-aux-msg-id contenu dans l'en-tête de niveau de transfert du message affecté par ce message de notification d'événement. Cette zone relie les données utiles du message d'origine à cet événement. |
GlobalMessageID | Identificateur x-aux-system-msg-id contenu dans l'en-tête de niveau de transfert du message responsable de ce message de notification d'événement |
Timestamp |
Utilisé lorsqu'un événement se produit à l'aide du format d'horodatage UTC: CCYY-MM-DDThh:mm:ssZ comprenant la précision fractionné des secondes (...ss.ssssZ). L'horodatage doit être conforme au type de données du schéma XML pour la zone dateTime (w3.org/TR/2001/REC-xmlschema-2-20010502#dateTime) |
La Figure 3 montre un exemple de message de notification d'événement envoyé via le protocole HTTP.
Figure 3. 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>
Le type de regroupement détermine le format dans lequel Business Integration Connect envoie le message à l'application dorsale.
Vous pouvez utiliser la Console de communauté pour établir la connexion avec les participants de communauté et spécifier le regroupement utilisé entre Business Integration Connect et l'application dorsale. Pour déterminer le type de regroupement à utiliser, vous devez être en mesure de répondre aux questions suivantes :
Pour plus d'informations sur la configuration de connexions de partenaires, voir le Guide de configuration du concentrateur.
Tous les types de regroupement ne sont pas adaptés lors de
l'utilisation de Business Integration Connect pour
l'intégration. Le Tableau 3 répertorie les types de regroupement
appropriés lorsque Business Integration Connect agit en tant que Gestionnaire
de communauté.
Tableau 3. Types de regroupement appropriés pour l'intégration dorsale
Type de regroupement | Description |
---|---|
Aucun regroupement |
Conduit Business Integration Connect à envoyer le message à
l'application dorsale sans aucune donnée d'en-tête
|
Regroupement d'intégration dorsale |
Ajoute des attributs supplémentaires à l'en-tête du message et
regroupe le contenu du message dans une enveloppe XML
|
Lorsque le regroupement a la valeur Aucun, Business Integration Connect n'ajoute aucun en-tête de niveau de transfert lorsqu'il envoie un message à une application dorsale et ne s'attend pas non plus à en obtenir un lorsqu'il reçoit un message provenant d'une application dorsale. Au lieu de cela, Business Integration Connect envoie uniquement le message à l'application dorsale. Les informations contenues dans le document contrôlent le routage des données.
Lorsque le regroupement a la valeur Intégration dorsale, les messages envoyés à ou reçus par une application dorsale doivent contenir les éléments suivants:
L'en-tête et les données utiles sont obligatoires tandis que les pièces jointes sont facultatives. Les sections suivantes décrivent chaque élément constitutif d'un document utilisant le regroupement d'Intégration Dorsale.
L'en-tête du niveau de transfert contient les informations utilisées par Business Integration Connect pour traiter et acheminer le message vers la destination appropriée. L'en-tête du niveau de transfert est bidirectionnelle de sorte que tous les messages qui entrent et sortent de Business Integration Connect comportent les zones obligatoires et facultatives qui s'appliquent.
Le Tableau 4 répertorie les zones de l'en-tête du niveau de
transfert.
Tableau 4. Zones de l'en-tête du niveau de transfert
Zone d'en-tête | Description | Obligatoire ? |
---|---|---|
x-aux-sender-id | ID de l'expéditeur du message, tel qu'un numéro DUNS | Oui |
x-aux-receiver-id | ID du réceptionnaire du message, tel qu'un numéro DUNS | Oui |
x-aux-protocol | Protocole du contenu du message. Les valeurs valides sont RNSC pour le contenu du service RosettaNet, XMLEvent et Binary. Pour Business Integration Connect, la valeur contenue dans cette zone a priorité sur n'importe quelle autre zone du protocole dans les données utiles. | Oui |
x-aux-protocol-version | Version du protocole du contenu du message | Oui |
x-aux-process-type | Processus à réaliser ou type de message à envoyer. Pour les messages RosettaNet, il s'agit du code PIP tel que 3A4. Pour les messages d'événement, il s'agit de la valeur XMLEvent et pour les messages binaires, il s'agit de la valeur Binary. Pour Business Integration Connect, la valeur contenue dans cette zone a priorité sur n'importe quelle autre zone du processus dans les données utiles. | Oui |
x-aux-process-version | Version du processus. Pour les messages RosettaNet, il s'agit du numéro de version du PIP. | Oui |
x-aux-create-datetime | Utilisée lorsqu'un message a été correctement transmis à l'aide du format d'horodatage UTC (CCYY-MM-DDThh:mm:ssZ) |
|
x-aux-msg-id | ID du contenu des données utiles. Il peut, par exemple, s'agir de l'ID d'instance RNPIPServiceContent d'un message RosettaNet ou de l'ID document du propriétaire. Il relie les données utiles du message à un élément contenu dans le système de l'expéditeur du message pour des besoins de traçage. |
|
x-aux-production | Acheminement du message. La valeur valide est la suivante : Production Test. Cette valeur est renseignée pour les requêtes effectuées dans les deux sens. Notez que lorsque le message est une réponse à un PIP bidirectionnel initialisé par un participant de communauté, Business Integration Connect utilise la valeur du paramètre GlobalUsageCode dans la requête et ignore la valeur contenue dans l'en-tête du niveau de transfert. |
|
x-aux-system-msg-id | Identificateur global unique (GUID) du message, utilisé pour la vérification de la duplication | Oui |
x-aux-payload-root-tag | Elément de code racine des données utiles. Par exemple, pour le contenu du service RosettaNet 3A4, la valeur de cette zone doit être Pip3A4PurchaseOrderRequest. Pour les messages de notification d'événement, la valeur de cette zone doit être EventNotification. |
|
x-aux-process-instance-id | ID qui relie les documents contenus dans un processus métier multiple de messages à une instance de processus unique. Pour RosettaNet, cette valeur doit être unique pour les processus RosettaNet pendant les 30 derniers jours. Tous les messages échangés en tant que partie intégrante de l'instance d'un processus RosettaNet, notamment les tentatives de relance, utilisent le même ID d'instance de processus. |
|
x-aux-event-status-code | Code d'état de la notification d'événement. Voir la zone StatusCode à la section Structure des messages d'événement. |
|
x-aux-third-party-bus-id | ID tel que le numéro DUNS de la partie à l'origine de l'envoi du message. Il peut être différent des identificateurs x-aux-sender-id et x-aux-receiver-id si un tiers héberge Business Integration Connect pour le compte du propriétaire de communauté. |
|
x-aux-transport-retry-count | Nombre de tentatives infructueuses pour transmettre ce message avant cette tentative. Si un message est transmis à la première tentative, la valeur de cette zone sera 0. |
|
content-type | Type de contenu du message |
|
content-length | Longueur du message (en octets) |
|
Le Tableau 4 présente les informations de l'en-tête du niveau de transfert. Les sections suivantes fournissent les informations de l'en-tête du niveau de transfert spécifiques à certains protocoles métier :
En-tête du niveau de transfert et message RosettaNet:
Le Tableau 5 décrit l'emplacement où Business Integration Connect
extrait les valeurs pour les zones de l'en-tête du niveau de transfert à
partir d'un message RosettaNet.
Tableau 5. Zones de l'en-tête du niveau de transfert et contenu RosettaNet
Zone d'en-tête | Source de la valeur : RosettaNet 2.0 | Source de la valeur : RosettaNet 1.1 |
---|---|---|
x-aux-sender-id |
<(DeliveryHeader)> <messageSenderIdentification> <PartnerIdentification> <GlobalBusinessIdentifier> |
<ServiceHeader> <ProcessControl> <TransactionControl> <ActionControl> or <SignalControl> <PartnerRouter> <fromPartner> <PartnerDescription> <BusinessDescription> <GlobalBusinessIdentifier> |
x-aux-receiver-id |
<(DeliveryHeader)> <messageReceiverIdentification> <PartnerIdentification> <GlobalBusinessIdentifier> |
<ServiceHeader> <ProcessControl> <TransactionControl> <ActionControl> or <SignalControl> <PartnerRouter> <toPartner> <PartnerDescription> <BusinessDescription> <GlobalBusinessIdentifier> |
x-aux-protocol | Définir une valeur pour RosettaNet : RNSC | Identique pour RosettaNet 2.0 |
x-aux-protocol-version | Définir une valeur : 1.0 | Identique pour RosettaNet 2.0 |
x-aux-process-type |
La variable XPath source est : /ServiceHeader/ProcessControl/ pipCode/GlobalProcessIndicatorCode |
La variable XPath source est : /ServiceHeader/ProcessControl/ ProcessIdentity/GlobalProcessIndicatorCode |
x-aux-process-version |
La variable XPath source est : /ServiceHeader/ProcessControl/ pipVersion/VersionIdentifier La valeur de l'ID de version de chaque PIP se trouve dans la spécification PIP qui lui est associée. |
La variable XPath source est : /ServiceHeader/ProcessControl/ ProcessIdentity/VersionIdentifier La valeur de l'ID de version de chaque PIP se trouve dans la spécification PIP qui lui est associée. |
x-aux-payload- root-tag | Nom du PIP, par exemple Pip3A4PurchaseOrderRequest | Identique pour RosettaNet 2.0 |
x-aux-process-instance-id |
Pour les processus lancés par l'application, cette valeur correspond à l'ID d'instance du processus. Pour les processus lancés par un participant de communauté qui ne correspondent pas à des flux de travaux du passe-système, cette valeur correspond à l'ID processus dans la requête RosettaNet initiale : <ServiceHeader> <ProcessControl> <pipInstanceId> <InstanceIdentifier> |
<ServiceHeader> <ProcessControl> <ProcessIdentity> <InstanceIdentifier> |
x-aux-msg-id |
<(RNPipServiceContent)> <thisDocumentIdentifier> <ProprietaryDocumentIdentifier> | Identique pour RosettaNet 2.0 |
x-aux-production |
<ServiceHeader> <ProcessIndicator> <GlobalUsageCode> |
<Preamble> <GlobalUsageCode> |
En-tête du niveau de transfert et message AS2:
Le Tableau 6 décrit l'emplacement où Business Integration Connect extrait les valeurs pour les zones de l'en-tête du niveau de transfert à partir d'un message AS2.
Tableau 6. Zones de l'en-tête du niveau de transfert à partir d'un contenu AS2
Zone d'en-tête | Source de la valeur |
---|---|
x-aux-sender-id | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect, Edition Enterprise ou Advanced, la zone d'en-tête AS2-From du message AS2 est définie dans la zone x-aux-sender-id du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-sender-id du message d'intégration dorsale entrant est utilisée en tant que valeur d'en-tête AS2-From du message AS2. |
x-aux-receiver-id | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, la zone d'en-tête AS2-To du message AS2 est définie dans la zone x-aux-receiver-id du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-receiver-id du message d'intégration dorsale entrant est utilisée en tant que valeur d'en-tête AS2-To du message AS2. |
x-aux-protocol | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProtocol de la connexion du participant est définie dans la zone x-aux-protocol du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-protocol du message d'intégration dorsale entrant est utilisée pour déterminer la zone FromProtocol de la connexion du participant. |
x-aux-protocol-version | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProtocolVersion de la connexion du participant est définie dans la zone x-aux-protocol-version du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-protocol-version du message d'intégration dorsale entrant est utilisée en tant que zone FromProtocolVersion de la connexion du participant. |
x-aux-process-type | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProcessCode de la connexion du participant est utilisée pour définir la zone x-aux-process-type du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-process-type du message d'intégration dorsale entrant est utilisée en tant que zone FromProcessCode de la connexion du participant. |
x-aux-process-version | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProcessVersion de la connexion du participant est définie dans la zone x-aux-process-version du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS2 est acheminé vers un participant de communauté, la zone x-aux-process-version du message d'intégration dorsale entrant est utilisée en tant que zone FromProcessVersion de la connexion du participant. |
x-aux-payload- root-tag | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, pour un protocole XML personnalisé uniquement, le code racine indiqué dans la variable XPATH du message est analysé et utilisé dans la zone x-aux-payload-root-tag. Lorsqu'un message AS2 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-process-instance-id | Cette zone n'est pas utilisée pour AS2. |
x-aux-msg-id | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, pour un protocole XML personnalisé uniquement, l'ID document indiqué dans la variable XPATH du message est analysé et utilisé dans la zone x-aux-payload-root-tag. Lorsqu'un message AS2 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-system-msg-id | Lorsqu'un participant de communauté envoie un message AS2 à Business Integration Connect Edition Enterprise ou Advanced, cette zone est définie par l'ID unique généré en interne pour ce message. Lorsqu'un message AS2 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-production | Cette zone n'est pas utilisée pour AS2. |
En-tête du niveau de transfert et message AS1:
Le Tableau 7 décrit l'emplacement où Business Integration Connect extrait les valeurs pour les zones de l'en-tête du niveau de transfert à partir d'un message AS1.
Tableau 7. Zones de l'en-tête du niveau de transfert à partir d'un contenu AS1
Zone d'en-tête | Source de la valeur |
---|---|
x-aux-sender-id | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, l'élément FromID contenu dans la zone d'en-tête "Objet :ToID;FromID" du message AS1 est défini dans la zone x-aux-sender-id du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-sender-id du message d'intégration dorsale entrant est utilisée en tant qu'élément FromID dans la valeur d'en-tête "Objet : ToID;FromID" du message AS1. |
x-aux-receiver-id | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, l'élément ToID contenu dans la zone d'en-tête "Objet : ToID;FromID" du message AS1 est défini dans la zone x-aux-receiver-id du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-receiver-id du message d'intégration dorsale entrant est utilisée en tant qu'élément ToID dans la valeur d'en-tête "Objet : ToID;FromID" du message AS1. |
x-aux-protocol | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect, Edition Enterprise ou Advanced, la zone ToProtocol de la connexion du participant est définie dans la zone x-aux-protocol du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-protocol du message d'intégration dorsale entrant est utilisée en tant que zone FromProtocol de la connexion du participant. |
x-aux-protocol-version | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProtocolVersion de la connexion du participant est définie dans la zone x-aux-protocol-version du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-protocol-version du message d'intégration dorsale entrant est utilisée en tant que zone FromProtocolVersion de la connexion du participant. |
x-aux-process-type | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProcessCode de la connexion du participant est définie dans la zone x-aux-process-type du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-process-type du message d'intégration dorsale entrant est utilisée en tant que zone FromProcessCode de la connexion du participant. |
x-aux-process-version | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, la zone ToProcessVersion de la connexion du participant est définie dans la zone x-aux-process-version du message d'intégration dorsale envoyé au Gestionnaire de communauté. Lorsqu'un message AS1 est acheminé vers un participant de communauté, la zone x-aux-process-version du message d'intégration dorsale entrant est utilisée en tant que zone FromProcessVersion de la connexion du participant. |
x-aux-payload- root-tag | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, pour un protocole XML personnalisé uniquement, le code racine indiqué dans la variable XPATH du message est analysé et défini dans la zone x-aux-payload-root-tag. Lorsqu'un message AS1 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-process-instance-id | Cette zone n'est pas utilisée pour AS1. |
x-aux-msg-id | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, pour un protocole XML personnalisé uniquement, l'ID document indiqué dans la variable XPATH du message est analysé et utilisé dans la zone x-aux-payload-root-tag. Lorsqu'un message AS1 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-system-msg-id | Lorsqu'un participant de communauté envoie un message AS1 à Business Integration Connect Edition Enterprise ou Advanced, cette zone est définie par l'ID unique généré en interne pour ce message. Lorsqu'un message AS1 est acheminé vers un participant de communauté, cette zone n'a pas besoin d'être définie dans le message d'intégration dorsale entrant. |
x-aux-production | Cette zone n'est pas utilisée pour AS1. |
Les données utiles du message correspondent au contenu réel du
message. L'emplacement des données utiles dépend du
protocole de transfert qui envoie le message, comme le montre le Tableau 8.
Tableau 8. Emplacement des données utiles
Protocole de transfert | Emplacement des données utiles |
---|---|
Messages du protocole HTTP | Dans le corps de la requête HTTP Post |
Messages du protocole JMS | Dans le corps du message JMS |
Messages RosettaNet | Dans le contenu du service à partir du PIP |
Envoi des informations EDI sur AS2 |
Dans le message EDI Les données utiles ne sont pas regroupées dans une enveloppe XML
à moins que le message comporte également une ou plusieurs pièces
jointes. Pour plus d'informations sur l'enveloppe XML et les
codes utilisés pour regrouper les pièce jointes, voir Pièces jointes.
|
Les données utiles peuvent être encodées en Base64 et regroupées dans une enveloppe XML dans les cas suivants:
Un document équippé de pièces jointes doit être inséré dans une enveloppe XML. Pour plus d'informations sur les pièces jointes, voir Pièces jointes.
Pour inclure un document dans une enveloppe XML sans savoir s'il contient des pièces jointes, positionner l'indicateur de l'enveloppe d'Intégration Dorsale sur Oui dans l'écran profil des prestataires B2B. Par exemple, pour positionner l'indicateur sur le profil Opérateur concentré, choisir:
Profil > Opérateur concentré > Prestataires B2B
Cliquez sur Edition avant Intégration Dorsale pour afficher l'étiquette de l'enveloppe.
Cette enveloppe XML insère le document concerné dans le code racine <transport-envelope>. A l'intérieur de ce code racine se trouve un code étiquette <payload> qui contient les données utiles du document. Si ce document contient des pièces jointes, celles-ci se trouvent dans une étiquette <attachment>. Pour plus d'informations sur la structure de ces étiquettes, voir Pièces jointes.
Business Integration Connect inclut le fichier schéma XML W3C suivant qui décrit la structure d'enveloppe XML de l'intégration dorsale :
wbipackaging_v1.0_ns.xsd
Ce fichier schéma se trouve dans le répertoire suivant sur le support d'installation :
B2BIntegrate\packagingSchemas
Vous pouvez utiliser n'importe quel outil d'édition XML pour valider l'intégration dorsale XML à la place de ce fichier schéma afin de garantir la validité du document avant de l'envoyer au Gestionnaire de documents.
Si le protocole de messagerie le permet, chaque document peut avoir une ou
plusieurs pièces jointes. Si le document contient des pièces jointes,
celui-ci doit être inséré dans une
enveloppe XML, comme stipulé dans la section Données utiles. Le Tableau 9 décrit les attributs contenus dans les
codes des données utiles et des pièces jointes.
Tableau 9. Attributs XML des codes des données utiles et des pièces jointes
La Figure 4 présente un exemple de document inséré dans une enveloppe XML comprenant des données utiles et une pièce jointe.
xmlns="http://www.ibm.com/websphere/bcg/2003/v1.0/wbipackaging"
Figure 4. Exemple d'enveloppe XML comprenant des données utiles et une pièce jointe
<?xml version="1.0" encoding="utf-8"?> <transport-envelope xmlns="http://www.ibm.com/websphere/bcg/2003/v1.0/wbipackaging">
<payload encoding="base64" contentType="application/xml"> ...base64 encoded XML message... </payload>
<attachment encoding="base64" Content-Type="text/xml"> ...base64 encoded XML attachment... </attachment>
</transport-envelope>
Les documents de certains protocoles métier peuvent uniquement utiliser certains types de regroupement. Par exemple, un document RosettaNet peut uniquement être traité lorsqu'un regroupement d'intégration dorsale a été spécifié. Voir le Tableau 15 et le Tableau 20 pour obtenir la liste complète des types de document et des types de regroupement auxquels ils peuvent être associés.
La Figure 5 présente un exemple de message provenant de Business Integration Connect à destination d'une application utilisant le protocole de transfert HTTP. Notez que le message ne contient aucune pièce jointe.
Figure 5. Exemple de message utilisant le protocole de transfert HTTP
POST /sample/receive HTTP/1.1 Host: sample. COM Content-Type: application/xml Content-Length: nnn 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: RNSC x-aux-protocol-version: 1.0 x-aux-process-type: 3A4 x-aux-process-version: V02.00 x-aux-payload-root-tag: Pip3A4PurchaseOrderRequest x-aux-msg-id: 1021358129419 x-aux-system-msg-id: 2 x-aux-production: Production x-aux-process-instance-id: 123456 x-aux-transport-retry-count: 0
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE Pip3A4PurchaseOrderRequest SYSTEM "3A4PurchaseOrderRequestMessageGuideline_v1_2.dtd"> <Pip3A4PurchaseOrderRequest>
<PurchaseOrder> ... </PurchaseOrder> ...
<thisDocumentIdentifier> <ProprietaryDocumentIdentifier>1021358129419 </ProprietaryDocumentIdentifier> </thisDocumentIdentifier> <GlobalDocumentFunctionCode>Request</GlobalDocumentFunctionCode>
</Pip3A4PurchaseOrderRequest>
Lorsque l'application dorsale et WebSphere Business Integration Connect s'envoient des messages entre eux, chacun doit utiliser le même protocole de transfert des messages. Le protocole de transfert des messages définit le protocole de communication utilisé pour l'envoi des messages.
Business Integration Connect communique avec une application dorsale via
son interface d'intégration dorsale. Le Tableau 10 fournit la liste des protocoles de transfert compatibles
avec l'interface d'Intégration dorsale
Tableau 10. Protocoles de transfert compatibles avec Business Integration Connect
Protocole de transfert | Pour plus d'informations |
---|---|
HTTP ou HTTPS | Protocole de transfert HTTP |
Fichiers de système de fichiers | Protocole de système de fichiers pour les éditions Enterprise et Advanced |
JMS | Protocole JMS |
Voir les Tableau 15 et Tableau 20 pour plus d'informations sur les protocoles de transfert adaptés à une combinaison spécifique de contenu de message et de regroupement d'intégration dorsale.
Pour envoyer des messages à l'aide d'un protocole HTTP, Business Integration Connect utilise HTTP/S 1.1. Pour recevoir des messages en provenance d'applications dorsales, Business Integration Connect prend en charge HTTP/S version 1.0 et 1.1.
Le message HTTP peut inclure des attributs de regroupement d'intégration. Ces attributs sont inclus dans ce message en fonction du type de regroupement associé à la connexion du participant, comme suit:
Les messages EDI, SOAP, et cXML doivent utiliser l'option Aucun regroupement.
Les messages RosettaNet doivent utiliser le Regroupement d'intégration dorsale
Voici ce qui se passe lorsque des messages HTTP ou HTTPS sont envoyés entre Business Integration Connect et une application pour des échanges asynchrones :
*When the exchange is synchronous (for example, for a SOAP or cXML document), a response is returned along with the HTTP 200 message in the same HTTP connection.
Pour envoyer un message à Business Integration Connect à l'aide du protocole HTTP, l'application dorsale effectue les opérations suivantes :
L'attribut Content-Type de l'en-tête du niveau de transfert fournit le codage utilisé pour le message.
Pour le regroupement d'intégration dorsale, l'application dorsale ajoute les attributs de l'en-tête du protocole requis par Business Integration Connect.
Pour activer ce type d'échange de message via HTTP, sur l'écran Détails Cible de la Console de Communauté, définir une Cible destinée aux documents entrants. Pour plus d'informations, voir Réception de documents de l'application dorsale.
Pour recevoir un message de Business Integration Connect à l'aide du protocole HTTP, l'application dorsale effectue les opérations suivantes :
Pour activer ce type d'échange de message via HTTP, utiliser l'écran Passerelle de la Console de Communauté pour configurer la passerelle destinée aux documents sortants. Pour plus d'informations, voir Envoi de documents à l'application dorsale.
Le protocole JMS est basé sur le service JMS (Java Message Service) et transfère les messages par l'intermédiaire de files d'attente JMS transactionnelles et permanentes fournies, par exemple, par IBM WebSphere MQ. Le protocole JMS prend en charge les types de message JMS suivants :
Dans le protocole JMS, le système d'envoi envoie un message JMS au système de réception à l'aide de l'opération de mise en file d'attente. Le système de réception extrait le message de la file d'attente, le conserve puis procède à l'opération de vidage de la file d'attente pour supprimer le message de la file d'attente. A partir de ce moment, le système de réception peut traiter le message de manière asynchrone.
Le message JMS peut inclure des attributs de regroupement d'intégration. Ces attributs sont inclus dans ce message en fonction du type de regroupement associé à la connexion du participant, comme suit:
A l'exception des messages binaires, Business Integration Connect prend en charge l'envoi et la réception des messages JMS utilisant n'importe quel type de regroupement. Les messages binaires reçus d'une application doivent utiliser le regroupement d'intégration dorsale. L'inverse n'est pas vrai car Business Integration Connect prend en charge l'envoi des messages binaires vers l'application dorsale au moyen de n'importe quel type de regroupement.
Pour envoyer un message à Business Integration Connect à l'aide du protocole JMS, l'application dorsale effectue les opérations suivantes :
L'attribut d'en-tête content_type définit le type de contenu du message et l'attribut d'en-tête content_length définit la longueur du message (en octets).
Pour le regroupement d'intégration dorsale, l'application ajoute les attributs d'en-tête JMS requis.
Pour activer ce type d'échange de message via JMS, sur l'écran Détails Cible de la Console de Communauté, définir une Cible destinée aux documents entrants. Pour plus d'informations, voir Réception de documents de l'application dorsale.
Pour recevoir un message de Business Integration Connect à l'aide du protocole JMS, l'application dorsale effectue les opérations suivantes :
Pour activer ce type d'échange de message via JMS, utiliser l'écran Passerelle de la Console de Communauté pour configurer la passerelle destinée aux documents sortants. Pour plus d'informations, voir Envoi de documents à l'application dorsale.
Le protocole de système de fichiers permet à Business Integration Connect d'envoyer des messages en les plaçant dans une arborescence de répertoires définie. Business Integration Connect reçoit des messages en les lisant à partir de l'arborescence de répertoires. Le protocole de système de fichiers prend en charge les éléments suivants :
Pour envoyer un message à Business Integration Connect à l'aide du protocole de système de fichiers, l'application effectue les opérations suivantes :
Pour activer ce type d'échange de message via le système de fichiers, sur l'écran Détails Cible de la Console de Communauté, définir une Cible destinée aux documents entrants. La cible du message détermine le répertoire interrogé par Business Integration Connect. Lorsque vous créez une cible, Business Integration Connect crée un répertoire de stockage des documents et ses sous-répertoires pour la cible, comme suit :
<doc_root> Documents Production Test <other destination types>
Business Integration Connect interroge régulièrement les répertoires de stockage des documents et leurs sous-répertoires pour détecter les fichiers de messages. S'il trouve un message, Business Integration Connect le conserve puis le supprime du répertoire. Business Integration Connect traite ensuite le message normalement. Voir le Guide de configuration du concentrateur pour obtenir des informations sur la création d'une cible.
Pour recevoir des messages à l'aide du protocole de système de fichiers, l'application effectue les opérations suivantes :
Pour activer ce type d'échange de message via le système de fichiers, utiliser l'écran Passerelle de la Console de Communauté pour configurer la passerelle destinée aux documents sortants.Business Integration Connect place le message dans le répertoire Documents défini par la passerelle. En définissant le répertoire de destination en fonction de la passerelle, chaque connexion de participant peut avoir un répertoire différent. Pour plus d'informations sur les passerelles, voir le Guide de configuration du concentrateur.
Business Integration Connect permet l'intégration de nombreux types
d'applications dorsales.En règle générale, une application dorsale
est accessible via un système dorsal du type gestionnaire
d'intégration. Ce guide traite des différents types
d'intégration dans les systèmes dorsaux présentés dans le Tableau 11.
Tableau 11. Applications dorsales prises en charge pour Business Integration Connect
Application dorsale | Pour plus d'informations |
---|---|
WebSphere InterChange Server | Présentation de l'intégration à InterChange Server |
WebSphere Business Integration Message Broker | Intégration à WebSphere Business Integration Message Broker |
WebSphere Data Interchange | Intégration à WebSphere Data Interchange |