Transformation du contrôle des transactions dans Informatica (exemple)

⚡ Résumé intelligent

Dans Informatica, une transformation de contrôle des transactions est un objet actif et connecté qui valide ou annule des lignes pendant qu'une carteping s'exécute en utilisant cinq variables intégrées dans une condition évaluée une fois pour chaque ligne.

(I.e. Cinq variables intégrées : TC_CONTINUE_TRANSACTION, TC_COMMIT_BEFORE, TC_COMMIT_AFTER, TC_ROLLBACK_BEFORE et TC_ROLLBACK_AFTER déterminent ce qui se passe à chaque ligne.
⚙️ La condition réside dans les propriétés : Le champ « Condition de contrôle des transactions » de l'onglet « Propriétés » contient l'expression IIF évaluée par le service d'intégration.
🧪 Exemple concret : Sept cartesping Les étapes du concepteur enregistrent les données EMP dans EMP_TARGET chaque fois que le numéro de département 20 est trouvé.
✅ Efficace ou inefficace : Toute transformation qui supprime les limites de transaction après avoir rendu l'objet inefficace pour la cible sous-jacente.
🔧 Type de validation de session : Une carteping avec une transformation de contrôle des transactions efficace s'exécute sous le type de validation défini par l'utilisateur.
⚠️ Valeur de retour stricte : Toute condition renvoyant autre chose que commit, roll back ou continue entraîne l'échec de la session par le service d'intégration.

Qu’est-ce que la transformation du contrôle des transactions ?

Le contrôle des transactions est une transformation active et connectée qui nous permet de valider ou d'annuler des transactions pendant l'exécution de la carte.pingLes opérations de validation et d'annulation sont d'une importance capitale car elles garantissent la disponibilité des données.

Lors du traitement d'un volume important de données, il peut arriver qu'il faille les enregistrer dans le système. Des enregistrements trop fréquents engendrent une surcharge système, tandis que des enregistrements trop tardifs augmentent le risque de perte de données en cas de panne.

Pour offrir plus de flexibilité, la transformation de contrôle des transactions est fournie. Au lieu de laisser le point de validation à sa valeur par défaut de session, elle permet d'introduire une condition à l'intérieur de la session. planping décider, ligne par ligne, où une transaction se termine et où la suivante commence.

Commandes TCL de validation et d'annulation

Cette transformation utilise cinq variables intégrées pour gérer l'opération. La condition doit renvoyer l'une de ces cinq valeurs pour chaque ligne ; toute valeur hors de cette liste entraîne l'échec de la session par le service d'intégration.

TC_CONTINUE_TRANSACTION

Dans TC_CONTINUE_TRANSACTION, aucune opération n'est effectuée ; le processus de chargement des données se poursuit normalement. Il s'agit de la valeur par défaut de l'expression.

TC_COMMIT_BEFORE

Dans TC_COMMIT_BEFORE, lorsque cet indicateur est activé, une validation est effectuée avant le traitement de la ligne courante. Une nouvelle transaction démarre alors et la ligne courante est écrite dans la cible.

TC_COMMIT_AFTER

Dans TC_COMMIT_AFTER, la ligne courante est traitée, puis une validation est effectuée et la transaction suivante commence.

TC_ROLLBACK_BEFORE

Dans TC_ROLLBACK_BEFORE, la restauration est effectuée en premier, puis les données sont traitées pour l'écriture.

TC_ROLLBACK_AFTER

Dans TC_ROLLBACK_AFTER, les données sont traitées, puis la restauration est effectuée.

Propriétés de transformation du contrôle des transactions

L'objet est configuré depuis la fenêtre « Modifier les transformations », qui comporte les mêmes quatre onglets que les autres transformations PowerCenter. Savoir quel onglet correspond à quel paramètre vous évitera de nombreuses recherches lors de la procédure détaillée ci-dessous.

Languette	Qu'est-ce qui est configuré là-bas ?
Transformation	Nom de la transformation, sa description et indication si l'objet est réutilisable.
Ports	Les ports d'entrée et de sortie sont généralement créés en faisant glisser les colonnes depuis la transformation en amont.
Propriétés	La condition de contrôle de transaction, ouverte avec la petite flèche à côté du champ, et la TracNiveau d'entrée enregistré dans le journal de session.
Extensions de métadonnées	Métadonnées définies par l'utilisateur conservées avec la transformation dans le référentiel.

Deux réglages font vraiment le travail. Condition de contrôle des transactions contient l'expression, qui est généralement un test IIF() renvoyant l'une des cinq variables. TracNiveau d'apprentissage détermine le niveau de détail de la transformation qui apparaît dans le journal de session lors de l'analyse de l'exécution.

Un des paramètres se situe en dehors de la transformation. Lorsqu'une carteping contient une transformation de contrôle des transactions efficace, la session s'exécute avec le Type de commit Défini sur « Défini par l'utilisateur » dans l'onglet Propriétés de Session, à la place du Target ou les types de commits de source qui utilisent un intervalle de commit fixe.

Comment utiliser la transformation de contrôle des transactions dans Informatica

Dans cet exemple, nous enverrons des données à la cible lorsque la condition dept no = 20 sera vraie.

Étape 1) Créer une carteping avec EMP comme source et EMP_TARGET comme cible. La carteping L'interface du concepteur contient alors la source, son qualificateur de source et la définition cible.

Étape 2) Créez une nouvelle transformation à l'aide du menu Transformation, puis dans la fenêtre Créer une transformation :

Sélectionnez un contrôle de transaction comme nouvelle transformation
Entrez le nom de la transformation « tc_commit_dept20 »
Sélectionnez l'option de création

Étape 3) La transformation Contrôle des transactions sera créée ; cliquez sur le bouton Terminé. Le nouvel objet apparaît alors sur le canevas, à côté du qualificateur de source.

Étape 4) Faites glisser toutes les colonnes de Source Qualifier vers la transformation Transaction Control, puis liez toutes les colonnes de la transformation Transaction Control à la table cible. Le pipeline s'exécute désormais : source → Source Qualifier → tc_commit_dept20 → EMP_TARGET.

Étape 5) Double cliquez sur la transformation Contrôle des transactions, puis dans la fenêtre de modification des propriétés :

Sélectionner l'onglet Propriété
Cliquez sur l'icône de l'éditeur de contrôle des transactions

Étape 6) Dans l'éditeur d'expressions, saisissez l'expression :

iif(deptno=20,tc_commit_before,tc_continue_transaction)

Sélectionnez ensuite OK. Cela signifie que si le numéro de département 20 est trouvé, la transaction est validée dans la cible ; sinon, le traitement en cours se poursuit.

Étape 7) Dans la fenêtre précédente, sélectionnez OK. La condition est désormais enregistrée dans l'onglet Propriétés de la transformation.

Maintenant, sauvegardez la carte.ping et l'exécuter après avoir créé la session et les flux de travail. Cette carteping Les données seront transférées vers la cible chaque fois que le numéro de département 20 sera trouvé dans les données.

Transformations efficaces et inefficaces du contrôle des transactions

La transformation est un générateur de transactions. Elle supprime les limites de transaction provenant de l'amont et définit ses propres limites pour tout ce qui suit ; c'est pourquoi sa position dans le pipeline est aussi importante que son état.

Il est appelé efficaces pour une cible lorsque les limites qu'elle crée atteignent encore cette cible, et inefficace lorsqu'une transformation ultérieure supprime ces limites. Selon le guide des transformations d'Informatica PowerCenter, les objets suivants suppriment les limites des transactions entrantes :

Un agrégateur, Fraiseuse, RangTransformation de tri ou transformation personnalisée dont la portée est « Toutes les entrées ».
Une transformation personnalisée configurée pour générer des transactions
Une autre transformation du contrôle des transactions
Une transformation de groupe à entrées multiples connectée à plusieurs points de contrôle de transaction en amont

L'inefficacité d'une transformation pour la cible ne la rend pas pour autant inutile. Une transformation en aval dont la portée est « Transaction » utilise toujours les limites définies en amont ; ainsi, une même transformation peut être efficace pour un trieur et inefficace pour la table sous-jacente.

Dans une carteping Avec plusieurs cibles, l'objet peut être efficace pour une cible et inefficace pour une autre. La carteping La configuration reste valide tant que chaque cible est connectée à une transformation de contrôle des transactions effective, et devient invalide dès qu'une cible ne l'est plus. Le concepteur indique quelles transformations sont inefficaces pour les cibles lorsque la configuration est établie.ping est enregistré ou validé.

Règles et lignes directrices pour la transformation du contrôle des transactions

La plupart des problèmes liés à cette transformation apparaissent lors de l'exécution plutôt que lors de la conception ; il est donc conseillé de vérifier les points ci-dessous avant la création de la session.

La valeur de retour est stricte. Si la condition est évaluée à une valeur autre que commit, rollback ou continue, le service d'intégration interrompt la session.
TC_CONTINUE_TRANSACTION est la solution de repli. Chaque branche de la fonction IIF() doit se terminer quelque part, et la valeur continue permet de laisser la transaction en cours intacte.
Le type de cible est important. Une transformation de contrôle des transactions connectée à une cible autre qu'une cible relationnelle, XML ou MQSeries dynamique est inefficace pour cette cible.
Cette condition ne peut utiliser que ce qui lui parvient. Seuls les ports liés à la transformation, ses ports variables et les variables intégrées sont disponibles dans l'éditeur de contrôle des transactions.
La fréquence d'engagement est un compromis. Une condition qui s'applique à presque chaque ligne supprime l'avantage de la mise en mémoire tampon, tandis qu'une condition qui ne se déclenche presque jamais réintroduit la fenêtre de perte de données que la transformation était censée combler.
Consultez le journal de session. Le journal enregistre les points de validation réellement effectués, ce qui constitue le moyen le plus rapide de confirmer que la condition s'est comportée comme prévu pendant l'optimisation des performances.

FAQ

Un intervalle de validation effectue la validation après un nombre fixe de lignes défini dans la session. Une condition de contrôle de transaction effectue la validation sur les données elles-mêmes ; le point de validation suit donc une règle métier plutôt qu’un nombre de lignes.

Le guide de transformation d'Informatica PowerCenter indique qu'une transformation Transaction Control connectée à une cible autre qu'une cible relationnelle, XML ou MQSeries dynamique est inefficace pour cette cible.

Oui. Créez-le dans l'outil de développement de transformations, ou cochez la case « Rendre réutilisable » dans l'onglet Transformation d'une transformation existante. Chaque carteping Elles partagent alors la même condition, de sorte qu'une modification de la règle les affecte toutes simultanément.

L'apprentissage automatique appliqué aux journaux de sessions historiques peut identifier les charges où la fréquence des commits est corrélée à des durées d'exécution longues ou à des épisodes de restauration. Cette suggestion reste une hypothèse ; il est donc conseillé de la vérifier sur un test réel avant de modifier les conditions.

Copilot peut générer la structure IIF() et vous rappeler les cinq noms de variables, mais il ne connaît pas vos noms de ports ni vos règles métier. Considérez le résultat comme un point de départ et validez-le dans l'éditeur d'expressions.

La stratégie de mise à jour détermine le traitement d'une ligne : insertion, mise à jour, suppression ou rejet. Le contrôle des transactions détermine le moment où les lignes modifiées sont rendues définitives. Ces deux mécanismes répondent à des problématiques différentes et sont souvent utilisés conjointement.

Cloud Data Integration intègre sa propre transformation de contrôle des transactions avec les mêmes variables de validation, d'annulation et de continuation. Le principe de conception reste le même, mais l'objet est construit dans la map cloud.ping Concepteur plutôt que dans le client PowerCenter.

Les lignes écrites depuis la dernière validation de cette transaction sont ignorées. Les données validées antérieurement sont conservées dans la cible ; c’est pourquoi l’emplacement des points de validation détermine l’impact d’une erreur sur le travail.