Utilisation du protocole de transfert HTTP avec une version antérieure à ICS 4.2.2

WebSphere Business Integration Connect peut échanger des documents avec une version antérieure à WebSphere InterChange Server 4.2.2 (ICS) via le protocole de transfert HTTP.

Remarques:

  1. Pour échanger des documents entre WebSphere Business Integration Connect et InterChange Server version 4.2.2 via le protocole de transfert HTTP, voir Utilisation du protocole de transfert HTTP avec ICS version 4.2.2.

  2. Si vous échangez des documents SOAP sur le protocole HTTP, voir Envoi de documents SOAP sur HTTP/S.

Cette section fournit les informations suivantes sur la manière de configurer une version d'InterChange Server antérieure à la version 4.2.2 et les composants compatibles ICS appropriés en vue de leur utilisation avec Business Integration Connect sur HTTP :

Envoi de documents à une version d'ICS antérieure à 4.2.2 via HTTP

Cette section explique comment envoyer des documents à partir de Business Integration Connect vers une version d'ICS antérieure à 4.2.2 via le protocole de transfert HTTP :

Le document que Business Integration Connect envoie vers InterChange Server déclenche une notification d'événements dans InterChange Server.

Composants requis pour l'envoi

Business Integration Connect peut envoyer des documents aux versions suivantes d'InterChange Server antérieures à la version 4.2.2 via le protocole de transfert HTTP :

Pour que Business Integration Connect envoie un document à une version d'ICS antérieure à 4.2.2 via le protocole HTTP, vous devez configurer ces deux composants. Tableau 45 résume ces étapes de configuration.

Tableau 45. Configuration de Business Integration Connect et d'InterChange Server
Composant Version Pour plus d'informations
WebSphere Business Integration Connect 4.2.2

Configuration de documents sortants sur le protocole de transfert HTTP

Configuration de documents entrants sur le protocole de transfert HTTP

WebSphere InterChange Server 4.1.1, 4.2.0, 4.2.1 Création d'artefacts ICS antérieurs à la version 4.2.2 pour HTTP

Par ailleurs, pour qu'un document puisse être envoyé à ICS via le protocole HTTP, vous devez utiliser les composants compatibles ICS indiqués dans le Tableau 46. La plupart de ces composants sont fournis par Business Integration Connect.

Tableau 46. Composants requis pour envoyer des documents vers une version d'ICS antérieure à 4.2.2 via HTTP
Composant Description Remarques et limitations
WebSphere Business Integration Connect Servlet (Connect Servlet)

Ce servlet est un client d'accès à WebSphere InterChange Server. Un client d'accès est un processus externe à InterChange Server (ICS) qui peut demander l'exécution d'une collaboration dans ICS.

Le servlet peut être utilisé avec les versions de WebSphere InterChange Server antérieures à 4.2.2.

Remarque :
Le servlet ne peut pas être utilisé avec WebSphere InterChange Server version 4.2.2.
Wrapper Data Handler

Ce gestionnaire de données est appelé par Connect Servlet pour convertir le message HTTP en objet métier de données approprié. Il fait appel au gestionnaire de données correspondant à votre message. Par exemple, si les données utiles sont au format XML, vous pouvez configurer le composant Wrapper Data Handler pour qu'il appelle le composant Data Handler for XML.

Aucune
Un gestionnaire de données utiles Ce gestionnaire de données convertit les données utiles du document (généralement au format XML) en représentation d'objet métier. Ce gestionnaire de données est indispensable et doit prendre en charge le type MIME du document contenant les données utiles.
Attachment Data Handler

Ce gestionnaire de données traite les documents en pièce jointe de votre message.

Ce gestionnaire de données est nécessaire uniquement si votre document contient des pièces jointes.

Remarque :
Tous les composants figurant dans le Tableau 46 sont inclus dans le support d'installation de Business Integration Connect. Pour plus d'informations sur l'emplacement de ces composants, voir Déploiement de Connect Servlet.

La Figure 9 illustre comment Business Integration Connect envoie des documents à une version d'ICS antérieure à 4.2.2 sur le protocole HTTP.

Remarque :
Les composants Wrapper Data Handler, Attachment Data Handler et le gestionnaire de données défini pour les données utiles s'exécutent dans InterChange Server.

Figure 9. Flux de messages entre Business Integration Connect et une collaboration via HTTP


Comme l'illustre la Figure 9, WebSphere Business Integration Connect Servlet est le composant compatible ICS avec lequel Business Integration Connect interagit directement. Connect Servlet est un client d'accès, à savoir un processus externe à InterChange Server qui peut demander l'exécution d'une collaboration ICS. Le client d'accès lance des appels à partir d'une interface de programme d'application (API) appelée Interface SAI (Server Access Interface) afin d'interagir avec ICS. Ces appels sont reçus et interprétés par WebSphere InterChange Server Access, qui est un composant d'ICS et qui assure les interactions avec les clients d'accès. L'interface SAI appelle les collaborations de manière asynchrone.

Remarques:

  1. Bien que certaines interactions entre Business Integration Connect et les systèmes dorsaux soient asynchrones, l'interface SAI continue d'appeler la collaboration de manière synchrone et attend la fin de l'exécution de la collaboration.

  2. Pour plus d'informations sur les clients d'accès et l'interface SAI, voir le document Access Development Guide dans la documentation de WebSphere InterChange Server.

Les étapes suivantes expliquent comment Business Integration Connect participe à la notification d'événements en envoyant un document à une collaboration dans ICS sur le protocole de transfert HTTP :

  1. Business Integration Connect appelle WebSphere Business Integration Connect Servlet pour envoyer le document à InterChange Server.

    Business Integration Connect envoie le document à l'adresse URL désignée comme passerelle cible.

    Remarque :
    Connect Servlet permet d'appeler plusieurs collaborations.
  2. Connect Servlet crée une chaîne Java à partir du message de requête HTTP que Business Integration Connect envoie.

    Le message de requête HTTP est constitué de deux parties :

  3. Le composant Connect Servlet consulte son fichier de propriétés de servlet afin de déterminer la collaboration à appeler, ainsi que l'instruction et le type MIME à utiliser.

    Chaque URL correspond à une collaboration à appeler (pour plus d'informations, voir Configuration de Connect Servlet).

  4. Connect Servlet envoie la chaîne Java, ainsi que les informations du fichier de propriétés du servlet à WebSphere InterChange Server Access via l'interface SAI.

    Etant donné que Connect Servlet peut envoyer uniquement un document à InterChange Server (il ne peut pas recevoir de document), il peut uniquement participer à la notification d'événements avec InterChange Server.

    Remarque :
    Pour assurer le traitement des requêtes à l'aide d'InterChange Server, Business Integration Connect doit interagir avec WebSphere Business Integration Adapter for XML. Pour plus d'informations, voir Réception de documents à partir d'une version antérieure à ICS 4.2.2 via HTTP.
  5. WebSphere InterChange Server Access, dans InterChange Server, reçoit la chaîne Java et appelle le composant Wrapper Data Handler.

    La tâche du composant Wrapper Data Handler consiste à convertir la chaîne Java dans la structure d'objet métier correspondante. InterChange Server s'attend à recevoir des objets métier.

  6. Le composant Wrapper Data Handler procède de la manière suivante pour convertir la chaîne Java dans sa structure d'objet métier :
    1. Il extrait les en-têtes et les données utiles à partir de la chaîne Java.
      Remarque :
      Si le document envoyé à partir de Business Integration Connect contient des pièces jointes, le composant Wrapper Data Handler peut être configuré pour appeler le composant Attachment Data Handler. Les opérations du composant Attachment Data Handler sont décrites dans la section Gestion des documents contenant des pièces jointes.
    2. Il vérifie le type MIME des données utiles et appelle le gestionnaire de données qui a été configuré pour ce type MIME afin de convertir les données utiles en objet métier de données utiles.
    3. Il crée l'objet métier Propriétés HTTP et l'objet métier dynamique.

      Il définit les en-têtes HTTP dans l'objet métier Propriétés HTTP, qui est un enfant du métaobjet dynamique de cet objet métier de données utiles.

    4. Il crée l'objet métier de niveau supérieur et définit l'objet métier d'événement comme son objet métier de requête.

      Le composant Wrapper Data Handler s'attend à ce que l'objet métier de données utiles ait une structure hiérarchique. Pour plus d'informations sur la structure de cet objet métier de données utiles, voir Création de définitions d'objet métier pour envoyer des documents.

    5. Il renvoie l'objet métier de niveau supérieur à l'interface SAI dans InterChange Server.
  7. L'interface SAI appelle la collaboration, en lui transmettant l'objet métier de niveau supérieur.

    Assurez-vous que le port de collaboration de l'objet de collaboration que vous allez appeler est configuré en tant que port externe. Pour plus d'informations sur la configuration des ports, voir la documentation de WebSphere InterChange Server.

  8. La collaboration exécute et renvoie l'objet métier de niveau supérieur au composant Wrapper Data Handler.

    Le remplissage de l'objet métier de réponse (dans l'objet métier de niveau supérieur) dépend du type d'interaction existant entre InterChange Server et Business Integration Connect, par exemple :

    Pour plus d'informations, voir Objet métier de réponse.

  9. Si l'interaction aboutit, Connect Servlet renvoie un accusé de réception HTTP 200 OK à Business Integration Connect.

Configuration de Connect Servlet

WebSphere Business Integration Connect Servlet est un client d'accès, c'est-à-dire un processus externe à InterChange Server qui peut demander l'exécution d'une collaboration dans InterChange Server. Le client d'accès utilise des appels à partir d'une interface de programme d'application (API) appelée Interface SAI pour interagir avec ICS. Ces appels sont reçus et interprétés par WebSphere InterChange Server Access, qui est un composant d'InterChange Server et qui traite les interactions avec les clients d'accès

Remarque :
Pour plus d'informations sur les clients d'accès et l'interface SAI, voir le document Access Development Guide dans la documentation de WebSphere InterChange Server.

La configuration de Connect Servlet nécessite les étapes suivantes :

Déploiement de Connect Servlet

Les composants Connect Servlet, Wrapper Data Handler et le fichier référentiel de Wrapper Data Handler sont disponibles sur le support d'installation de Business Integration Connect, dans les répertoires indiqués par le Tableau 47.

Tableau 47. Emplacement des composants de Connect Servlet
Composant Emplacement
Connect Servlet Integration/WBI/WICS/WBICServlet/ bcgwbiservlet.war
Wrapper Data Handler Integration/WBI/WICS/WBICServlet/ bcgwbiwrapperdh.jar
Fichier référentiel pour Wrapper Data Handler Integration/WBI/WICS/WBICServlet MO_DataHandler_WBIWrapper.in

Remarque :
Si vous envisagez d'envoyer des documents qui contiennent des pièces jointes, vous pouvez également déployer le composant Attachment Data Handler et son fichier référentiel, comme décrit dans Déploiement du gestionnaire de données de pièces jointes.

Ce servlet peut se connecter à WebSphere InterChange Server versions 4.1.1, 4.2.0 et 4.2.1. Il peut être déployé sur les plateformes de n'importe quelle version d'InterChange Server prise en charge. Vous devez également vous assurer que l'interface SAI est prise en charge sur cette plateforme. Pour obtenir la liste des plateformes sur lesquelles la version d'ICS que vous utilisez est prise en charge, voir la documentation de WebSphere InterChange Server.

Pour déployer les composants dans le Tableau 47, suivez ces étapes :

  1. Déployez Connect Servlet et les fichiers associés sur le serveur Web conformément à la documentation relative au serveur Web.
  2. Assurez-vous que les fichiers suivants sont inclus dans la variable CLASSPATH de Connect Servlet :

    Ces fichiers se situent dans le sous-répertoire lib du répertoire produit d'InterChange Server.

    Remarques:

    1. Ils doivent avoir la même version d'InterChange Server que vous allez appeler.

    2. Ces fichiers doivent être disponibles pour le conteneur Web de Connect Servlet sur votre serveur Web. Pour plus d'informations sur la façon de rendre des fichiers disponibles pour un conteneur Web, consultez la documentation de votre serveur Web.
  3. Assurez-vous que les fichiers suivants sont inclus dans la variable CLASSPATH de Connect Servlet :

    Ces fichiers sont disponibles sur le support d'installation de Business Integration Connect, dans le répertoire suivant :

    integration/wbi/wics/http/lib/thirdparty
     

    Remarque :
    Ces fichiers doivent être disponibles pour le conteneur Web de Connect Servlet sur votre serveur Web. Pour plus d'informations sur la façon de rendre des fichiers disponibles pour un conteneur Web, consultez la documentation de votre serveur Web.
  4. Rendez le fichier .ior (Interoperable Object Reference) d'InterChange Server accessible sur la machine où Connect Servlet est déployé.

    Si le composant Connect Servlet est situé sur une machine différente de celle d'InterChange Server, vous pouvez procéder comme suit pour rendre le fichier .ior accessible :

    Remarque :
    Vous devez également mettre à jour la propriété ICS_IORFILE dans le fichier de propriétés de Connect Servlet avec l'emplacement de ce fichier .ior. Pour plus d'informations, voir Identification de l'instance d'InterChange Server.

Définition des propriétés de Connect Servlet

Comme mentionné dans Envoi de documents à une version d'ICS antérieure à 4.2.2 via HTTP, le fichier de propriétés du servlet contient des informations telles que le nom du port et l'instruction, qui sont nécessaires à WebSphere Business Integration Connect Servlet pour appeler une collaboration. Vous devez créer ce fichier de propriétés de servlet, en indiquant les informations générales relatives à WebSphere InterChange Server. Ensuite, pour toutes les collaborations que vous voulez que le servlet appelle, vous devez fournir les informations relatives à cette collaboration.

Cette section explique comment définir les propriétés de Connect Servlet :

Création du fichier de propriétés de servlet

Un fichier de propriétés de servlet contient les sections indiquées dans le Tableau 48.

Tableau 48. Sections du fichier de propriétés du servlet
Section du fichier de propriétés du servlet Description Pour plus d'informations
Informations générales Propriétés permettant d'identifier l'instance d'InterChange Server Identification de l'instance d'InterChange Server
Informations de collaboration Propriétés permettant d'identifier chaque collaboration à appeler Identification des collaborations à appeler
Informations de connexion Propriétés permettant de configurer la connexion du servlet Indication de l'emplacement du fichier journal du servlet

Identification de l'instance d'InterChange Server  La première partie du fichier de propriétés de Connect Servlet contient des informations générales qui permettent d'identifier l'instance d'InterChange Server avec laquelle Business Integration Connect communique. Cette instance d'ICS contient la ou les collaboration(s) dont a besoin Business Integration Connect pour effectuer un appel. Le Tableau 49 indique les propriétés générales du fichier de propriétés du servlet.

Tableau 49. Propriétés générales du fichier de propriétés du servlet
Nom de propriété Description Exemple
ICS_SERVERNAME Machine hôte sur laquelle est exécuté WebSphere InterChange Server. Server1
ICS_VERSION Numéro de version de WebSphere InterChange Server. Les valeurs possibles sont 4.1.1, 4.2.0 et 4.2.1. 4.2.0
ICS_IORFILE

Nom du fichier .ior (Interoperable Object Reference) utilisé pour accéder à WebSphere InterChange Server Access. L'exemple illustre comment indiquer le chemin d'accès sur un système Windows.

Remarque :
Ce chemin d'accès doit être entré sur une seule ligne.
c:/myiorlocation/
Server1ICS.ior
ICS_USERNAME ID utilisateur utilisé pour la connexion à WebSphere InterChange Server. admin
ICS_PASSWORD Mot de passe utilisé pour la connexion à WebSphere InterChange Server. null
ICS_ENCRYPTED_PASSWORD Indique si le mot de passe ICS_PASSWORD est chiffré. Le servlet affecte la valeur true à cette zone si ce mot de passe est chiffré. false
ICS_DISABLEENCRYPTION Indique si le chiffrement du mot de passe est désactivé (true) ou activé (false). Affectez à cette zone la valeur false si vous voulez autoriser le chiffrement des mots de passe. true

Remarque :
Pour consulter un exemple de fichier de propriétés de servlet qui définit les valeurs indiquées dans la colonne Exemple du Tableau 49, voir Exemple de fichier de propriétés du servlet.

Identification des collaborations à appeler 

La seconde partie du fichier de propriétés de Connect Servlet contient des informations de collaboration, qui associent l'URL de collaboration à des propriétés de collaboration. Cette partie sépare les URL de collaboration en deux éléments, comme suit :


Tableau 50. Propriétés de collaboration du fichier de propriétés du servlet
Nom de propriété Description Exemple
WBIC_SERVLET_COUNT

Nombre d'URL configurés dans ce fichier :

  • Si le nombre attribué est 1, le servlet traitera l'URL et les propriétés définies pour WBIC_URL_1.
  • Si le nombre attribué est 2, le servlet traitera l'URL et les propriétés définies pour WBIC_URL_1 et WBIC_URL_2.

1
WBIC_URL_1 Nom de l'URL relatif PurchaseOrder
WBIC_URL_1_COLLAB Nom de la collaboration PurchaseOrderCollab
WBIC_URL_1_PORT Nom du port de la collaboration From
WBIC_URL_1_VERB Instruction à laquelle la collaboration a souscrit Create
WBIC_URL_1_WRAPPER_MIME Type MIME pris en charge par Wrapper Data Handler. Notez que l'exemple est en minuscule. wbic/wrapper
WBIC_URL_1_CHARENCODE Codage du caractère à utiliser pour les requêtes HTTP. Indiquez un codage de caractères Java correct. UTF-8

Remarque :
Pour consulter un exemple de fichier de propriétés de servlet qui définit les valeurs indiquées dans la colonne Exemple du Tableau 50, voir Exemple de fichier de propriétés du servlet.

La section de collaboration du fichier de propriétés du servlet fournit une URL relative dans le but d'identifier la collaboration à exécuter. Pour rechercher la collaboration au moment de l'exécution, Connect Servlet combine les informations suivantes :

Si vous avez utilisé les exemples de valeurs indiquées dans le Tableau 50, Connect Servlet doit obtenir l'URL de la collaboration PurchaseOrderCollab. Pour rechercher cette URL, le servlet effectue les opérations suivantes :

  1. Il recherche l'URL du servlet qui identifie l'emplacement de Connect Servlet.

    Le servlet obtient l'URL du servlet à partir de votre serveur Web. Par exemple, supposons que vous avez déployé Connect Servlet à l'emplacement suivant :

    http://www.yourcompany.com/tasks
     
  2. Ajoutez à l'URL du servlet le chemin indiqué dans la propriété WBIC_URL_count.

    Dans le Tableau 50, la propriété WBIC_URL_1 contient la valeur "PurchaseOrder". Par conséquent, Connect Servlet ajoute cette chaîne à l'URL du servlet afin d'obtenir l'URL suivante pour la collaboration :

    http://www.yourcompany.com/tasks/PurchaseOrder
     

Dans les propriétés de collaboration, la propriété WBIC_URL_1_WRAPPER_MIME indique le type MIME défini pour le composant Wrapper Data Handler. Si vous indiquez plusieurs types MIME, vous devez définir plusieurs métaobjets. Pour plus d'informations, voir Création du métaobjet enfant de Wrapper.

Indication de l'emplacement du fichier journal du servlet  La troisième partie du fichier de propriétés de Connect Servlet contient les propriétés de connexion. Indiquez l'emplacement du fichier journal du servlet dans le fichier de propriétés en ajoutant l'instruction suivante :

log4jappender.RollingFile.File=logFileLocation
 

Comme l'illustre la Figure 10, la propriété log4jappender.RollingFile.File se trouve dans la section du fichier de propriétés du servlet qui configure Log4J. Pour configurer Connect Servlet, il suffit de spécifier l'emplacement du fichier journal en définissant la propriété log4jappender.RollingFile.File. Si vous connaissez bien Log4J, vous pouvez également définir ses autres propriétés.

Exemple de fichier de propriétés du servlet  La Figure 10 illustre un exemple de fichier de propriétés du servlet, qui définit les valeurs des colonnes Exemple du Tableau 49 et du Tableau 50.

Figure 10. Exemple de fichier de propriétés du servlet

# Example properties file for WebSphere Business Integration
 # Connect Servlet
  ICS_SERVERNAME=Server1
  ICS_VERSION=4.2
  ICS_IORFILE=C:/myiorlocation/Server1InterChangeServer.ior
  ICS_USERNAME=admin
  ICS_PASSWORD=null
  ICS_ENCRYPTED_PASSWORD=false
  ICS_DISABLEENCRYPTION=true
 
# Collaboration properties for single collaboration
  WBIC_SERVLET_COUNT=1
 
 WBIC_URL_1=PurchaseOrder
  WBIC_URL_1_COLLAB=PurchaseOrderCollab
  WBIC_URL_1_CHARENCODE=UTF-8
  WBIC_URL_1_PORT=From
  WBIC_URL_1_VERB=Create
  WBIC_URL_1_WRAPPER_MIME=wbic/wrapper
 
#Log4J Debug Properties
 #Possible Categories - debug/info/warn/error/fatal
 #Default Category "error". Output to: stdout and RollingFile
 log4j.rootCategory=debug,RollingFile
 log4j.appender.RollingFile=org.apache.log4j.RollingFileAppender
 
#Log File Name
 log4j.appender.RollingFile.File=D:\\_DEV\\servlet.log
 log4j.appender.RollingFile.MaxFileSize=1000KB
 
#Number of backup files to keep
 log4j.appender.RollingFile.MaxBackupIndex=10
 log4j.appender.RollingFile.layout=org.apache.log4j.PatternLayout
 log4j.appender.RollingFile.layout.ConversionPattern=
    %d{yyyy-MM-ddHH:mm:SS} %-5p [%c{1}] - %m%n
 

Un exemple de fichier de propriétés de servlet est également disponible dans le répertoire SAMPLES sur le support d'installation de Business Integration Connect.

Identification de l'emplacement du fichier de propriétés du servlet

Le descripteur de déploiement de Connect Servlet, web.xml, fournit les paramètres d'initialisation du servlet. Pour identifier l'emplacement du fichier de propriétés du servlet, vous devez définir le paramètre WBIC_FILENAME dans ce descripteur de déploiement. Ce paramètre indique le chemin d'accès absolu au fichier de propriétés du servlet Connect.

Par exemple, si l'exemple de fichier de propriétés de servlet illustré par la Figure 10 a été nommé connectServlet.cfg et qu'il a été placé dans le répertoire de déploiement de Connect Servlet (par exemple, C:\WBIC\integration), vous devez définir le paramètre WBIC_FILENAME comme suit :

C:\WBIC\integration\connectServlet.cfg
 

Configuration de Wrapper Data Handler

Le composant Wrapper Data Handler convertit un document depuis son format sérialisé (que Connect Servlet a créé à partir du message HTTP) dans son objet métier correspondant. Lorsque Connect Servlet appelle une collaboration, il envoie à InterChange Server le format sérialisé du document que Business Integration Connect lui a envoyé. Cette demande de collaboration est reçue par WebSphere Server Access, qui réside dans InterChange Server. Comme l'indique la Figure 9, Server Access appelle le composant Wrapper Data Handler et lui transmet le document de Business Integration Connect. Le gestionnaire de données renvoie l'objet métier de données utiles correspondant.

Pour configurer Wrapper Data Handler, procédez comme suit :

Les étapes à suivre pour configurer Wrapper Data Handler sont décrites dans les sections suivantes. Pour obtenir des informations générales sur les gestionnaires de données, voir le document Data Handler Guide dans la documentation de WebSphere InterChange Server.

Indication de l'emplacement du composant Wrapper Data Handler

InterChange Server a besoin de connaître l'emplacement du composant Wrapper Data Handler pour pouvoir le charger au moment de l'exécution. Pour indiquer l'emplacement, procédez comme suit :

  1. Modifiez le script de démarrage ICS, start_server.bat, situé dans le sous-répertoire bin du répertoire produit d'InterChange Server (sur la machine où réside InterChange Server).
  2. Ajoutez le fichier jar du composant Wrapper Data Handler, bcgwbiwrapperdh.jar, à la liste des fichiers jar inclus au démarrage d'ICS. En règle générale, les fichiers jar du gestionnaire de données sont ajoutés à la variable DATAHANDLER dans le script de démarrage ICS.
    Remarque :
    Si vous avez installé le composant Attachment Data Handler en option, vous devez également ajouter son fichier jar au script de démarrage d'ICS. Pour plus d'informations, voir Spécification de l'emplacement du gestionnaire de données de pièces jointes.

Création d'objets métier de configuration pour Wrapper Data Handler

Pour identifier le gestionnaire de données à appeler, Server Access (dans InterChange Server) consulte le métaobjet du gestionnaire de données de niveau supérieur, MO_Server_DataHandler. Ce fichier est situé dans le sous-répertoire suivant du répertoire produit d'InterChange Server :

repository\edk
 

Ce métaobjet de niveau supérieur associe un type MIME à un métaobjet enfant, qui contient les informations de configuration du gestionnaire de données. Par conséquent, la création d'objets métier de configuration implique les étapes suivantes :

  1. Création du métaobjet enfant de Wrapper

    Vous devez initialiser un métaobjet enfant avec les informations de configuration du composant Wrapper Data Handler.

  2. Edition du métaobjet MO_Server_DataHandler

    Vous devez créer une entrée dans ce métaobjet qui associe un type MIME au nom du métaobjet enfant de Wrapper Data Handler.

Création du métaobjet enfant de Wrapper

Pour configurer Wrapper Data Handler, vous devez créer son métaobjet enfant et l'initialiser avec les informations de configuration. Le gestionnaire de données utilise les attributs de ce métaobjet pour obtenir ses informations de configuration, notamment le nom de la classe du gestionnaire de données à instancier. Pour créer ce métaobjet, vous devez créer une définition d'objet métier qui contient les attributs indiqués dans le Tableau 51.

Remarque :
Utilisez le composant Business Object Designer pour créer cette définition d'objet métier.

Tableau 51. Propriétés de configuration dans le métaobjet enfant de Wrapper
Attribut Description
ClassName

Nom de classe (obligatoire), qui désigne la classe du gestionnaire de données suivante :

com.ibm.bcg.integration.wbi.datahandlers.
 WBICWrapperDataHandler
 
TopBOPrefix Le préfixe permet de déterminer le nom de l'objet métier de niveau supérieur. Si l'objet métier de requête renvoyé par le gestionnaire de données configuré pour la requête ne possède pas le code wbic_mainboname dans ses informations relatives à l'objet métier spécifiques à l'application, le nom de l'objet de niveau supérieur est obtenu en ajoutant le préfixe TopBOPrefix au nom de l'objet métier de requête.
wbic_request_mime

Type MIME pris en charge par le gestionnaire de données que le Wrapper Data Handler appelle pour traiter les données utiles du message de requête. Assurez-vous que ce gestionnaire de données a été configuré pour être appelé par WebSphere InterChange Server Access. Pour plus d'informations, voir Edition du métaobjet MO_Server_DataHandler.

Remarque :
Si vos documents contiennent des pièces jointes, le type MIME de cette propriété de configuration doit être le même que celui qui appelle le composant Attachment Data Handler. Pour plus d'informations, voir Gestion des documents contenant des pièces jointes.
wbic_response_mime

Type MIME du gestionnaire de données que le Wrapper Data Handler appelle pour traiter les données utiles du message de réponse.

Remarque :
Vous n'avez pas besoin de définir le type MIME wbic_response_mime si Business Integration Connect n'attend pas de réponse.

Important:
Pour affecter une valeur aux attributs figurant dans le Tableau 51, définissez la valeur par défaut de l'attribut. Par exemple, si le composant Wrapper Data Handler doit utiliser le composant Delimited data handler pour son message de requête, affectez à la valeur par défaut de l'attribut wbic_request_mime la valeur text/delimited.

Vous pouvez définir un métaobjet enfant pour chaque instance du composant Wrapper Data Handler que vous devez utiliser. Par exemple, si vous devez prendre en charge uniquement un type MIME de requête ou une combinaison de types MIME de requête et de réponse, vous pouvez créer un seul métaobjet enfant et définir les valeurs par défaut des attributs wbic_request_mime et wbic_response_mime en conséquence. Toutefois, si vous devez prendre en charge différentes combinaisons de types MIME de requête et de réponse, vous pouvez créer un métaobjet enfant pour chaque combinaison prise en charge.

Business Integration Connect fournit le fichier référentiel InterChange Server suivant qui contient un exemple de métaobjet enfant pour le composant Wrapper Data Handler :

ProductDir/Integration/WBI/WICS/WBICServlet/MO_DataHandler_WBICWrapper.in
 

ProductDir est le répertoire d'installation de votre produit Business Integration Connect. Ce fichier référentiel définit une seule instance du composant Wrapper Data Handler qui est configurée pour appeler le composant Delimited Data Handler à la fois pour les objets métier de requête et de réponse. La Figure 11 illustre l'exemple de métaobjet enfant appelé MO_DataHandler_WBICWrapper.

Figure 11. Exemple de métaobjet enfant pour un composant Wrapper Data Handler


Si vous avez besoin de prendre en charge un document dont le message de requête était au format XML, vous devez créer un second métaobjet enfant pour représenter une seconde instance du composant Wrapper Data Handler. Dans ce métaobjet enfant, la valeur par défaut de l'attribut wbic_request_mime aurait le type MIME text/xml.

Edition du métaobjet MO_Server_DataHandler

WebSphere InterChange Server Access utilise un métaobjet de niveau supérieur appelé MO_Server_DataHandler afin d'associer les types MIME que les clients d'accès peuvent traiter aux gestionnaires de données qui assurent la prise en charge de ces types MIME. En particulier, ce métaobjet de niveau supérieur associe les types MIME aux métaobjets enfant du gestionnaire de données.

Le métaobjet MO_Server_DataHandler est une définition d'objet métier. Par conséquent, pour modifier ce métaobjet, recherchez l'objet MO_Server_DataHandler dans Business Object Designer et ajoutez-le à un nouvel attribut pour chaque instance prise en charge du Wrapper Data Handler. Chaque instance de ce gestionnaire de données est une combinaison unique de types MIME de requête et de réponse.

Vous apportez les modifications suivantes au métaobjet MO_Server_DataHandler :

Par exemple, supposez que vous disposez du Wrapper Data Handler tel qu'il est configuré dans la Figure 11. La Figure 12 représente le métaobjet MO_Server_DataHandler dont l'attribut associe le type MIME wbic_wrapper à l'instance de Wrapper Data Handler configurée par le métaobjet enfant MO_DataHandler_WBICWrapper. Ce métaobjet MO_Server_DataHandler associe également les types MIME de requête et de réponse (text/delimited) au métaobjet enfant du composant Delimited Data Handler.

Figure 12. Association du type MIME wbic_wrapper au composant Wrapper Data Handler


Pour chaque combinaison de type MIME de requête et de réponse que vous devez prendre en charge, répétez ce processus en ajoutant un attribut dans le métaobjet de niveau supérieur MO_Server_DataHandler dont le nom d'attribut est le type MIME associé à l'instance de Wrapper Data Handler et dont le type est le nom du métaobjet enfant associé. Assurez-vous également que les types MIME de requête et de réponse configurés (ainsi que leurs métaobjets enfant) existent dans le métaobjet MO_Server_DataHandler.

Remarque :
Si vous utilisez Attachment Data Handler pour traiter des pièces jointes dans vos documents Business Integration Connect, vous devez également modifier l'objet MO_Server_DataHandler afin de prendre en charge le composant Attachment Data Handler, comme décrit dans Configuration du gestionnaire de données de pièces jointes.

Création de définitions d'objet métier pour envoyer des documents

WebSphere Business Integration Connect Servlet envoie votre document à InterChange Server sous la forme d'un objet métier de données utiles. Pour Connect Servlet, l'objet métier de données utiles est représenté sous la forme d'une hiérarchie d'objets métier. Le composant Wrapper Data Handler crée cette hiérarchie d'objets métier lorsqu'il reçoit un document Business Integration Connect. Par conséquent, vous devez créer des définitions d'objet métier pour représenter cette hiérarchie.

Etant donné que Connect Servlet participe uniquement à la notification d'événements avec InterChange Server, les attributs de requête et de réponse de l'objet métier de niveau supérieur sont interprétés comme indiqué dans le Tableau 52.

Tableau 52. Objets métier de requête et de réponse dans la notification d'événements
Attribut Utilisation
objet métier de requête Contient le message de demande de Business Integration Connect ; ce message est l'événement qui déclenche la collaboration.
objet métier de réponse Contient le message de réponse, si l'interaction est synchrone.

Pour plus d'informations sur la création de cette structure d'objets métier, voir Création de définitions d'objet métier pour une version antérieure à ICS 4.2.2. sur HTTP.

Réception de documents à partir d'une version antérieure à ICS 4.2.2 via HTTP

Cette section explique comment recevoir des documents de Business Integration Connect depuis une version antérieure à InterChange Server 4.2.2 sur HTTP :

Le document que Business Integration Connect reçoit depuis InterChange Server a été déclenché par traitement des requêtes dans InterChange Server.

Composants requis pour la réception

Business Integration Connect peut recevoir des documents à partir des versions suivantes d'InterChange Server antérieures à la version 4.2.2 via le protocole de transfert HTTP :

Pour que Business Integration Connect reçoive un document depuis une version d'InterChange Server antérieure à 4.2.2 via le protocole HTTP, vous devez configurer ces deux composants. Tableau 45 résume ces étapes de configuration. Par ailleurs, pour qu'un document puisse être reçu depuis InterChange Server via le protocole HTTP, vous devez utiliser les composants compatibles ICS indiqués dans le Tableau 53.

Tableau 53. Composants requis pour recevoir des documents depuis une version antérieure à InterChange Server 4.2.2 via HTTP
Composant Description Remarques et limitations

le composant WebSphere Business Integration Adapter for XML.

(Adapter for XML)

Ce composant permet à InterChange Server d'échanger des objets métier avec des applications qui reçoivent des données sous la forme de messages HTTP. Le composant Adapter for XML et Business Integration Connect communiquent par le biais d'une adresse URL.

Le composant Adapter for XML n'est pas fourni avec Business Integration Connect. Vous devez utiliser la version 3.1.x ou une version ultérieure de cet adaptateur.

Remarque :
L'adaptateur peut uniquement être utilisé avec WebSphere InterChange Server version 4.2.2.
Gestionnaire de protocole HTTP ou HTTPS

Ce gestionnaire de protocole s'associe au composant Adapter for XML pour échanger des flux d'informations avec l'URL.

Ce gestionnaire de protocole est fourni avec Business Integration Connect. Pour plus d'informations, voir Déploiement du gestionnaire de protocole HTTP.
Un gestionnaire de données utiles Ce gestionnaire de données convertit les données utiles du document (généralement au format XML) en représentation d'objet métier. Ce gestionnaire de données est indispensable et doit prendre en charge le type MIME du document contenant les données utiles.
Attachment Data Handler Ce gestionnaire de données convertit les documents qui contiennent des pièces jointes depuis leur format de document en représentation d'objet métier. Ce gestionnaire de données est nécessaire uniquement si votre document contient des pièces jointes. Pour plus d'informations, voir Gestion des documents contenant des pièces jointes.

La Figure 13 illustre comment Business Integration Connect reçoit des documents à partir d'une version antérieure à InterChange Server 4.2.2 sur le protocole HTTP.

Remarque :
Toutes les références faites au gestionnaire de protocole HTTP sont également valables pour le gestionnaire de protocole HTTPS.

Figure 13. Flux de messages entre une collaboration et Business Integration Connect via HTTP


Les étapes suivantes expliquent comment Business Integration Connect participe au traitement des requêtes en recevant un document initialisé par une collaboration dans InterChange Server :

  1. La collaboration dans InterChange Server appelle le composant Adapter for XML, en lui envoyant un objet métier de niveau supérieur qui contient des objets enfant de requête et de réponse.

    L'objet enfant de requête contient des informations spécifiques à l'application qui désignent un métaobjet dynamique comprenant des en-têtes HTTP personnalisés, attendus par Business Integration Connect.

  2. Le composant Adapter for XML appelle le gestionnaire de protocole HTTP.
  3. Le gestionnaire de protocole HTTP utilise un gestionnaire de données pour convertir l'objet métier que la collaboration a envoyé dans un flux HTTP.

    Le gestionnaire de protocole lit le type MIME et l'URL à partir de l'objet métier afin de déterminer quel gestionnaire de données utiliser ainsi que l'adresse du destinataire.

  4. A partir de l'objet métier de niveau supérieur, le gestionnaire de protocole HTTP reçoit le premier objet métier contenant des données. Il s'agit de l'objet métier de requête.

    Le gestionnaire de protocole HTTP appelle le gestionnaire de données pour convertir l'objet métier en flux HTTP.

    Remarque :
    Si vos documents contiennent des pièces jointes, installez le composant Attachment Data Handler, puis configurez Adapter for XML afin qu'il convertisse l'objet métier en document contenant des pièces jointes. Pour plus d'informations, voir Gestion des documents contenant des pièces jointes.
  5. Le gestionnaire de protocole HTTP détermine le nom du métaobjet dynamique à partir de l'objet métier de requête.

    Le gestionnaire de protocole HTTP recherche les informations spécifiques à l'application relatives à l'objet métier de requête pour connaître le code cw_mo_conn, qui identifie l'attribut correspondant au métaobjet dynamique. Si vous utilisez le regroupement d'intégration dorsale pour vos documents, vous pouvez indiquer les informations d'en-tête HTTP personnalisé dans ce métaobjet dynamique.

  6. Le gestionnaire de protocole HTTP recherche le métaobjet dynamique correspondant à l'attribut HTTPProperties.

    Si cet attribut a une valeur, le gestionnaire de protocole définit les en-têtes de transfert dans le message de requête. Dans l'attribut HTTPProperties, vous pouvez également indiquer l'en-tête HTTP standard de type de contenu. Pour plus d'informations, voir Création d'informations d'en-tête de niveau de transfert HTTP pour ICS version 4.2.2.

  7. Le gestionnaire de protocole HTTP crée un flux HTTP à l'aide de la chaîne renvoyée par le gestionnaire de données. Il définit également les informations d'en-tête personnalisé, telles qu'elles sont définies dans le métaobjet dynamique.
  8. Le gestionnaire HTTP envoie le message de requête en tant que flux à l'URL indiqué.

    Business Integration Connect écoute sur cet URL, qui est configuré comme une cible.

  9. Business Integration Connect répond en renvoyant un message HTTP 200 OK.

    Si la propriété du connecteur ReturnBusObjResponse (du composant Adapter for XML) a la valeur "true", l'appel est synchrone. Le gestionnaire de protocole convertit le message de réponse en objet métier de réponse, puis le renvoie au composant Adapter for XML. Ce composant définit l'objet métier dans l'objet métier de niveau supérieur. L'objet métier de niveau supérieur est ensuite transmis à la collaboration dans InterChange Server.

Configuration de l'environnement requis pour HTTP avec une version antérieure à ICS 4.2.2

Etant donné que la réception de documents à partir d'InterChange Server nécessite l'utilisation de composants compatibles avec ICS, vous devez effectuer les tâches d'installation et de configuration décrites dans le Tableau 54. Pour plus d'informations sur la manière de configurer Business Integration Connect afin qu'il établisse la communication avec une version antérieure à InterChange Server 4.2.2 sur HTTP, voir Prise en charge des documents sortants.

Tableau 54. Configuration de l'environnement requis pour l'envoi de documents
Etape Pour plus d'informations

1. Déployer le gestionnaire de protocole HTTP.

Déploiement du gestionnaire de protocole HTTP

2. Configurer WebSphere Business Integration Adapter for XML.

Configuration d'Adapter for XML

Remarque :
Si vos documents contiennent des pièces jointes, vous devez également installer et configurer le composant Attachment Data Handler, comme décrit dans Gestion des documents contenant des pièces jointes.

Déploiement du gestionnaire de protocole HTTP

Business Integration Connect fournit un gestionnaire de protocole HTTP personnalisé pour l'échange de messages avec Business Integration Connect. Ce gestionnaire de protocole HTTP est situé sur le support d'installation de Business Integration Connect dans le fichier suivant :

Integration/WBI/WICS/WBICServlet/bcgwbiprotocol.jar
 

Ce gestionnaire de protocole personnalisé peut être connecté au composant Adapter for XML version 3.1.x ou supérieure. Consultez la liste des versions et plateformes InterChange Server prises en charge dans le document Adapter for XML User Guide pour connaître la version de l'adaptateur que vous utilisez.

Pour déployer le gestionnaire de protocole HTTP sur le composant Adapter for XML, vous devez permettre à ce composant d'obtenir l'emplacement du gestionnaire de protocole HTTP pour qu'il puisse le charger au moment de l'exécution. Pour indiquer l'emplacement du gestionnaire de protocole HTTP, procédez comme suit :

  1. Modifiez le script de démarrage du composant Adapter for XML, start_xml.bat, situé dans le sous-répertoire suivant du répertoire produit où les composant WebSphere Business Integration Adapter sont installés :
    connectors/xml
     
  2. Dans ce script de démarrage, ajoutez le fichier jar du gestionnaire de protocole HTTP personnalisé, bcgwbiprotocol.jar, à la liste des fichiers jar inclus dans la variable CLASSPATH du composant Adapter for XML.

Configuration d'Adapter for XML

Adapter for XML est un composant compatible avec ICS qui permet à Business Integration Connect d'échanger des documents avec InterChange Server sous la forme de messages HTTP. Il prend en charge l' interaction du traitement des requêtes avec InterChange Server comme suit :

Remarque :
L' de notification d'événements de ce composant n'est pas utilisée. Pour envoyer des messages HTTP depuis Business Integration Connect vers InterChange Server, utilisez le servlet WebSphere Business Integration Connect, comme décrit dans Envoi de documents à une version d'ICS antérieure à 4.2.2 via HTTP.
Important:
WebSphere Business Integration Connect n'intègre pas WebSphere Business Integration Adapter for XML. Vous devez vous procurer ce produit séparément et l'installer conformément aux instructions figurant dans le document Adapter for XML User Guide. Reportez-vous à la documentation relative à l'adaptateur pour vérifier que la version de l'adaptateur est compatible avec la version d'InterChange Server que vous utilisez.

Lorsque vous avez configuré Adapter for XML pour communiquer avec InterChange Server, suivez les étapes de ces sections afin de configurer cet adaptateur pour qu'il traite les messages HTTP envoyés par Business Integration Connect.

Spécification du gestionnaire de données utiles

Comme l'illustre la Figure 13, le gestionnaire de protocole du composant Adapter for XML utilise un gestionnaire de données pour convertir les objets métier reçus depuis InterChange Server dans les flux HTTP appropriés.

Remarque :
Le gestionnaire de données que le composant Adapter for HTTP appelle convertit les données utiles du document. Si votre document est encapsulé dans une enveloppe de transfert XML (il contient des pièces jointes ou l'Indicateur d'enveloppe a pour valeur Oui), configurez le composant Attachment Data Handler en tant que gestionnaire de données utiles. Pour plus d'informations, voir Gestion des documents contenant des pièces jointes.

Pour indiquer quel gestionnaire de données utiliser pour convertir les données utiles, vous devez procéder comme indiqué dans le Conversion d'objet métier. Par ailleurs, vous devez configurer le composant Adapter for XML pour utiliser ce gestionnaire de données utiles. Dans Connector Configurator, définissez la propriété de configuration du connecteur DataHandlerConfigMO pour spécifier le métaobjet du gestionnaire de données de niveau supérieur que le composant Adapter for XML utilise pour identifier les gestionnaires de données. Veillez à ajouter le nom du métaobjet du gestionnaire de données de niveau supérieur dans la liste des objets métier pris en charge pour l'adaptateur.

Configuration du nom des modules du gestionnaire de protocole

Le composant Adapter for XML utilise la propriété de configuration du connecteur JavaProtocolHandlerPkgs pour identifier le nom des modules du gestionnaire de protocole Java. Pour permettre l'intégration avec Business Integration Connect, assurez-vous que la propriété JavaProtocolHandlerPkgs a pour valeur le nom de module du gestionnaire de protocole HTTP fourni parBusiness Integration Connect :

com.ibm.bcg.integration.wbi.utils.protocolhandlers
 

Spécification de la prise en charge d'un objet métier de réponse

Le composant Adapter for XML utilise la propriété de configuration du connecteur ReturnBusObjResponse pour indiquer si un objet métier de réponse doit être renvoyé. Un objet métier de réponse est renvoyé uniquement si l'interaction est synchrone. Par défaut, la propriété de configuration du connecteur ReturnBusObjResponse a pour valeur false. Pour configurer le composant Adapter for XML pour qu'il renvoie un objet métier de réponse, affectez la valeur true à la propriété de configuration du connecteur ReturnBusObjResponse.

Remarque :
Si Business Integration Connect prend en charge les interactions synchrones pour le protocole métier et de regroupement utilisé par le Gestionnaire de communauté, affectez à la propriété de configuration du connecteur ReturnBusObjResponse la valeur true et associez l'objet métier de réponse dans votre objet métier de niveau supérieur.

Pour définir les propriétés de configuration d'un connecteur, vous devez utiliser l'outil Connector Configurator, livré avec la version de WebSphere Business Integration Adapter for XML. Dans Connector Configurator, la propriété ReturnBusObjResponse doit apparaître dans l'onglet spécifique à l'outil Connector des propriétés du connecteur.

Création de définitions d'objet métier pour la réception de documents

WebSphere Business Integration Adapter for XML reçoit les informations transmises depuis InterChange Server sous la forme d'un objet métier de données utiles. Pour Adapter for XML, l'objet métier de données utiles est représenté sous la forme d'une hiérarchie d'objets métier. Le composant Adapter for XML crée cette hiérarchie d'objets métier lorsqu'il reçoit un document de Business Integration Connect. Par conséquent, vous devez créer des définitions d'objet métier pour représenter cette hiérarchie.

Etant donné que le composant Adapter for XML participe uniquement au traitement des requêtes avec InterChange Server, les attributs de requête et de réponse de l'objet métier de niveau supérieur sont interprétés comme indiqué dans le Tableau 55.

Tableau 55. Objets métier de requête et de réponse dans le traitement des requêtes
Attribut Utilisation
objet métier de requête Contient les informations de requête transmises depuis InterChange Server ; le gestionnaire de protocole et le gestionnaire de données convertissent ces informations et les transmettent à l'URL sur laquelle Business Integration Connect est à l'écoute.
objet métier de réponse Contient les informations de réponse transmises depuis Business Integration Connect si l'interaction est synchrone.

Pour plus d'informations sur la création de cette structure d'objet métier, voir Création de définitions d'objet métier pour une version antérieure à ICS 4.2.2. sur HTTP.

Création de définitions d'objet métier pour une version antérieure à ICS 4.2.2. sur HTTP

Connect Servlet envoie votre document à InterChange Server sous la forme d'un objet métier de données utiles. Le composant Adapter for XML reçoit votre message à partir d'InterChange Server sous la même forme. Ces deux composants appellent le gestionnaire de données utiles pour gérer cet objet métier lorsqu'il reçoit ou envoie un document de Business Integration Connect, comme suit :

Par conséquent, vous devez créer des définitions d'objet métier comme illustré dans le Tableau 56 pour représenter la structure d'objet métier de données utiles que le composant Adapter for XML et Connect Servlet attendent.

Tableau 56. Définitions d'objet métier pour le protocole HTTP
Condition définition d'objet métier Pour plus d'informations
Si vous utilisez Aucun regroupement ou un Regroupement d'intégration dorsale pour votre document et si vos documents ne possèdent pas de pièces jointes

Hiérarchie des objets métier pour l'objet métier de données utiles :

  • objet métier de niveau supérieur
  • objet métier de requête
  • Objet métier de réponse (uniquement si une réponse est attendue)

Création de la structure d'objet métier de données utiles pour une version antérieure à ICS 4.2.2. sur HTTP
Si vous utilisez le regroupement d'intégration dorsale pour votre document

Ajoutez à l'objet métier de données utiles les objets métier destinés à contenir les informations d'en-tête de niveau de transfert :

  • métaobjet dynamique
  • objet métier Propriétés HTTP

Création d'informations d'en-tête de niveau de transfert HTTP pour une version d'InterChange Server antérieure à 4.2.2
Si document contient des pièces jointes (le regroupement d'intégration dorsale est requis) Vous devez également créer des objets métier supplémentaires pour représenter les pièces jointes. Création de définitions d'objets métier liées aux pièces jointes

Remarque :
Si vous définissez des objets métier pour les documents cXML, voir Création d'objets métier pour cXML.

Création de la structure d'objet métier de données utiles pour une version antérieure à ICS 4.2.2. sur HTTP

Le composant Wrapper Data Handler (pour l'envoi de documents) et Adapter for XML et le gestionnaire de protocole HTTP (pour la réception de documents) attendent la même structure d'objet métier pour l'objet métier de données utiles. Cette structure d'objet métier comprend les objets métier suivants :

La Figure 14 illustre un exemple de structure d'objet métier correspondant à la définition d'un objet métier de données utiles à utiliser avec une version d'InterChange Server antérieure à la version 4.2.2 via le protocole HTTP.

Remarque :
Pour obtenir une description détaillée de cette structure d'objet métier, voir le document Adapter for XML User Guide.

Figure 14. Structure d'objet métier pour l'objet métier de données utiles HTTP pour une version d'InterChange Server antérieure à la version 4.2.2


Objet métier de niveau supérieur

L'objet métier de niveau supérieur est un encapsuleur des objets métier de requête et de réponse. Vous devez créer une définition d'objet métier pour cet objet métier. Le Tableau 57 contient les attributs de cette définition d'objet métier de niveau supérieur.

Tableau 57. Attributs de l'objet métier de niveau supérieur
Attribut Type d'attribut Description
URL Chaîne

Destination des données dans l'objet métier.

Important:
Cet attribut n'est pas utilisé par le composant Wrapper Data Handler. En revanche, il est utilisé par le composant Adapter for XML.
MimeType Chaîne

Définit le type de contenu et le format des données qui sont transmises à l'URL.

Important:
Cet attribut n'est pas utilisé par le composant Wrapper Data Handler. En revanche, il est utilisé par le composant Adapter for XML.
BOPrefix Chaîne

Utilisé pour déterminer quel gestionnaire de données appeler.

Important:
Cet attribut n'est pas utilisé par le composant Wrapper Data Handler.
réponse objet métier Objet métier enfant qui représente le message de réponse (si vous attendez une réponse). L'objectif de cet objet métier dépend de sa participation ou non au traitement des requêtes ou à la notification des événements. Pour plus d'informations sur la structure de l'objet métier, voir Objet métier de réponse.
Request objet métier Objet métier enfant qui représente le message de requête. L'objectif de cet objet métier dépend de sa participation ou non au traitement des requêtes ou à la notification des événements. Pour plus d'informations sur la structure de l'objet métier, voir Objet métier de requête.

Remarque :
Si vous utilisez le composant Attachment Data Handler pour traiter des pièces jointes, vous devez modifier votre objet métier de requête pour qu'il contienne les pièces jointes, comme décrit dans Création de définitions d'objets métier liées aux pièces jointes.

Pour obtenir une description complète de la structure de l'objet métier de niveau supérieur, voir le document Adapter for XML User Guide.

Objet métier de requête

L'objet métier de requête contient les données à transmettre à l'URL. Il contient les attributs des différents codes XML utilisés dans le message de requête. L'objectif de cet objet métier de requête dépend de la tâche à laquelle InterChange Server participe, par exemple :

Remarque :
Cette structure d'objet métier identifie ses deux objets métier enfant comme des objets métier de requête et de réponse. Toutefois, cette structure est utilisée à la fois dans le traitement des requêtes et la notification d'événements.

Pour obtenir une description de la structure de l'objet métier de requête, voir Adapter for XML User Guide. Pour l'utiliser avec Business Integration Connect, vous devez effectuer deux personnalisations de la structure de la définition de l'objet métier de requête :


Tableau 58. Codes contenus dans les informations d'application sur l'objet métier de requête
Code des informations spécifiques à l'application Description Obligatoire ?
wbic_mainboname Donne le nom de l'objet métier de niveau supérieur Oui
cw_mo_conn Indique le métaobjet dynamique, qui contient les zones d'en-tête de niveau de transfert HTTP. Pour plus d'informations, voir Création d'informations d'en-tête de niveau de transfert HTTP pour une version d'InterChange Server antérieure à 4.2.2. Non (uniquement si vous utilisez le regroupement d'intégration dorsale)

Objet métier de réponse

L'objet métier de réponse contient les données à recevoir depuis l'URL. Il contient les attributs des différents codes XML utilisés dans le message de réponse. L'objectif de cet objet métier de réponse dépend de la tâche à laquelle InterChange Server participe, par exemple :

Que la réponse ait lieu dans le cadre du traitement des requêtes ou de la notification d'événements, un objet métier de réponse est envoyé uniquement si l'échange entre Business Integration Connect et InterChange Serverest synchrone et qu'un objet métier est attendu en réponse à la requête. Si tel est le cas, vous devez procéder comme suit :

Remarque :
L'objet métier de réponse ne contient pas d'attribut correspondant au métaobjet dynamique.

Si l'échange entre Business Integration Connect et InterChange Server est asynchrone, Business Integration Connect n'attend pas de réponse, vous n'avez donc pas besoin de créer un objet métier de réponse.

Création d'objets métier pour cXML

Pour les documents cXML, vous pouvez utiliser l'outil XML Object Discovery Agent (ODA) afin de créer les objets métier. L'outil XML ODA peut utiliser les DTD cXML. Notez toutefois que l'outil XML ODA ne prend pas en charge la variable ENTITY. Par conséquent, avant d'exécuter les DTD cXML avec l'outil XML ODA, vous devez supprimer la variable ENTITY de la DTD.

Lorsque vous créez des objets métier à l'aide de l'outil XML ODA, vous pouvez sélectionner le code cXML comme élément racine. Cela peut conduire à la création d'un objet métier de grande taille, en capturant cependant l'ensemble de la DTD cXML. Si vous voulez créer un objet métier plus petit, vous pouvez sélectionner un code différent comme élément racine, ce qui nécessitera de créer un gestionnaire de nom personnalisé pour le composant Data Handler for XML. Le gestionnaire de données appellera ce gestionnaire de nom pour effectuer la conversion du nom de l'objet métier de niveau supérieur. Pour plus d'informations sur la création de gestionnaires de noms personnalisés, voir la documentation de Data Handler for XML.

Création d'informations d'en-tête de niveau de transfert HTTP pour une version d'InterChange Server antérieure à 4.2.2

Si vous envoyez des documents avec le regroupement d'intégration dorsale sur le protocole de transfert HTTP, votre objet métier de requête doit contenir des informations d'en-tête de niveau de transfert personnalisées. Les composants Wrapper Data Handler et Adapter for XML s'attendent à trouver ces informations d'en-tête personnalisé sous la forme d'un métaobjet dynamique.

La Figure 15 illustre la structure de l'objet métier définie pour un objet métier de requête qui représente un document Business Integration Connect utilisant le regroupement d'intégration dorsale via le protocole HTTP.

Figure 15. Relation entre l'objet métier de requête et le métaobjet dynamique HTTP


Assurez-vous que la structure de l'objet métier contient un métaobjet en procédant comme suit :

  1. Créez une définition d'objet métier destinée à contenir les propriétés HTTP requises par le regroupement d'intégration dorsale.
  2. Créez une définition d'objet métier pour l'objet métier dynamique.
  3. Modifiez la définition de l'objet métier de requête afin d'inclure un attribut pour le métaobjet dynamique.

Chaque étape est décrite dans les sections ci-dessous.

Création de l'objet métier Propriétés HTTP

Un objet métier Propriétés HTTP contient les propriétés HTTP requises par le regroupement d'intégration dorsale. Il peut également contenir l'attribut Content-Type, qui spécifie l'en-tête du type de contenu à définir dans le message de requête ainsi que l'attribut de longueur du contenu qui détermine la longueur du message, en octets. Le Tableau 4 décrit chaque zone valide de l'en-tête de transfert.

Pour créer une définition d'objet métier Propriétés HTTP, procédez comme suit :

  1. Créez un attribut au sein de la définition de l'objet métier pour chaque zone d'en-tête de transfert.

    Tous les attributs doivent comporter un type d'attribut Chaîne. Vous pouvez affecter à l'attribut le même nom que la propriété HTTP (comme indiqué dans la colonne de la zone En-tête du Tableau 4).

    Remarque :
    La seule exception à la définition des noms de propriété HTTP est que la zone du type de contenu doit comporter un attribut nommé Content_Type.
  2. Pour chacun des attributs contenus dans l'objet métier Propriétés HTTP, ajoutez les informations spécifiques à l'application qui permettent d'identifier l'objectif de l'attribut associé.

    Ces informations spécifiques à l'application au niveau de l'attribut ont le format suivant :

    name=HTTPproperty
     

    HTTPproperty est l'une des valeurs contenues dans la colonne zone En-tête du Tableau 4.

Dans la Figure 15, la définition de l'objet métier HttpProps_BusObj contient des attributs pour les différentes zones d'en-tête de transfert. Ces attributs possèdent tous des informations spécifiques à l'application au niveau des attributs afin de spécifier le nom de l'en-tête du protocole associé. Par exemple, les informations spécifiques à l'application de l'attribut x-aux-sender-id sont définies comme suit :

name=x-aux-sender-id
 

Création du métaobjet dynamique HTTP

Le métaobjet dynamique contient un objet métier enfant associé à des informations de configuration pour les informations d'en-tête HTTP. Assurez-vous que la structure de l'objet métier contient un métaobjet dynamique. La définition de l'objet métier pour le métaobjet dynamique doit inclure un attribut nommé HttpProperties, dont le type est la définition d'objet métier pour l'objet métier Propriétés HTTP (voir Création de l'objet métier Propriétés HTTP).

Par exemple, dans la Figure 15, la définition de l'objet métier HttpDynMO_BusObj contient l'attribut HttpProperties, de type HttpProps_BusObj.

Modification de la définition de l'objet métier de requête

La définition de l'objet métier de requête représente les informations demandées auprès de Business Integration Connect. Pour plus d'informations sur la création d'un objet métier de requête, voir Objet métier de requête. Pour intégrer le métaobjet dynamique à votre structure d'objet métier de données utiles, vous devez effectuer les modifications suivantes dans la définition d'objet métier de requête :

  1. Ajoutez un attribut à votre définition d'objet métier de requête afin qu'il contienne le métaobjet enfant dynamique.

    Le type de cet attribut correspond à la définition d'objet métier du métaobjet dynamique (voir Création du métaobjet dynamique HTTP).

  2. Ajoutez le code cw_mo_conn aux informations spécifiques à l'application au niveau de l'objet métier de votre définition d'objet métier afin d'identifier l'attribut qui contient le métaobjet dynamique.

    Le code cw_mo_conn a le format suivant :

    cw_mo_conn=dynamicMetaObjAttr
     

    dynamicMetaObjAttr est le nom de l'attribut dans l'objet métier de requête qui contient le métaobjet dynamique.

Par exemple, dans la Figure 15, un attribut nommé HttpDynMO a été ajouté à la définition d'objet métier de requête, WBIC_HttpRequest_BusObj. Cet attribut contient le métaobjet dynamique, qui est un objet métier enfant du type HttpDynMO_BusObj. Par ailleurs, les informations spécifiques à l'application de l'objet métier de requête ont été modifiées pour inclure le code cw_mo_conn suivant afin d'identifier ce métaobjet dynamique :

cw_mo_conn=HttpDynMO
 

Création d'artefacts ICS antérieurs à la version 4.2.2 pour HTTP

Pour configurer un InterChange Server antérieur à la version 4.2.2 pour qu'il communique avec Business Integration Connect via le protocole HTTP, vous devez créer les artefacts InterChange Server indiqués dans le Tableau 59.

Tableau 59. Artefacts pour la communication avec une version d'ICS antérieure à 4.2.2 via le protocole HTTP
Artefact ICS Fonction Pour plus d'informations
Définitions d'objet métier Représentent le document Création de définitions d'objet métier pour une version antérieure à ICS 4.2.2. sur HTTP
Objet de connecteur (requis uniquement pour le traitement des requêtes) Représentent le composant Adapter for XML au moment de l'exécution Création de l'objet de connecteur XML
Modèle de collaboration et objet de collaboration Représente le processus métier qu'InterChange Server utilise pour traiter le document Liaison de collaborations pour communiquer avec Adapter for XML

Création de l'objet de connecteur XML

Pour prendre en charge le traitement des requêtes à l'aide d'une version d'InterChange Server antérieure à 4.2.2 via le protocole HTTP, utilisez le composant Adapter for XML pour envoyer un document à InterChange Server. Pour obtenir une instance du composant Adapter for XML au moment de l'exécution, exécutez la procédure suivante dans l'outil System Manager :

  1. Créez les objets de connecteur :
  2. Configurez les objets de connecteur.

    Pour plus d'informations sur la manière de configurer l'objet de connecteur du composant Adapter for XML afin de l'utiliser avec Business Integration Connect, voir Configuration d'Adapter for XML.

Liaison de collaborations pour communiquer avec Adapter for XML

Comme décrit dans Création des collaborations, un objet de collaboration doit exister au moment de l'exécution pour qu'InterChange Server puisse savoir où recevoir et envoyer des objets métier. Lorsque vous créez l'objet de collaboration pour la collaboration qui envoie des informations à Business Integration Connect, vous devez lier ses ports. Pour le traitement des requêtes , vous devez affecter au port de collaboration "cible", qui utilise Adapter for XML pour envoyer des requêtes à Business Integration Connect, l'objet de connecteur que vous avez créé pour le composant Adapter for XMP ; à savoir, l'adaptateur de destination.

Copyright IBM Corp. 1997, 2004