Fonctionnement du connecteur

Les sections suivantes décrivent la façon dont le connecteur traite les requêtes d'objets métier et gère les notifications d'événements.

Comportement des métadonnées du connecteur

Le connecteur est contrôlé par les métadonnées. Il est conçu pour gérer l'extraction et l'envoi de tous les objets métier, quel que soit leur type ou les variables qu'ils comportent. Pour que le connecteur soit contrôlé par les métadonnées, les objets métier destinés à Portal Infranet doivent contenir les informations suivantes :

Pour plus d'informations sur les métadonnées d'objets métier pour Portal, voir Présentation des objets métier.

Traitement des objets métier

Lorsque le connecteur reçoit une requête d'objet métier du système WebSphere Business Integration, le gestionnaire d'objets métier du connecteur traite l'objet métier. Le gestionnaire d'objet métier assure la liaison entre l'objet spécifique à l'application et l'interface de programme d'application Portal Infranet. Il est chargé de transmettre une opération Portal Infranet à l'interface de programme d'application et de créer un objet métier spécifique à l'application transmis au système WebSphere Business Integration en tant que résultat d'un événement Infranet. Le gestionnaire d'objets métier utilise les données de l'objet métier et tout type de métadonnées pour appeler l'interface de programme d'application Java Infranet afin d'envoyer un objet stockable vers Portal. Une fois cette opération terminée, un statut est renvoyé vers le courtier d'intégration.

Dans la figure 2, l'organigramme de traitement de l'information illustre à un niveau élevé la façon dont le gestionnaire d'objets métier traite les requêtes d'objets métier. Le gestionnaire d'objets métier extrait l'instruction et les attributs clé depuis l'objet métier. Il utilise l'instruction pour déterminer l'appel de fonction effectué pour gérer l'objet métier. Dans cet exemple, s'il s'agissait d'une instruction Update, la fonction UpdateObject serait appelée.

Figure 2. Vue d'ensemble du traitement des objets métier
Vue d'ensemble du traitement des objets métier

Traitement de l'instruction Retrieve

La méthode Retrieve du gestionnaire d'objets métier extrait un objet de Portal Infranet et alimente un objet métier de WebSphere Business Integration Adapter avec les informations de l'application. La méthode Retrieve du connecteur effectue les opérations suivantes :

  1. Elle vérifie si la connexion de Portal Infranet est valide. Si tel n'est pas le cas, la connexion doit être rétablie. Si la connexion est rompue en cours de traitement, le connecteur renvoie un statut BON_FAIL indiquant un problème de connexion avec Infranet.
  2. Elle extrait les informations spécifiques à l'application pour l'objet. Les informations spécifiques à l'application indiquées pour une instruction fournissent le code opération qui doit être appelé pour extraire un objet Portal Infranet.
  3. Elle prépare la flist destinée au code opération basé sur les informations spécifiques à l'application pour l'objet métier et ses attributs.
    Remarque :
    Une flist est une liste de longueur variable qui contient des paires de zones et de valeurs.Les flists fournissent des paramètres d'entrée et de sortie aux codes opération et aux fonctions Infranet.
  4. Elle appelle le code opération spécifique avec la flist en entrée et une flist vide en sortie.
  5. Si les étapes précédentes se déroulent normalement, la structure de la flist renvoyée contient un objet flist intégralement rempli qui correspond à l'objet stockable défini par un objet métier WebSphere Business Integration Adapter. Etant donné que la flist a une correspondance un à un avec l'objet métier WebSphere Business Integration Adapter, elle est parcourue de façon à extraire tous les attributs de l'objet métier WebSphere Business Integration Adapter basés sur les informations spécifiques à l'application au niveau de l'attribut qui identifie le nom et le type de zone de cette flist.
  6. Elle alimente l'objet métier et le transmet au courtier d'intégration.

La figure 3 illustre le fonctionnement de la méthode Retrieve. La méthode détermine l'action à entreprendre sur un attribut, en fonction de son type. S'il s'agit d'un attribut de type basique (tel qu'une chaîne), le gestionnaire d'objets métier alimente la zone de façon dynamique. Si la méthode détecte un objet métier enfant, elle analyse l'objet en profondeur jusqu'à atteindre les attributs de base de cet objet métier enfant. Ensuite, elle passe en revue tous les attributs de base de l'objet enfant avant de procéder de même avec ceux de l'objet parent.

Figure 3. Organigramme pour le traitement de l'instruction Retrieve
Organigramme pour le traitement de l'instruction Retrieve

Traitement des instructions Create et Update

Pour traiter une instruction Create ou Update, le gestionnaire d'objets métier construit un objet d'interface de programme d'application Infranet (une flist) et le transmet à l'interface de programme d'application. Le gestionnaire d'objets métier suit les étapes suivantes :

  1. Elle extrait l'objet métier spécifique à l'application de l'objet métier WebSphere Business Integration Adapter.
  2. Elle alimente l'objet métier de l'interface de programme d'application Portal Infranet. Lorsque la flist est instanciée, le connecteur effectue une itération dans l'objet, attribut par attribut, puis identifie les valeurs avec lesquelles alimenter cette flist. Ce processus doit effectuer une recherche dans un objet pour détecter un attribut susceptible de se trouver à l'intérieur des différentes couches qui composent cet objet.
  3. Elle vérifie que la connexion Portal Infranet est toujours valide. Si la connexion est interrompue lors du traitement, le connecteur renvoie un statut BON_FAIL, lequel signale un problème de connexion avec Infranet, et la connexion doit être réinstanciée.
  4. Elle utilise les informations spécifiques à l'application pour l'instruction de l'objet métier afin d'appeler le code opération approprié de façon dynamique pour l'opération Create ou Update. Une fois que les paramètres sont rassemblés et placés dans un tableau et que la chaîne fonctionnelle a été assemblée, la fonction de contexte dotée du code opération adéquat est appelée.
  5. Pour traiter des objets métier enfants qui disposent de leur propre code opération, le gestionnaire d'objets métier alimente une flist séparée pour chaque enfant, puis appelle le code opération approprié.
  6. Elle renvoie un statut lorsque l'opération est terminée.

Notification d'événement

Infranet dispose d'un mécanisme de notification d'événements qui permet d'assurer le suivi des actions qui se déroulent dans l'application. Lorsqu'un utilisateur réalise une action dans Infranet, l'application génère un événement associé.

Le module d'événements WebSphere Business Integration Adapter examine l'événement et détermine s'il est susceptible d'intéresser le connecteur. Si tel est le cas, le module d'événements génère une entrée dans la table d'événements WebSphere Business Integration Adapter correspondant à l'événement.

Détection d'événements dans Infranet

La détection d'événements dans Infranet est implémentée à l'aide d'un module de fonctions Infranet personnalisées appelé par le mécanisme de notification des événements. Ce module de fonctions est fourni par le courtier d'intégration et fonctionne avec deux fichiers de configuration pour identifier les événements Infranet et écrire des événements dans la table d'événements WebSphere Business Integration Adapter.

Lorsqu'un objet Infranet est modifié, un événement permanent est mis en avant. Infranet peut être configuré de façon à appeler un code opération spécifique lorsqu'un événement survient ; ainsi, le courtier d'intégration fournit un fichier de configuration plat qui configure Infranet de façon qu'il appelle le module de fonctions des événements WebSphere Business Integration Adapter pour les événements associés aux objets métier pour Portal. Ce fichier de configuration est appelé "pin_notify_cw" et est chargé dans Infranet à l'aide de l'utilitaire load_pin_notify fourni avec Infranet.

Lorsque le module d'événements reçoit un événement, il extrait les informations de l'objet lié à ce dernier et crée une entrée dans le tableau d'événements WebSphere Business Integration Adapter. Dans Infranet, un événement est en fait une instance de classe stockable Infranet et chaque événement de création, modification, ou suppression se rapporte à une classe stockable Infranet spécifique. Par exemple, si un utilisateur modifie un contact particulier en relation avec un client, Infranet génère une instance de la classe stockable /event/customer/nameinfo.

Le module d'événements utilise son propre fichier de configuration pour déterminer l'événement qui est survenu, identifier la partie de la classe stockable ayant été modifiée (et l'objet métier qui s'y rapporte), puis déterminer le type d'action qui s'est produit. A l'aide du fichier de configuration event_code.txt, le module d'événements examine l'événement Infranet et alimente la table d'événements WebSphere Business Integration Adapter avec un enregistrement qui reflète cet événement.

Le mécanisme de notification d'événements du connecteur utilise trois tables créées dans une instance de base de données Oracle par Infranet.

Le schéma de la première table indique les informations enregistrées pour chaque événement envoyé par Infranet qui intéresse le connecteur. Sa présentation est aussi utilisée pour la table d'archivage.

La détection des événements et le traitement associé s'effectuent dans une transaction Infranet. Infranet appelle les processus personnalisés dans une transaction et attend les résultats du traitement. Si le processus personnalisé renvoie une erreur, la transaction est abandonnée. Ceci permet de garantir qu'aucun événement ne soit perdu par le connecteur.

Remarque :

Problèmes connus - Le module de notification d'événements vérifie l'ID utilisateur de tous les événements Portal envoyés définis dans le fichier pin_notify_cw. Si aucun PIN_FLD_USERID n'est associé à l'événement envoyé au module, une erreur sera générée et des problèmes se produiront lors de la sauvegarde de l'objet en ligne. Ces types d'événements doivent être ajustés à l'aide de FLists ou de classes stockables afin d'inclure un tel ID. Recherchez ces erreurs dans le fichier journal défini dans le fichier de configuration crossworlds.cnf.

Le module d'événements recherche un ID utilisateur pour empêcher que les événements envoyés dans l'application par le connecteur soient ajoutés à la file d'attente d'événements. Cette procédure est appelée "travail en alternance".

"/event/customer/billinfo" est un type d'événement dans lequel un tel problème existe.

Extraction des événements

Le connecteur recherche des événements potentiels en interrogeant la table XWORLDS_Events qui a été définie dans l'instance de base de données Infranet. Le connecteur effectue l'interrogation en utilisant une instruction SQL SELECT pour extraire les entrées de la table XWORLDS_Events. Le nombre d'événements sélectionnés est indiqué par la propriété PollQuantity du connecteur.

L'interrogation s'effectue dans le connecteur à l'aide de la méthode pollForEvents().Le connecteur interroge la table d'événements en fonction de la propriété PollFrequency définie dans les propriétés du connecteur WebSphere Business Integration Adapter. Si une nouvelle ligne est détectée dans la table, les données de l'événement sont extraites, puis le connecteur traite l'événement de la façon suivante :

  1. La fonction d'interrogation crée un objet métier vide, définit l'instruction sur Retrieve, puis configure les clés à l'aide de l'enregistrement de l'événement. L'objet métier est envoyé au gestionnaire d'objets métier du connecteur'.
  2. Le gestionnaire d'objets métier utilise les données de l'événement pour appeler l'interface de programme d'application Java Infranet pour extraire l'objet stockable Portal Infranet.
  3. Le gestionnaire d'objets métier convertit l'objet stockable en objet métier WebSphere Business Integration Adapter spécifique à une application, définit l'instruction sur l'action indiquée par l'enregistrement de l'événement, puis transmet l'objet métier au courtier d'intégration.

Une fois que l'objet métier est transmis au système WebSphere Business Integration, la table d'événements est archivée dans la table XWORLDS_Archive_Events et supprimée dans la table d'événements.

L'intervalle de temps selon lequel la méthode d'interrogation est appelée peut être ajusté en modifiant la propriété PollFrequency du connecteur. Cette propriété est définie en utilisant le courtier d'intégration.

Connexion à l'application Infranet

Lors de la connexion au gestionnaire de connexions Portal Infranet à l'aide de l'interface de programme d'application, le connecteur effectue les opérations suivantes :

  1. Il crée une instance de contexte Portal Infranet.
  2. Lorsqu'un code opération doit être exécuté, le connecteur utilise un contexte du groupe disponible et l'ajoute au groupe utilisé.
  3. Lorsque la tâche est terminée, le contexte est renvoyé vers le groupe disponible.

L'instruction Connect utilise les valeurs des propriétés de connecteur spécifiques à l'application qui sont définies dans le référentiel.

Les instances du contexte situées dans le groupe sont fermées lorsque le connecteur est clos.

Traitement des données dépendantes des paramètres régionaux

Le connecteur a été internationalisé, il peut prendre en charge les jeux de caractères à deux octets et transmettre le texte du message dans la langue indiquée. Lorsque le connecteur transfère des données depuis un emplacement qui utilise un jeu de codes de caractères spécifique vers un emplacement qui utilise un jeu de codes de caractères différent, il procède à la conversion des caractères afin de conserver le sens des informations. L'environnement d'exécution Java de la machine virtuelle Java (JVM) représente les données dans le jeu de codes de caractères Unicode. Le format Unicode contient des codes pour les caractères présents dans la plupart des jeux de codes de caractères connus (à la fois mono-octet et multi-octets). La plupart des composants du système IBM CrossWorlds sont écrits en Java. Par conséquent, lorsque des données sont transférées entre la plupart des composants IBM CrossWorlds, la conversion des caractères est inutile. Pour enregistrer les messages d'erreur et d'informations dans la langue et le pays ou territoire approprié, configurez la propriété standard de configuration de paramètres régionaux pour votre environnement. Pour plus d'informations sur ces propriétés, voir l'Annexe A. Propriétés standard du connecteur.

Copyright IBM Corp. 2003, 2005