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:
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 :
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.
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.
La Figure 9 illustre comment Business Integration Connect envoie des documents à une version d'ICS antérieure à 4.2.2 sur le protocole HTTP.
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:
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 :
Business Integration Connect envoie le document à l'adresse URL désignée comme passerelle cible.
Le message de requête HTTP est constitué de deux parties :
Chaque URL correspond à une collaboration à appeler (pour plus d'informations, voir Configuration de Connect Servlet).
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.
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.
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.
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.
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.
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.
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
La configuration de Connect Servlet nécessite les étapes suivantes :
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
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 :
Ces fichiers se situent dans le sous-répertoire lib du répertoire produit d'InterChange Server.
Remarques:
Ces fichiers sont disponibles sur le support d'installation de Business Integration Connect, dans le répertoire suivant :
integration/wbi/wics/http/lib/thirdparty
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 :
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 :
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.
| 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 |
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 :
Elle indique un nombre entier d'URL configurés dans ce fichier :
Les propriétés de collaboration associées ont des noms de propriété de la forme WBIC_URL_count_propertyName. Le Tableau 50 définit un exemple de ces propriétés WBIC_URL_count_propertyName. Dans la colonne Exemple, ce tableau contient des exemples de valeurs des propriétés WBIC_URL_count_propertyName pour la première adresse URL de collaboration (count équivaut à 1).
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 :
| 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 |
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 :
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
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.
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
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.
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 :
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 :
Vous devez initialiser un métaobjet enfant avec les informations de configuration du composant Wrapper Data Handler.
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.
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.
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.
|
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.
|
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
où 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.
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 :
Le type de cet attribut est la définition de l'objet métier pour le métaobjet enfant du composant Wrapper Data Handler (voir Création du métaobjet enfant de Wrapper).
Le type de ces attributs serait le métaobjet enfant du gestionnaire de données associé.
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.
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
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.
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.
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.
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.
|
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.
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 :
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.
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.
Le gestionnaire de protocole HTTP appelle le gestionnaire de données pour convertir l'objet métier en flux HTTP.
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.
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.
Business Integration Connect écoute sur cet URL, qui est configuré comme une cible.
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.
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 |
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 :
connectors/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 :
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.
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.
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.
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
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.
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.
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
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.
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 :
| 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 :
| 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 |
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.
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.
|
MimeType | Chaîne |
Définit le type de contenu et le format des données qui sont transmises à l'URL.
|
BOPrefix | Chaîne |
Utilisé pour déterminer quel gestionnaire de données appeler.
|
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. |
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.
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 :
Pour plus d'informations, voir Création de définitions d'objet métier pour envoyer des documents.
Pour plus d'informations, voir Création de définitions d'objet métier pour la réception de documents.
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 :
Cet attribut contient des informations de configuration pour les en-têtes du message. 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.
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) |
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 :
La syntaxe de ce code est la suivante :
wbic_type=reply
Si ce code n'est pas indiqué, le composant Wrapper Data Handler utilise le métaobjet enfant indiqué par l'attribut wbic_response_mime (dans l'objet métier de niveau supérieur) afin de déterminer le gestionnaire de données à utiliser pour la réponse.
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.
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.
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 :
Chaque étape est décrite dans les sections ci-dessous.
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 :
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).
Ces informations spécifiques à l'application au niveau de l'attribut ont le format suivant :
name=HTTPproperty
où 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
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.
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 :
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).
Le code cw_mo_conn a le format suivant :
cw_mo_conn=dynamicMetaObjAttr
où 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
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.
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 |
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 :
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.
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.