Cette section explique comment les métadonnées améliorent la souplesse du connecteur et décrit en détail le traitement des objets métier et la notification des événements.
Le connecteur est contrôlé par les métadonnées. Le terme métadonnées, dans l'environnement d'IBM WebSphere Business Integration Adapter, désigne les données spécifiques à une application qui sont stockées dans des objets métier et qui assistent le connecteur dans ses échanges avec l'application. Un connecteur contrôlé par des métadonnées traite chaque objet métier qu'il prend en charge d'après les métadonnées codées dans la définition de l'objet métier plutôt que d'après les instructions codées en dur dans le connecteur.
Les métadonnées de l'objet métier incluent la structure d'un objet métier, les paramètres de ses propriétés d'attribut et le contenu de ses informations spécifiques à l'application. Dans la mesure où le connecteur est contrôlé par les métadonnées, il peut traiter de nouveaux objets métier ou des objets modifiés sans devoir modifier les codes du connecteur.
Le connecteur exécute les instructions SQL ou les procédures stockées en vue d'extraire ou de modifier les données de la base de données ou de l'application. Pour créer des instructions SQL ou des procédures stockées, le connecteur utilise des métadonnées propres à l'application. Les instructions SQL et les procédures stockées effectuent la récupération requise depuis la base de données ou l'application ou apportent les modifications nécessaires pour l'objet métier et l'instruction que le connecteur traite. Pour plus d'informations sur les informations spécifiques à l'application, voir Présentation des objets métier pour le connecteur.
Cette section explique comment le connecteur traite les requêtes des objets métier et les événements d'application. Pour plus d'informations, voir Traitement des instructions d'objet métier.
Lorsque le connecteur reçoit une requête d'exécution d'une opération d'application, il traite les objets métier hiérarchiques de manière récursive : il exécute la même procédure pour chaque objet métier enfant jusqu'à ce qu'il ait traité l'ensemble des objets métier. L'ordre dans lequel le connecteur traite les objets métier enfant et l'objet métier de niveau supérieur dépend si les objets métier enfant sont inclus avec ou sans droits de propriété et s'ils sont de type cardinalité simple ou multiple.
Lorsqu'un courtier d'intégration demande au connecteur d'extraire un objet métier hiérarchique de la base de données, le connecteur tente de renvoyer un objet métier qui correspond exactement à la représentation de cet objet métier dans la base de données actuelle. Autrement dit, tous les attributs simples de chaque objet métier renvoyé au courtier d'intégration correspondent à la valeur de la zone correspondante dans la base de données. En outre, le nombre d'objets métier dans chaque tableau contenu par l'objet métier renvoyé correspond au nombre d'enfants dans la base de données pour ce tableau.
Pour effectuer cette extraction, le connecteur utilise les valeurs de clé primaire dans l'objet métier de niveau supérieur pour descendre de manière récursive dans les données correspondantes de la base de données.
Lorsqu'un courtier d'intégration demande au connecteur d'extraire un objet métier hiérarchique en fonction des valeurs définies dans les attributs non clés dans l'objet métier de niveau supérieur, le connecteur utilise la valeur des attributs non nuls comme critères pour extraire les données.
Lorsqu'un courtier d'intégration demande au connecteur de créer un objet métier hiérarchique dans la base de données, le connecteur effectue les opérations suivantes :
Lorsqu'un courtier d'intégration demande au connecteur de mettre à jour un objet métier hiérarchique dans la base de données, le connecteur effectue les opérations suivantes :
Lorsqu'un courtier d'intégration demande au connecteur de supprimer un objet métier hiérarchique de la base de données, le connecteur effectue les opérations suivantes :
Le connecteur traite les événements de création, de mise à jour et de suppression générés par l'application comme décrit ci-dessous.
Lorsque le connecteur rencontre un événement de création dans la table d'événements, il crée un objet métier du type indiqué par l'événement, définit les valeurs de clés de l'objet métier (à partir des clés indiquées dans la table d'événements), et extrait l'objet métier de la base de données. Une fois qu'il a extrait l'objet métier, le connecteur l'envoie au courtier d'intégration par le biais de l'instruction Create.
Lorsque le connecteur rencontre un événement de mise à jour dans la table d'événements, il crée un objet métier du type indiqué par l'événement, définit les valeurs de clés de l'objet métier (à l'aide des clés indiquées dans la table d'événements), et extrait l'objet métier de la base de données. Une fois qu'il a extrait l'objet métier, le connecteur l'envoie au courtier d'intégration par le biais de l'instruction Update.
Lorsque le connecteur rencontre un événement de suppression dans la table d'événements, il crée un objet métier du type indiqué par l'événement, définit les valeurs de clés de l'objet métier (à l'aide des clés indiquées dans la table d'événements), et l'envoie au courtier d'intégration par le biais de l'instruction Delete. La valeur CxIgnore est affectée à toutes les valeurs autres que les valeurs de clés. Si des zones non clés sont importantes sur le site, modifiez la valeur des zones, si nécessaire.
Le connecteur traite les opérations de suppression logique et physique qui sont générées par son application. Dans le cas de suppressions physiques, le mécanisme SmartFiltering supprime tous les événements non traités de l'objet métier (comme les événements de création ou de mise à jour) avant d'insérer l'événement de suppression dans la table d'événements. Dans le cas des suppressions logiques, le connecteur insère un événement de suppression dans la table d'événements sans supprimer les autres événements de l'objet métier.
Une extraction peut être réalisée de deux manières sur un objet métier pour le traitement des événements. La première méthode est une extraction basée sur les attributs clés dans un objet métier. La seconde méthode est une extraction basée sur les attributs clés et non clés. Dans ce cas, l'objet métier doit prendre en charge l'instruction RetrieveByContent et utiliser la paire nom_valeur pour les clés de l'objet.
Le mécanisme de détection des événements du connecteur utilise une table d'événements, une table d'archivage, des procédures stockées et des déclencheurs de base de données. Etant donné la possibilité de points de défaillance associés au traitement des événements, le processus de gestion des événements ne supprime pas un événement de la table tant qu'il n'a pas été inséré dans la table d'archivage.
Les déclencheurs de la base de données remplissent une table d'événements lorsqu'un événement intéressant se produit dans la base de données. Le connecteur interroge cette table à intervalles réguliers, que vous pouvez définir, extrait les événements et les traite tout d'abord dans l'ordre de priorité, puis de manière séquentielle. Lorsque le connecteur a traité un événement, son état est mis à jour.
Le paramètre de sa propriété ArchiveProcessed détermine si le connecteur archive un événement dans la table d'archivage après avoir mis à jour son état. Pour plus d'informations sur la propriété ArchiveProcessed, voir Configuration du connecteur.
Le Tableau 1 illustre le mode opératoire de l'archivage en fonction
de la définition de la propriété ArchiveProcessed.
Tableau 1. Mode opératoire de l'archivage
Définition de la propriété ArchiveProcessed | Raison de la suppression de la table d'événements | Mode opératoire du connecteur |
---|---|---|
true ou aucune valeur | Traité correctement | Archivé avec l'état Sent to InterChange |
| Echec du traitement | Archivé avec l'état Error |
| Aucune inscription pour l'objet métier | Archivé avec l'état Unsubscribed |
false | Traité correctement | Non archivé et supprimé de la table d'événements |
| Echec du traitement | Reste dans la table d'événements avec l'état Error |
| Aucune inscription pour l'objet métier | Reste dans la table d'événements avec l'état Unsubscribed |
SmartFiltering est un mécanisme dans les déclencheurs de la base de données qui réduit le nombre de traitements que doivent entreprendre le courtier d'intégration et le connecteur. Par exemple, si une application a mis à jour l'objet métier Contract 15 fois depuis la dernière fois que le connecteur a demandé si des événements s'étaient produits, SmartFiltering stocke ces changements dans un seul événement Update.
L'interruption d'une connexion à une base de données peut avoir plusieurs explications. Si la connexion est interrompue, le connecteur s'arrête. La spécification JDBC ne fournit pas de mécanisme pour la détection des connexions interrompues. Etant donné que le connecteur prend en charge des bases de données différentes, il n'existe pas de définition unique des codes d'erreur pour une connexion interrompue.
La propriété PingQuery est fournie pour assurer cette fonction. Si une défaillance se produit lors d'une requête d'appel de service, le connecteur exécute la commande PingQuery pour confirmer que la défaillance n'était pas due à une connexion interrompue à la base de données. Si la commande PingQuery échoue et que la valeur "false" est affectée à la propriété AutoCommit, le connecteur tentera de rétablir la connexion à la base de données. S'il parvient à rétablir la connexion à la base de données, il poursuivra le traitement. Dans le cas contraire, le connecteur renvoie un message APPRESPONSETIMEOUT, qui provoque l'arrêt du connecteur.
La commande PingQuery est exécutée en cas d'échec de l'accès à une base de données pour un type de transaction quelconque. Par exemple :
Le connecteur a été internationalisé de sorte qu'il puisse 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(TM) dans 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 WebSphere Business Integration sont rédigés en Java. Par conséquent, lorsque des données sont transférées entre la plupart des composants du système WebSphere Business Integration, 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é de configuration standard de l'environnement local pour votre environnement. Pour plus d'informations sur ces propriétés, voir Annexe A, Propriétés de configuration standard pour les connecteurs.