Entries tagged as informatica
Related tags
Thursday, 7. May 2009
Regexes bei Informatica
He, darauf habe ich so lange gewartet. Informatica 8 unterstüzt endlich reguläre Ausdrücke. Das kann die Arbeit sehr vereinfachen. Das ist echt mal praktisch. Fehlt nur noch bei Oracle. Das kanns erst ab Version 10 und ich muß hier immernoch Version 9 benutzen.
Monday, 27. April 2009
Debugging mit Informatica Powercenter 8
Ich muß mal kurz einen kleinen Rant loswerden.
In den letzten 2 Wochen habe ich 2 komplexere Probleme in 2 Flows untersucht. Das Killerfeature was dabei immer genannt wird ist der eingebaute Debugger. Damit kann man einem Datensatz zusehen, wie die Transformationslogik angewandt wird. So richtig schön grafisch und mit Breakpoints. Zumindest theoretisch. Praktischerweise funktioniert das Teil nämlich nicht verläßlich, zumindest, wenn in der Mappinglogik ein Outer-Join enthalten ist. Dann beendet sich der Debugger nämlich einfach ohne ersichtlichen Grund. Wenn man Glück hat, kann man wenigstens noch durch einen Teil der Logik durchsteppen. Was hab ich geflucht, aufgrund dieses Bugs, der schon mindestens seit Version 7 drin ist.
Man kann in diesem Fall also nicht mit dem Debugger debuggen. Was macht man? Richtig, wie früher in der guten alten Zeit(™) das Loglevel hochdrehen auf "Verbose Data" (damit loggt Informatica praktisch für jede Transformation den eingehenden und ausgehenden Datensatz) und dann Logfiles lesen. Lustigerweise hat Informatica mit Version 8 auf eine Art binäres Logfile umgestellt. Man kann diese Dinger nicht mehr anständig mit einem stinknormalen Editor oder Pager lesen, sondern muß den eingebauten Logfile Viewer nutzen. Der ist schon umständlich genug zu nutzen, nur leider ist das Teil auch nicht mal richtig stabil. Während ich also das Loglevel auf Verbose Data hochdrehte und mit ein paar Testdatensatz den ganzen Flow nochmal laufen lies, stellte ich fest, dass das Logfile auf enorme 2 GB angewachsen war. Und das mit nur einer Handvoll Testdatensätze. Aber wartet, es kommt noch besser: Als ich versuchte, das Logfile mit dem eingebauten Logfileviewer zu öffen, ist mit der Viewer gnadenlos abgestürzt. Also Loglevel wieder runtergedreht auf Normal und nur bei vereinzelten Transformationen "Verbose Data" angeschaltet. Danach war das Logfile immer noch mehrere Hundert MB groß, doch zumindest konnte man es betrachten.
Ich glaube jedes Problem hat ca: 1 Arbeitstag gekostet, bis ich den Fehler gefunden hatte. Da gibt es noch Verbesserungspotential.
In den letzten 2 Wochen habe ich 2 komplexere Probleme in 2 Flows untersucht. Das Killerfeature was dabei immer genannt wird ist der eingebaute Debugger. Damit kann man einem Datensatz zusehen, wie die Transformationslogik angewandt wird. So richtig schön grafisch und mit Breakpoints. Zumindest theoretisch. Praktischerweise funktioniert das Teil nämlich nicht verläßlich, zumindest, wenn in der Mappinglogik ein Outer-Join enthalten ist. Dann beendet sich der Debugger nämlich einfach ohne ersichtlichen Grund. Wenn man Glück hat, kann man wenigstens noch durch einen Teil der Logik durchsteppen. Was hab ich geflucht, aufgrund dieses Bugs, der schon mindestens seit Version 7 drin ist.
Man kann in diesem Fall also nicht mit dem Debugger debuggen. Was macht man? Richtig, wie früher in der guten alten Zeit(™) das Loglevel hochdrehen auf "Verbose Data" (damit loggt Informatica praktisch für jede Transformation den eingehenden und ausgehenden Datensatz) und dann Logfiles lesen. Lustigerweise hat Informatica mit Version 8 auf eine Art binäres Logfile umgestellt. Man kann diese Dinger nicht mehr anständig mit einem stinknormalen Editor oder Pager lesen, sondern muß den eingebauten Logfile Viewer nutzen. Der ist schon umständlich genug zu nutzen, nur leider ist das Teil auch nicht mal richtig stabil. Während ich also das Loglevel auf Verbose Data hochdrehte und mit ein paar Testdatensatz den ganzen Flow nochmal laufen lies, stellte ich fest, dass das Logfile auf enorme 2 GB angewachsen war. Und das mit nur einer Handvoll Testdatensätze. Aber wartet, es kommt noch besser: Als ich versuchte, das Logfile mit dem eingebauten Logfileviewer zu öffen, ist mit der Viewer gnadenlos abgestürzt. Also Loglevel wieder runtergedreht auf Normal und nur bei vereinzelten Transformationen "Verbose Data" angeschaltet. Danach war das Logfile immer noch mehrere Hundert MB groß, doch zumindest konnte man es betrachten.
Ich glaube jedes Problem hat ca: 1 Arbeitstag gekostet, bis ich den Fehler gefunden hatte. Da gibt es noch Verbesserungspotential.
Posted by chrisbra
in Tipps And Tricks
at
18:09
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: beruf, business intelligence, debug, dwh, informatica, nerd, rant, tipps and tricks
Tuesday, 19. February 2008
Informatica Repository Metadaten
Wenn man Informatica als ETL-Lösung zur Beladung eines Datawarehouse nutzt, kann es sinnvoll sein, hin und wieder die Metadaten des Repositories zu entrümpeln. Dort werden nämlich die Statistiken über alle durchgeführten Läufe gespeichert und, falls eingerichtet, auch die Versionsinformationen.
Wenn jetzt der Ladeprozess täglich läuft und dabei jedesmal um die 100 Workflows mit mehreren Sessions laufen (was weder unüblich noch besonder viel ist), dann kann der Platz im Tablespace der darunter liegenden Datenbank des Informatica Repositories arg eng werden. Deshalb empfiehlt es sich, hin und wieder mal die Statistiken zu löschen. Das geschieht typischerweise mittels pmrep truncatelog. Näheres weiß die sehr gute Dokumentation zum Thema.
Ich wollte es nur mal gesagt haben, damit ich das nicht wieder vergesse.
Wenn jetzt der Ladeprozess täglich läuft und dabei jedesmal um die 100 Workflows mit mehreren Sessions laufen (was weder unüblich noch besonder viel ist), dann kann der Platz im Tablespace der darunter liegenden Datenbank des Informatica Repositories arg eng werden. Deshalb empfiehlt es sich, hin und wieder mal die Statistiken zu löschen. Das geschieht typischerweise mittels pmrep truncatelog. Näheres weiß die sehr gute Dokumentation zum Thema.
Ich wollte es nur mal gesagt haben, damit ich das nicht wieder vergesse.
Wednesday, 23. January 2008
Dynamische Ausdrücke auswerten mit Informatica PowerCenter Designer
Informatica ist ein Hersteller von Datenintegrationssoftware. Sowas benötigt man im Allgemeinen, wenn man ein Daten-Warehouse beladen möchte. Damit kann man dann die Daten normalisieren und Regeln anwenden, ohne sich mit komplexen SQL-Statements rumzuschlagen (ETL-Prozess).
Für ein Projekt kam jetzt die Anforderung auf, dynamisch Regeln auszuwerten. Im Idealfall sieht das dann so aus. Man hat z.B. folgende Tabelle:
create table logik(
FELD1 number,
FELD2 number,
FORMULA varchar2(100)
)
In Spalte FELD1 und FELD2 steht jeweils ein Wert und in der Spalte Formel befindet sich die Berechnung (z.B. FELD1/FELD2 * 100 um den Prozentsatz des Verhältnisses zu bestimmen). Beim Beladen möchte man nun optimalerweise die Formel gleich anwenden, also dynamisch auswerten. Obwohl man mit Informatica PowerCenter durchaus komplexe Transformationen durchführen kann, fehlt die Funktionalität solche Ausdrücke zur Laufzeit auswerten zu können.
Der Workaround besteht darin, eine StoredProcedure Transformation einzubauen (in Informatica 8 sollte auch eine SQL-Transformation existieren, mit der man das auch erreichen kann) , die in der Datenbank eine Stored Procedure ablegt, die das dynamisch auswertet.
Bsp (für Oracle):
CREATE OR REPLACE FUNCTION calc (formula VARCHAR2) RETURN real IS
sql_stmt varchar2(100);
v_result real;
BEGIN
sql_stmt := 'SELECT ' || formula || ' from dual';
EXECUTE IMMEDIATE sql_stmt into v_result;
return v_result;
EXCEPTION
WHEN OTHERS THEN RAISE;
END calc;
Diese PL/SQL Funktion macht nichts weiter als den übergebenen Ausdruck auszuwerten, im Prinzip also ein eval(). So kann man z.B. einfache Formel berechnen:
Theoretisch kann man so jegliche SQL-Ausdrücke auswerten lassen, dazu muß der Rückgabewert bei Bedarf noch auf Varchar geändert werden.
In Informatica kann die Prozedur dann so eingebunden werden:

Übersicht über das Mapping Design:
In der Expression Transformation (rot), werden die String-Variablen FELD1 und FELD2 im Feld FORMULA durch ihren Inhalt ersetzt. Diese aufgelöste Formel, wird danach an die Stored Procedure CALC übergeben (unconnected)
Für ein Projekt kam jetzt die Anforderung auf, dynamisch Regeln auszuwerten. Im Idealfall sieht das dann so aus. Man hat z.B. folgende Tabelle:
create table logik(
FELD1 number,
FELD2 number,
FORMULA varchar2(100)
)
In Spalte FELD1 und FELD2 steht jeweils ein Wert und in der Spalte Formel befindet sich die Berechnung (z.B. FELD1/FELD2 * 100 um den Prozentsatz des Verhältnisses zu bestimmen). Beim Beladen möchte man nun optimalerweise die Formel gleich anwenden, also dynamisch auswerten. Obwohl man mit Informatica PowerCenter durchaus komplexe Transformationen durchführen kann, fehlt die Funktionalität solche Ausdrücke zur Laufzeit auswerten zu können.
Der Workaround besteht darin, eine StoredProcedure Transformation einzubauen (in Informatica 8 sollte auch eine SQL-Transformation existieren, mit der man das auch erreichen kann) , die in der Datenbank eine Stored Procedure ablegt, die das dynamisch auswertet.
Bsp (für Oracle):
CREATE OR REPLACE FUNCTION calc (formula VARCHAR2) RETURN real IS
sql_stmt varchar2(100);
v_result real;
BEGIN
sql_stmt := 'SELECT ' || formula || ' from dual';
EXECUTE IMMEDIATE sql_stmt into v_result;
return v_result;
EXCEPTION
WHEN OTHERS THEN RAISE;
END calc;
CODE:SQL> select 7*10/2 from dual; 7*10/2 ------ 35
Theoretisch kann man so jegliche SQL-Ausdrücke auswerten lassen, dazu muß der Rückgabewert bei Bedarf noch auf Varchar geändert werden.
In Informatica kann die Prozedur dann so eingebunden werden:
Übersicht über das Mapping Design:
In der Expression Transformation (rot), werden die String-Variablen FELD1 und FELD2 im Feld FORMULA durch ihren Inhalt ersetzt. Diese aufgelöste Formel, wird danach an die Stored Procedure CALC übergeben (unconnected)
(Page 1 of 1, totaling 4 entries)
