Planification de l'intégration dorsale

Cette section fournit les informations nécessaires à la planification de votre intégration dorsale avec WebSphere Business Integration Connect:

Quel est le protocole métier utilisé ?

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:

Services Web (SOAP)

Business Integration Connect peut mettre les services Web suivants à la disposition des membres du concentrateur :

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.

cXML

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:

Remarque :
Si la conversion du document XML est utilisée pour les transactions de requête/réponse synchrones avec le participant de communauté, la réponse est renvoyée de manière asynchrone à l'application dorsale.

Pour plus d'informations, notamment sur la configuration des définitions du flot de documents cXML, voir le Guide Administrateur.

RosettaNet

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.

Notification d'événement

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.

Structure des messages d'événement

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 :
  • 100 - Business Integration Connect a transmis le document et a reçu un accusé de réception.
  • 800 - L'application a annulé le PIP.
  • 900 - Business Integration Connect a reçu une exception d'accusé de réception, une exception générale ou un PIP 0A1Failure du participant de communauté.
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)

Exemple de message de notification d'événement

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>
 

Quel regroupement allez-vous utiliser ?

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.

Types de regroupement adaptés à l'intégration

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

Remarque :
D'autres types de regroupement (tels que AS)sont disponibles dans Business Integration Connect. 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, 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.

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 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.

Contenu de l'en-tête du niveau de transfert

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)

Remarque :
Pour des raisons de compatibilité avec IBM WebSphere MQ (A JMS provider), 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.

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.

Remarque :
Les valeurs respectent les majuscules.

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.

Remarque :
Les valeurs respectent les majuscules.

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.

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 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:

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.

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 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
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 4 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 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>
 
Remarque :
Pour traiter les documents regroupés dans une enveloppe XML via le WebSphere InterChange Server, Business Integration Connect 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 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.

Exemple de regroupement d'intégration dorsale sur HTTP

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>
 

Quel transfert de message allez-vous utiliser ?

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.

Protocole de transfert HTTP

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:

Processus

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 :

  1. Le système source (Business Integration Connect ou l'application dorsale) soumet un message HTTP au système cible au moyen d'un URL spécifique.
  2. Le système cible reçoit le message et envoie un accusé de réception du niveau de protocole, HTTP 200 ou 202, pour indiquer le changement de droits de propriété. Le système source ignore le corps de ce message d'accusé de réception. Si une erreur se produit au cours du traitement, le système cible renvoie un message HTTP 500 au système source.
  3. Si Business Integration Connect est le système cible (i.e. lorsque Business Integration Connect reçoit le message), il conserve ensuite le message et libère la connexion vers le système source.
  4. Les sytème cible peut ensuite traiter le message de manière asynchrone.

*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.

Envoi et réception de messages à l'aide du protocole HTTP

Pour envoyer un message à Business Integration Connect à l'aide du protocole HTTP, l'application dorsale effectue les opérations suivantes :

  1. Elle crée le message.

    L'attribut Content-Type de l'en-tête du niveau de transfert fournit le codage utilisé pour le message.

  2. Elle groupe le message conformément au regroupement défini pour la connexion.

    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.

  3. Elle soumet le message à l'URL utilisé par Business Integration Connect pour recevoir ces messages.
  4. Si l'échange est synchrone, l'application dorsale attend de recevoir une réponse dans la même connexion que celle utilisée pour la requête.

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 :

  1. Elle détecte l'arrivée d'un message sur un URL spécifique.
  2. Dès réception du message, elle le traite :
  3. Si l'échange est synchrone, l'application dorsale renvoie une réponse dans la même connexion que celle utilisée pour la requête.

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.

Protocole JMS

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.

Envoi de messages à l'aide du protocole JMS

Pour envoyer un message à Business Integration Connect à l'aide du protocole JMS, l'application dorsale effectue les opérations suivantes :

  1. Elle crée le message.

    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).

  2. Elle groupe le message conformément au regroupement défini pour la connexion.

    Pour le regroupement d'intégration dorsale, l'application ajoute les attributs d'en-tête JMS requis.

  3. Elle envoie le message à la file d'attente JMS utilisée par l'application dorsale pour envoyer des messages à Business Integration Connect.

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.

Réception de messages à l'aide du protocole JMS

Pour recevoir un message de Business Integration Connect à l'aide du protocole JMS, l'application dorsale effectue les opérations suivantes :

  1. Elle détecte l'arrivée d'un message sur la file d'attente JMS.
  2. Dès réception du message, elle le traite :

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.

Protocole de système de fichiers pour les éditions Enterprise et Advanced

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 :

Envoi de messages à l'aide du protocole de système de fichiers

Pour envoyer un message à Business Integration Connect à l'aide du protocole de système de fichiers, l'application effectue les opérations suivantes :

  1. Elle crée le fichier de messages dans un répertoire temporaire.
  2. Une fois le fichier de messages prêt, elle déplace le fichier dans le répertoire approprié interrogé par Business Integration Connect.

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.

Réception de messages à l'aide du protocole de système de fichiers

Pour recevoir des messages à l'aide du protocole de système de fichiers, l'application effectue les opérations suivantes :

  1. Elle interroge le répertoire approprié à la recherche de fichiers de messages.
    Remarque :
    Les fichiers temporaires (dont l'extension est .tmp ou .tmp1) doivent être ignorés. L'application ne doit pas extraire ni supprimer ces fichiers temporaires.
  2. Chaque fois qu'un message se présente, elle le conserve.
  3. Elle supprime le message du répertoire.
  4. Elle traite le message.

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.

Comment accéder à l'application dorsale?

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

Copyright IBM Corp. 1997, 2004