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 de configuration du concentrateur. Cette section fournit des informations nécessaires à l'intégration spécifiques aux protocoles métiers suivants:

Services Web (SOAP)

WebSphere Partner Gateway peut mettre les services Web suivants à la disposition des membres de la communauté 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 WebSphere Partner Gateway reçoit un document cXML provenant d'un participant de communauté, il le valide et le convertit (le cas échéant) avant de l'envoyer à l'application dorsale du Gestionnaire de communauté. Notez que la conversion ne doit pas être utilisée pour les messages cXML synchrones. Dans le cadre d'un échange synchrone, l'application dorsale génère une réponse qui est renvoyée par la suite par WebSphere Partner Gateway au participant de communauté (si approprié au message).

Une application dorsale du Gestionnaire de communauté qui doit envoyer un document cXML peut procéder de deux manières:

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 au système dorsal.

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

EDI

WebSphere Partner Gateway accepte les documents EDI émanant des participants de réseaux à valeur ajoutée et d'Internet.Les documents EDI envoyés à un réseau à valeur ajoutée ou reçus par celui-ci utilisent le transfert de script FTP. Ce transfert peut également être utilisé pour envoyer des documents à Internet ou en recevoir de ce dernier. Pour plus d'informations sur le transfert de scripts FTP, voir le Guide de configuration du concentrateur.

Un document EDI entre dans le concentrateur et quitte le concentrateur dans une enveloppe EDI, appelée Interchange. L'interchange contient des transactions ou des groupes de transactions EDI.

Dans le cas où l'interchange EDI sera transmis via le concentrateur(sans être désenveloppé), vous créez une connexion entre celui-ci et le Gestionnaire de communauté.

Cependant, dans le cas où l'interchange EDI sera désenveloppé, le processus de création d'interactions et de connexions est différent de celui d'autres protocoles de gestion. L'Interchange doit être désenveloppé et les transactions individuelles doivent être traitées. Les transactions sont généralement converties en un autre format, selon une mappe de transformation importée à partir du client Data Interchange Services. Si les transactions EDI sont converties en documents XML ou ROD (données orientées enregistrement), ces documents sont envoyés au Gestionnaire de communauté ou au participant. Si les transactions sont converties vers d'autres formats EDI, les transactions sont enveloppées avant d'être envoyées au Gestionnaire de communauté ou au participant.

Application dorsale vers des flux de participants

Une application dorsale peut envoyer les types de document suivants :

Participant aux flux d'applications dorsales

Un participant peut envoyer les types de document suivants :

Accusés de réception fonctionnels

Un accusé de réception fonctionnel spécifie qu'un interchange EDI a été reçu. Il est toujours enveloppé avant d'être envoyé.

Remarque : Les accusés de réception fonctionnels s'appliquent uniquement aux interchanges qui sont désenveloppés ou générés par WebSphere Partner Gateway. Ils ne s'appliquent pas aux interchanges transmis via WebSphere Partner Gateway.

Pour les interchanges reçus par WebSphere Partner Gateway

Pour les interchanges générés par WebSphere Partner Gateway :

RosettaNet

WebSphere Partner Gateway permet d'envoyer et de recevoir des documents conformes aux normes RosettaNet 1.1 et 2.0. Lorsqu'un participant envoie un message RosettaNet au concentrateur, l'intégration dorsale doit être spécifié à l'extrémité cible de la connexion du participant. Le concentrateur convertit les données utiles du message au format RNSC et envoie le message au système dorsal. En raison de l'utilisation du regroupement d'intégration dorsale, le concentrateur ajoute des en-têtes du niveau de transfert au message. Ce message est envoyé via le protocole de transfert HTTP ou JMS. L'en-tête du niveau de transfert conserve les méta-informations qui ne font pas partie du PIP et active WebSphere Partner Gateway afin qu'il achemine correctement le message.

De façon similaire, lorsque le système dorsal du Gestionnaire de communauté envoie un message RNSC au concentrateur, le regroupement d'intégration dorsale doit être spécifié à l'extrémité source de la connexion du participant et le système dorsal doit fournir les en-têtes du niveau de transfert.

Par exemple, imaginons qu'une application souhaite envoyer un message à un participant de communauté au moyen de RosettaNet sur HTTP. L'application fournit le contenu du service RosettaNet et ajoute l'en-tête du niveau de transfert. L'en-tête identifie le participant de communauté en charge de la requête, le PIP à envoyer et la version du PIP ainsi que d'autres informations. Ces informations permettent alors à WebSphere Partner Gateway d'envoyer le PIP approprié au participant de communauté.

Les informations relatives à la définition de la prise en charge de RosettaNet et à la configuration des PIP se trouvent dans le Guide de configuration du Concentrateur.

Notification d'événement

WebSphere Partner Gateway exécute des processus RNIF PIP avec les participants de communauté pour le compte des applications dorsales du Gestionnaire de communauté.Par conséquent, WebSphere Partner Gateway fournit une notification d'événement afin d'informer l'application dorsale des divers aspects de l'exécution du processus RNIF PIP. La notification d'événement permet à WebSphere Partner Gateway, par exemple, de notifier l'application si WebSphere Partner Gateway n'est pas en mesure d'envoyer un PIP au participant. L'application peut ainsi prendre en charge cet échec.

Un message de notification d'événement est un document XML qui comporte des informations sur les événements qui sont intervenus dans WebSphere Partner Gateway ou dans une application. Ces messages ont la même structure que tout autre message entrant ou sortant de WebSphere Partner Gateway : en d'autres termes, ils comportent un en-tête de niveau de transfert et des données utiles. WebSphere Partner Gateway peut être configuré pour envoyer ou non des messages de notification d'événement car ces messages sont facultatifs.

Le tableau 2 résume les messages de notification d'événements que WebSphere Partner Gateway est susceptible d'envoyer à une application dorsale.

Tableau 2. Notification d'événement envoyé à l'application dorsale
Condition d'événement Message de notification d'événement

WebSphere Partner Gateway fournit un document RosettaNet à un participant de communauté et reçoit un accusé de réception.

Evénement 100

WebSphere Partner Gateway annule un PIP en générant un message 0A1 et en le transmettant au participant de communauté.

Evénement 800

WebSphere Partner Gateway reçoit une exception d'accusé de réception ou une exception générale d'un participant de communauté.

Evénement 900

WebSphere Partner Gateway peut envoyer des messages 0A1 à l'application cible comme il le ferait avec n'importe quel autre PIP, s'il a été configuré pour envoyer ces messages à l'aide de la Procédure de gestion des listes d'exclusion. Voir "Gestion des listes d'exclusion" dans le Guide de l'administrateur.

Une application peut envoyer un message de notification d'événement à WebSphere Partner Gateway pour annuler un PIP RosettaNet.

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. Cependant, les données utiles du message ont une structure spécifique, comme le montre schéma XML dans la figure 11.

Figure 11. Schéma XML pour un message de notification 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 3 décrit chaque zone contenue dans les données utiles de l'événement.

Tableau 3. Zones de la notification d'événement XML
Zone Description
StatusCode Type de message. Les valeurs correctes sont :
  • 100 - WebSphere Partner Gateway a transmis le document et a reçu un accusé de réception.
  • 800 - L'application a annulé le PIP.
  • 900 - WebSphere Partner Gateway 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 ayant déclenché 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 notification d'événement

La figure 12 présente un exemple de message de notification d'événement envoyé via le protocole HTTP.

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

Copyright IBM Corp. 2003, 2005