Une définition de flot de documents se compose, au minimum, d'un regroupement, d'un protocole et d'un flot de documents. Les définitions de flots de documents précisent les types de documents qui seront traités par WebSphere Partner Gateway.
Le regroupement est la logique requise pour regrouper un document en fonction d'une spécification, par exemple AS2. Un flot de protocole est la logique exigée pour traiter un document adhérant à un certain protocole, tel que EDI-X12. Un flot de documents décrit l'aspect du document.
Les sections suivantes décrivent rapidement les étapes de définition d'un flot de documents entre le Gestionnaire de communauté et un participant. Elles décrivent également les points où vous pouvez définir des attributs.
Avant de pouvoir envoyer ou recevoir un document, vous devez procéder à la définition du flot de documents auquel il sera lié. WebSphere Partner Gateway propose plusieurs définitions de flots de documents, dont une qui représente des accusés de réception fonctionnels. Lorsque vous importez des mappes de transformation pour des transactions EDI ou des documents XML ou ROD, les définitions de documents associées apparaissent sur la page des définitions de flot de documents. De la même façon, si vous importez une mappe d'accusé de réception fonctionnel qui n'est pas encore définie, sa définition de flot de documents s'affiche sur la page. Vous pouvez créer vos propres définitions de flots de documents.
Lors de la définition d'un flot de documents, vous pouvez modifier certains attributs. Les attributs servent à diverses fonctions de traitement de document et de routage, comme la validation, la vérification pour chiffrement et le nombre de relances. Ils permettent un paramétrage global du regroupement, protocole ou flot de documents associé. Les attributs disponibles varient selon la définition du flot de documents. Les attributs des définitions de flots de documents EDI sont différents de ceux des définitions de flots de documents RosettaNet.
Par exemple, si vous spécifiez une valeur pour Autoriser une requête TA1 au niveau du flot de documents ISA, elle s'applique à tous les documents ISA. Si par la suite vous définissez l'attribut Autoriser une requête TA1 au niveau des capacités B2B pour un participant ou le Gestionnaire de communauté, cette valeur supplante celle qui était indiquée au niveau de la définition de flot de documents.
Pour les attributs qui peuvent être définis à plusieurs niveaux de la définition du flot de documents, les valeurs définies au niveau du flot de document prévalent sur celles définies au niveau du protocole, et ces dernières sont prioritaires sur celles paramétrées au niveau du regroupement. Par exemple, si vous précisez un profil d'enveloppe au niveau du protocole &X44TA1 mais que vous précisez un profil d'enveloppe différent au niveau du flot de documents TA1, c'est ce dernier qui est utilisé.
Le flot de documents doit figurer sur la page Gérer des définitions de flots de documents pour que vous puissiez créer des interactions.
Ensuite, vous définissez les interactions, qui sont des modèles pour créer les connexions des participants. Les interactions décrivent comment arrive le document, les traitements qu'il subit et comment il est envoyé depuis le concentrateur.
Pour certains protocoles, deux flots suffisent : un pour décrire le document reçu dans le concentrateur (de la part du participant ou du Gestionnaire de communauté) et un qui décrit le document envoyé depuis le concentrateur (au participant ou au Gestionnaire de communauté). Toutefois, si le concentrateur envoie ou reçoit un EDI qui sera désenveloppé en transactions individuelles, ou pour lequel des accusés de réception sont requis, vous créerez plusieurs interactions. Par exemple, si vous recevez un EDI dans le le concentrateur, vous aurez une interaction qui décrira comment l'EDI est envoyé au concentrateur et comment il y est traité. Vous aurez également une interaction pour chaque transaction du concentrateur, qui décrit le traitement de la transaction. Pour les EDI qui quittent le concentrateur, vous aurez une interaction qui décrit comment l'enveloppe est envoyée au destinataire.
Ensuite, créez les profils des participants pour le Gestionnaire de communauté et les participants. Définissez des passerelles (qui déterminent quels documents seront envoyés) et les capacités B2B qui identifient les documents que le Gestionnaire de communauté ou un participant peuvent envoyer et recevoir. La page Capacités B2B répertorie tous les flots de documents définis.
Vous pouvez définir des attributs au niveau des capacités B2B. Tout attribut défini à ce niveau a la précédence sur ceux qui ont été définis au niveau de la définition du flot de documents. Par exemple, si vous définissez Autoriser une requête TA1 sur Non au niveau de la définition du flot de documents pour les documents ISA, puis sur Oui au niveau des capacités B2B, la valeur Oui est utilisée. Le fait de définir un attribut au niveau B2B vous permet de le personnaliser pour un participant donné.
Si vous définissez le profil d'enveloppe au niveau du protocole ou du flot de documents (sur la page Gérer des définitions de flots de documents) puis sur une valeur différente sur la page des capacités B2B, c'est cette dernière valeur qui est utilisée.
Vous devez définir les profils et capacités B2B du Gestionnaire de communauté et des participants avant de pouvoir créer des connexions entre eux.
Enfin, activez les connexions entre le Gestionnaire de communauté et les participants. Les connexions disponibles dépendent des capacités B2B des participants et des interactions que vous avez créées. Ces dernières dépendent de la disponibilité des définitions de flots de documents.
Pour certains échanges, une seule connexion est requise. Par exemple, c'est le cas si un participant envoie un document binaire à une application dorsale du Gestionnaire de communauté. Toutefois, dans le cadre des échanges EDI pour lesquels l'EDI est désenveloppé et les transactions individuelles transformées, plusieurs connexions sont définies.
Vous pouvez définir des attributs au niveau de la connexion. Tout attribut défini à ce niveau a le pas sur ceux qui ont été définis au niveau des attributs B2B. Par exemple, si vous définissez Autoriser une requête TA1 sur Oui au niveau des capacité B2B, puis sur Non au niveau de la connexion, la valeur Non est utilisée. Le fait de définir la valeur d'un attribut au niveau de la connexion permet de le personnaliser selon les besoins en routage des participants et applications impliqués.