Transaktionskontroltransformation i Informatica (eksempel)
Redaktionelle team
⚡ Smart opsummering
Transaktionskontroltransformation i Informatica er et aktivt, forbundet objekt, der committer eller ruller rækker tilbage, mens et kortping kører ved hjælp af fem indbyggede variabler i en betingelse, der evalueres én gang for hver række.
Hvad er Transaction Control Transformation?
Transaktionskontrol er en aktiv og forbundet transformation, der giver os mulighed for at committe eller rulle tilbage transaktioner under udførelsen af kortet.pingCommit- og rollback-operationer er af stor betydning, fordi de garanterer tilgængeligheden af data.
Når man behandler en stor mængde data, kan der opstå situationer, hvor det er nødvendigt at commit dataene til målet. Hvis en commit udføres for ofte, vil det medføre en overhead for systemet. Hvis en commit udføres for sent, er der risiko for datatab i tilfælde af fejl.
Så for at give fleksibilitet er Transaction Control-transformationen tilgængelig. I stedet for at lade commit-punktet være standardindstillingen for sessionen, tillader den en betingelse indeni kortping bestemme, række for række, hvor én transaktion slutter, og den næste begynder.
TCL Commit- og Rollback-kommandoer
Der er fem indbyggede variabler tilgængelige i denne transformation til at håndtere operationen. Betingelsen skal returnere en af de fem for hver række, og en værdi uden for denne liste får integrationstjenesten til at fejle sessionen.
TC_CONTINUE_TRANSACTION
I TC_CONTINUE_TRANSACTION udføres der ingen handlinger, dataindlæsningsprocessen fortsætter som den er. Dette er standardværdien for udtrykket.
TC_COMMIT_BEFORE
I TC_COMMIT_BEFORE, når dette flag er angivet, udføres en commit før behandlingen af den aktuelle række. En ny transaktion begynder derefter, og den aktuelle række skrives til målet.
TC_COMMIT_AFTER
I TC_COMMIT_AFTER behandles den aktuelle række, derefter udføres en commit, og den næste transaktion begynder.
TC_ROLLBACK_BEFORE
I TC_ROLLBACK_BEFORE udføres rollback først, derefter behandles dataene for at skrive.
TC_ROLLBACK_AFTER
I TC_ROLLBACK_AFTER behandles dataene, og derefter udføres rollback.
Egenskaber for transformation af transaktionskontrol
Objektet konfigureres fra vinduet Rediger transformationer, som har de samme fire faner som de andre PowerCenter-transformationer. At vide, hvilken fane der ejer hvilken indstilling, sparer en masse søgen under gennemgangen nedenfor.
| Tab | Hvad er konfigureret der |
| Transformation | Navn på transformationen, dens beskrivelse og om objektet gøres genbrugeligt. |
| Havne | Input- og outputportene, normalt oprettet ved at trække kolonnerne ind fra den opstrøms transformation. |
| Ejendomme | Transaktionskontrolbetingelsen, åbnet med den lille pil ved siden af feltet, og Tracing-niveau skrevet til sessionsloggen. |
| Metadata-udvidelser | Brugerdefinerede metadata, der opbevares sammen med transformationen i arkivet. |
To indstillinger gør det rigtige arbejde. Transaktionskontrolbetingelse indeholder udtrykket, som normalt er en IIF()-test, der returnerer en af de fem variabler. Tracniveau bestemmer, hvor mange detaljer om transformationen der vises i sessionsloggen, når kørslen undersøges.
Én indstilling ligger uden for transformationen. Når et kortping indeholder en effektiv transaktionskontroltransformation, kører sessionen med Commit-type indstillet til Brugerdefineret på fanen Egenskaber i Session, i stedet for Target eller kilde-commit-typer, der bruger et fast commit-interval.
Sådan bruger du transaktionskontroltransformation i Informatica
I dette eksempel vil vi committe data til målet, når betingelsen afdelingsnr. = 20 findes at være sand.
Trin 1) Opret et kortping med EMP som kilde og EMP_TARGET som mål. Kortetping Designer-lærredet indeholder derefter kilden, dens kildekvalifikator og måldefinitionen.
Trin 2) Opret en ny transformation ved hjælp af menuen Transformation, og gør derefter følgende i vinduet Opret transformation:
- Vælg en transaktionskontrol som den nye transformation
- Indtast transformationsnavnet "tc_commit_dept20"
- Vælg oprettelsesmulighed
Trin 3) Transaktionskontroltransformationen oprettes. Vælg knappen "Udført". Det nye objekt vises nu på lærredet ved siden af kildekvalifikatoren.
Trin 4) Træk og slip alle kolonnerne fra kildekvalifikatoren til transaktionskontroltransformationen, og link derefter alle kolonnerne fra transaktionskontroltransformationen til måltabellen. Pipelinen kører nu kilde → kildekvalifikator → tc_commit_dept20 → EMP_TARGET.
Trin 5) Double Klik på transformationen Transaktionskontrol og derefter i vinduet Rediger egenskaber:
- Vælg egenskabsfanen
- Klik på ikonet for transaktionskontroleditoren
Trin 6) I udtrykseditoren skal du indtaste udtrykket –
iif(deptno=20,tc_commit_before,tc_continue_transaction)
og vælg OK. Det betyder, at hvis afdelingsnr. 20 findes, skal transaktionen committes i målet, ellers skal den aktuelle behandling fortsættes.
Trin 7) Vælg OK i det forrige vindue. Betingelsen er nu gemt på fanen Egenskaber for transformationen.
Gem nu kortetping og udføre den efter oprettelse af session og arbejdsgange. Dette kortping vil overføre dataene til målet, når afdelingsnummer 20 findes i dataene.
Effektive og ineffektive transaktionskontroltransformationer
Transformationen er en transaktionsgenerator. Den fjerner enhver transaktionsgrænse, der kommer fra upstream, og definerer sine egne nye grænser for alt downstream, hvilket er grunden til, at dens position i pipelinen er lige så vigtig som dens tilstand.
Det kaldes effektiv for et mål, når de grænser, det skaber, stadig når dette mål, og ineffektiv når en senere transformation fjerner disse grænser. Ifølge Informatica PowerCenter Transformation Guide fjerner følgende objekter grænser for indgående transaktioner:
- En aggregator, Joiner, Rang (Kolonne), Sorteringsværktøj eller brugerdefineret transformation, hvis transformationsomfang er Alt input
- En brugerdefineret transformation konfigureret til at generere transaktioner
- Endnu en transformation af transaktionskontrol
- En transformation med flere inputgrupper forbundet til mere end ét upstream-transaktionskontrolpunkt
At være ineffektiv for målet gør ikke objektet ubrugeligt. En downstream-transformation, hvis Transformation Scope er Transaction, bruger stadig de grænser, der er defineret upstream, så den samme transformation kan være effektiv for en sorterer og ineffektiv for tabellen bagved.
På et kortping Med flere mål kan objektet være effektivt for ét mål og ineffektivt for et andet. Kortetping forbliver gyldig, mens hvert mål er forbundet til en effektiv transaktionskontroltransformation, og bliver ugyldig, så snart ét mål ikke er det. Designeren rapporterer, hvilke transformationer der er ineffektive for mål, når kortetping er gemt eller valideret.
Regler og retningslinjer for transformation af transaktionskontrol
De fleste problemer med denne transformation opstår under kørsel snarere end under design, så det er værd at kontrollere punkterne nedenfor, før sessionen bygges.
- Returværdien er streng. Hvis betingelsen evalueres til andet end commit, rollback eller continue, fejler integrationstjenesten sessionen.
- TC_CONTINUE_TRANSACTION er reserven. Hver gren af IIF() skal slutte et sted, og continue er den værdi, der ikke berører den aktuelle transaktion.
- Måltypen er vigtig. En transaktionskontroltransformation, der er forbundet med et andet mål end et relationelt, XML- eller dynamisk MQSeries-mål, er ineffektiv for det pågældende mål.
- Betingelsen kan kun bruge det, der når den. Kun porte, der er linket til transformationen, dens variable porte og de indbyggede variabler, er tilgængelige i transaktionskontroleditoren.
- Commit-frekvens er en afvejning. En betingelse, der committer på næsten hver række, fjerner fordelen ved buffering, mens en betingelse, der næsten aldrig udløses, genintroducerer det datatabsvindue, som transformationen blev tilføjet for at lukke.
- Tjek sessionsloggen. Loggen registrerer de commit-punkter, der rent faktisk blev taget, hvilket er den hurtigste måde at bekræfte, at betingelsen opførte sig som tilsigtet under præstationsindstilling.
