Quel regroupement allez-vous utiliser ?
Le type de regroupement détermine le format dans lequel
WebSphere Partner Gateway envoie le message au système dorsal et format dans lequel ce dernier envoie le message à WebSphere Partner Gateway.
Vous pouvez utiliser la Console de communauté pour établir la
connexion avec les participants de communauté et spécifier le
regroupement utilisé entre WebSphere Partner Gateway et l'application
dorsale.
Pour déterminer le type de regroupement à utiliser, vous devez être en mesure de répondre aux questions suivantes :
- Quels types de regroupement peuvent être utilisés avec une application dorsale?
- Quels sont les types de regroupement adaptés à un message dans un protocole métier spécifique ?
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 WebSphere Partner Gateway pour l'intégration. Le tableau 4 répertorie les types de
regroupement appropriés lorsque WebSphere Partner Gateway échange des
documents ou des messages avec une application dorsale du
Gestionnaire de communauté.
Tableau 4. Types de regroupement appropriés pour l'intégration dorsale
Type de regroupement |
Description |
Aucun regroupement |
Envoie le message au système dorsal ou au concentrateur sans données 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 |
Remarque : D'autres types de regroupement (tels que AS) sont
disponibles dans WebSphere Partner Gateway. Toutefois, pour l'intégration dans des applications dorsales, il est recommandé d'utiliser uniquement les valeurs "regroupement d'Intégration Dorsale" et "aucun regroupement".
Aucun regroupement
Lorsque le regroupement a la valeur Aucun, WebSphere
Partner Gateway 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, WebSphere Partner Gateway
envoie uniquement le message à l'application dorsale. Les informations contenues dans le document contrôlent le routage des données.
Regroupement d'intégration
dorsale
Lorsque le regroupement a la valeur Intégration dorsale,
les messages envoyés à ou reçus par une application dorsale
contiennent les éléments suivants :
- des un
en-tête de niveau de transfert qui contient des méta-informations
relatives au message (requis) ;
- des des données utiles qui
incluent le contenu du message (requis) ;
- une pièce jointe (facultatif).
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 WebSphere Partner Gateway pour traiter et acheminer le
message vers la destination appropriée. L'en-tête du niveau de
transfert est bidirectionnel de sorte que tous les messages qui
entrent et sortent de WebSphere Partner Gateway comportent les zones
obligatoires et facultatives qui s'appliquent.
Le tableau 5 répertorie les zones de l'en-tête du niveau de transfert.
Tableau 5. 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 WebSphere Partner Gateway, 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 (par exemple,
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
WebSphere Partner Gateway, 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. Les valeurs valides sont
les suivantes : Production et Test. Ces valeurs sont renseignées 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é, WebSphere Partner Gateway 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 WebSphere Partner Gateway 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. |
|
x-out-file-name |
Nom du fichier d'origine pour les messages envoyés via JMS avec le regroupement d'intégration dorsale. (Voir la remarque 2.) |
|
content-type |
Type de contenu du message |
|
content-length |
Longueur du message (en octets) |
|
Remarques :
- Pour des raisons de compatibilité avec IBM WebSphere MQ (un
fournisseur JMS), on utilisera des traits de soulignements au lieu de traits
d'union dans les zones des messages transmis via le protocole JMS.
Par exemple, dans un message JMS, la zone x_aux_sender_id remplace la zone x-aux-sender-id.
-
Si la cible est spécifiée comme étant HTTP et que la valeur du module est
Aucun, le nom de fichier d'origine est défini dans les en-têtes HTTP
en tant que "Content-Disposition: attachment;po.xml".
Si la
cible est spécifiée comme étant JMS et que la valeur du module est
Intégration Dorsale, le nom de fichier d'origine est écrit dans
x-out-file-name avec d'autres en-têtes x-aux-*.
Le tableau 5 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 :
Le tableau 6 décrit
l'emplacement où WebSphere Partner Gateway extrait les valeurs pour
les zones de l'en-tête du niveau de transfert à partir d'un message
RosettaNet.
Tableau 6. 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> |
Le tableau 7 décrit
l'emplacement où WebSphere Partner Gateway extrait les valeurs pour les
zones de l'en-tête du niveau de transfert à partir d'un message AS2.
Remarque : Les valeurs respectent les majuscules.
Tableau 7. Zones de l'en-tête du niveau de transfert à partir d'un contenu AS2
Zone d'en-tête |
Source de la valeur lorsqu'un participant de
communauté envoie un message AS/2 au concentrateur |
Source de la valeur lorsqu'un message AS2 est
envoyé à un participant de communauté |
x-aux-sender-id |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-process-instance-id |
Cette zone n'est pas utilisée pour AS2. |
Cette zone n'est pas utilisée pour AS2. |
x-aux-msg-id |
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-msg-id. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-system-msg-id |
Cette zone est définie par l'ID unique généré en
interne pour ce message. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-production |
Cette zone n'est pas utilisée pour AS2. |
Cette zone n'est pas utilisée pour AS2. |
Le tableau 8 décrit
l'emplacement où WebSphere Partner Gateway extrait les valeurs pour
les zones de l'en-tête du niveau de transfert à partir d'un message
AS1.
Remarque : Les valeurs respectent les majuscules.
Tableau 8. Zones de l'en-tête du niveau de transfert à partir d'un contenu AS1
Zone d'en-tête |
Source de la valeur lorsqu'un participant de
communauté envoie un message AS/1 au concentrateur |
Source de la valeur lorsqu'un message AS/1 est
envoyé à un participant de communauté |
x-aux-sender-id |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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é. |
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 |
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. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-process-instance-id |
Cette zone n'est pas utilisée pour AS1. |
Cette zone n'est pas utilisée pour AS1. |
x-aux-msg-id |
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-msg-id. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-system-msg-id |
Cette zone est définie par l'ID unique généré en
interne pour ce message. |
Il est inutile de définir cette zone dans le
message d'intégration dorsale entrant. |
x-aux-production |
Cette zone n'est pas utilisée pour AS1. |
Cette zone n'est pas utilisée pour AS1. |
Données utiles
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 9.
Tableau 9. 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 |
EDI |
Enveloppe EDI |
Document ROD ou XML |
Document ROD ou XML |
Les données utiles peuvent être encodées en Base64 et regroupées
dans une enveloppe de transfert XML dans les
cas suivants :
- Si le document contient une pièce jointe
Un document doté 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.
- Si l'indicateur de l'enveloppe de regroupement d'intégration
dorsale est positionné sur Oui
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 dans le profil Gestionnaire de communauté's,
effectuez les tâches suivantes :
- Cliquez sur Administrateur du compte > Profils.
- Entrez le nom du Gestionnaire de communauté(ou effectuez une recherche sur tous les participants).
- Cliquez sur l'icône Afficher les détails en
regard du nom du Gestionnaire de communauté.
- Cliquez sur Prestataires B2B.
- Cliquez sur l'icône Edition à côté
d'Intégration Dorsale.
- Affectez à l'indicateur d'enveloppe la valeurOui.
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.
WebSphere Partner Gateway 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.
Pièces jointes
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 10 décrit les attributs XML dans les codes
des données utiles et des pièces jointes.
Tableau 10. Attributs XML des codes des données utiles et des pièces jointes
Attributs XML |
Description |
Obligatoire ? |
Content-Type |
Identifie le type/sous-type MIME, tel que text/xml ou image/gif. |
Oui |
Encoding |
Identifie le codage. Dans la mesure où les pièces jointes et les données utiles doivent être cryptées en Base64, la seule valeur valide pour cet attribut est "Base64". |
Non |
La figure 13 présente un exemple de document inséré dans une enveloppe XML comprenant des données utiles et une pièce jointe.
Remarque : L'espace de nom est requis dans cet exemple :
xmlns="http://www.ibm.com/websphere/bcg/2003/v1.0/wbipackaging"
Figure 13. 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>
Remarque : Pour traiter les documents regroupés dans une
enveloppe XML via le WebSphere Interchange Server, WebSphere Partner
Gateway inclut un gestionnaire de pièces jointes. Pour plus d'informations, voir Gestion des documents contenant des pièces jointes.
Quel type de regroupement peut être utilisé pour vos documents ?
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 12, le
tableau 13 et le
tableau 14 pour obtenir la liste
complète des types de document et des types de regroupement auxquels
ils peuvent être associés.
Exemple de regroupement d'intégration dorsale sur HTTP
La figure 14 présente un exemple de message provenant de WebSphere Partner Gateway à destination d'une application utilisant le protocole de transfert HTTP. Notez que le message ne contient aucune pièce jointe.
Figure 14. 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>
