Verwendung des Lookup Heater

Hallo,
ich habe eine Frage zur Verwendung des Lookup Heater.

Ich habe auf der Eingangsseite eine csv Datei, welche eine Rechnungsnummer als Teil eines Stringfeldes beinhaltet. Diese Rechnungsnummer extrahiere ich per RegEx (?<!\d)\d{6}(?!\d) aus dem entsprechenden CSV Feld, was soweit auch funktioniert.

Auf der Write - Seite  habe ich aktuell zwei Adapter. Den In-Memory-Adapter für den späteren CSV Export (2. Verarbeitungschritt), sowie einen nur zu Definition des SQL-Connect  für den Lookup verwendeten Oracle Adapter.

Das RegEx Ergebnis versuche ich über den Lookup Heater zu führen um entsprechende zusätzliche Informationen, die aus einer Oracle-Tabelle gelesen/ergänzt werden müssen zu erhalten.
Das scheint aber offenbar der falsche Weg zu sein.

Wie kann diese Anforderung abgebildet werden ?


Danke, Philip Herbert


 

Hallo Herr Herbert,

das Problem ist, dass aktuell ein hinzugefügter Adapter auch eine Verbindung und Funktion haben muss. Sie können das auf zwei Arten lösen.

1. Einlesen der Tabellenwerte in einem vorgelagerten Verarbeitungsschritt in eine weitere InMemory Adapter Tabelle und dann per String Replace Heater diese InMemory Tabelle abfragen.
   
2. Sie konfigurieren den Oracle Adapter so, dass hier nur ein SQL Skript erstellt wird, siehe Screenshot. Für den PrimaryKey übergeben Sie lediglich einen Dummy Wert, so sind Sie sicher, dass keine Daten eingefügt werden. Hinweis: Wenn Sie die Definition ausführen wird Ihnen angezeigt, dass die Daten erfolgreich geschrieben wurden, das bezieht sich in dem Fall nur auf das SQL Skript!

 
 

Danke, zumindest komme ich einen Schritt weiter,

Ich hatte zuvor die gesamte Tabelle ausgelesen,
das hat jedoch deutlich zu lange gedauert.

allerdings liefert der Lookup Header (Konfig wie im Screenshot kein Ergebnis, sondern nur das Default Ergebnis wenn nichts gefunden wird.
Im In Memory Adapter steht aber die richtige Rechnungsnummer drin, die der RegEx findet.

Wenn ich Lookup die Bedingung = $1 gegen 4711 tausche, wird der Inhalt des Feldes PATNR richtig aus der Tabelle passend zur Rechnung 4711 geliefert.
Das verstehe ich noch nicht.

Danke, Philip Herbert


 

bitte setzen Sie auf dem Lookup Heater mal einen Haltepunkt. Hierzu einfach mit der rechten Maustaste das Kontextmenü öffnen und „Haltepunkt“ auswählen. Der Lookup Heater wird nun mit einem roten Kreis dargestellt. Wenn Sie die Definition nun im Testmodus ausführen hält die Verarbeitung hier an und Sie können sich die Ein- und Ausgehenden Daten ansehen. Ich vermute, dass hier ein Problem mit der Formatierung vorliegt?

Alternativ könnten Sie auch den SQL Heater verwenden. Hier können Sie den SQL Befehl selbst aufbauen.

 

Danke, ein TRIM vor dem Lookup Heater  war die Lösung !

Dennoch werde ich mal weiter mit Tabelle einlesen (in Memory) probieren.
Da ich insgesamt 3 Felder aus der Tabelle benötigen werde, erscheint mit das doch effizienter (ggf. mit WHERE Clause um keinen FullTable Read zu benötigen)

ggf. kommen noch ein-zwei  Fragen zum FlowHeater Server ... Ich bin auf jeden Fall schon mal begeistert ! 

Danke, Philip Herbert
 

Ich habe den Fehler gefunden. Das Problem ist, dass aus dem RegEx Heater ein Datentyp String kommt und dann der Lookup Heater hier folgendes durchführt.

    … WHERE RECHNR = ‘4711’

Sie können diese Standardformatierung umgehen indem Sie die Ausgabe des RegEx Heater über einen Set Parameter Heater in einem FlowHeater Parameter (z.B. $RECHNR$) ablegen und dann im Lookup Heater diesen Parameter verwenden.

    … WHERE RECHNR = $RECHNR$

 

Hallo Herr Stark,

ich bin aktuell wieder an diesem Thema dran.

Ist es immer noch so, dass man für einen Lookup den Adapter für jede Zeile auf der Write Seite neu ausführen muss und eine sql datei füllen muss ?
Ich habe den Eindruck, dass die Performance mindestens suboptimal ist. 

Ich hatte damals einfach einen Großteil der Orale Tabelle inMemory eingelesen und dann den lookup dagegen ausgeführt.
Um z.B. 120 Datensätze anzureichen mehrere Zehntausend Zeilen der letzten Jahre einzulesen (nur weil ein Datensatz aus der Zeit sein kann) stört mich irgendwie nach wie vor.

Danke, Philip Herbert

Hallo Herr Herbert,

das geht mittlerweile so wie Sie es ursprünglich tun wollten. Allerdings dürfen Sie im Oracle Adapter nur die Verbindung konfigurieren, ohne dass dann im Anschluss die Felder der Tabelle ausgelesen werden.

Im Lookup Heater müssen Sie dann lediglich auswählen auf welchen Adapter bzw. Datenquelle der Datenlookup durchgeführt werden soll, siehe Screenshot.

 
 

vielen Dank, das funktioniert deutlich performanter und ist (mit entsprechendem Namen des Adapters) auch verständlicher

Wenn man mehrere Felder einer Tabelle aus dieser Tabelle benötigt, muss man für jedes Feld den Lookup oder SQL Heater verwenden, (Performace) oder kann man dieser Felder 
zusammen auslesen und dann trennen ? Was ist in so einem Fall Best-Practice.

Danke, Philip Herbert

 

Hallo Herr Herbert,

also wenn es sich nur um ein paar zehntausend Datensätze handelt würde ich pro Feld einen eigenen SQL Heater oder aber Lookup Heater verwenden. Oracle bzw. auch andere DBMS-Systeme können das gut skalieren, der Datensatz ist ja bereist eh schon selektiert bzw. im Cache und es muss nur eine andere Spalte bzw. Feld zurückgegeben werden. Natürlich muss hier immer pro Feld ein erneuter Connect zur Oracle Datenbank aufgebaut werden, was bei sehr vielen Daten sich dann schon aufsummiert.

Alternativ dazu könnte das über den  SQL Heater durchgeführt werden. Hier müssten Sie aber im SELECT die Felder selbst zu einem Feld zusammenführen, da der  SQL Heater nur eine Feld zurückgeben kann. Das ist dann gerade bei nicht Zeichenfolgen mit der Formatierung teilweise nicht ganz so einfach.

z.B. reine Textfelder über: select concat(feld1, ‘#’, feld2, ‘#’, feld3) from ihre_tabelle where pk = ‘$ID$’

Im Anschluss können Sie dann die Rückgabe mit dem String Split Heater und dem Trennzeichen ‚#‘ wieder auseinander splitten.
Sie werden die Daten über einen zusätzlichen Connect zur Oracle Datenbank geholt, sie sparen sich pro CSV-Zeile bei 3 Feldern 2 zusätzliche SQL-Abfragen.

Aus meiner Sicht ist der Kosten/Nutzen Faktor erst bei wirklich großen Datenmengen relevant, ansonsten würde ich immer einfach mehrere  SQL Heater oder aber  Lookup Heater verwenden.
 

mich irritiert einfach die Performance ....

104000 Zeilen aus Oracle in Memory Einlesen: 4.5 Sekunden
780x denn LookupHeater: > 30 Sekunden


 

Hallo Herr Herbert,

ich vermute mal der Lookup Heater soll anhand einer IF-THEN-ELSE Bedingung nur ausgeführt werden, wenn ein bestimmtes Kriterium erfüllt ist, so kommen Sie auf 780x Lookup Heater?

Das Problem hier ist, der FlowHeater führt immer alle Heater/Funktionen 1x aus die eine Verbindung zur WRITE Seite haben oder aber durch einen anderen Heater (z.B. Set) gerufen werden und das unabhängig ob hier der „Wenn/Then“ bzw. „Dann/Else“ Fall zurückgegeben wird.

Dafür ist doch die Performance nicht schlecht 

Sie können das aber über den .NET Script Heater umsetzen. Wenn Sie hier im Skript die Bedingung einbauen, wird der Lookup bzw. das SQL auch nur ausgeführt, wenn die Bedingung zutrifft.