Will man bestimmte Werte zu einem späteren Zeitpunkt in einem Mapping weiterverwenden, stellt sich immer wieder die Frage: Wie kann ich das problemlos und praktikabel handhaben?! Andreas, Solution Architect QUIBIQ Schweiz, hat eine wirklich gute Lösung für euch:
Die meistgelesene Empfehlung lautet ungefähr so: Erstelle ein Hilfsschema, das die benötigte Variable aufnehmen kann und schicke eine darauf beruhende Hilfsmessage gemeinsam mit der zu bearbeitenden Message in das Mapping – als Multipart-Message. Der Variablenwert kann dann aus dem Hilfsmessage-Part entnommen werden. Will man z.B. aus einer Liste von Commands ein einzelnes Command mit einem Index herausselektieren, so würde das etwa so aussehen:
Eine einfache Lösung, schnell gemacht. Nachteil dieser Lösung ist allerdings, dass man das gesonderte Hilfsschema benötigt und die entsprechende Message natürlich auch vor dem Mapping instanziieren muss – in einem Loop also bei jedem Loopdurchlauf. Außerdem ist es bei der Entwicklung des Mappings mitunter ziemlich lästig, die Multiparts-Testmessages zu erstellen. Ganz davon abgesehen, das all das Zeit kostet...
Wir haben eine alternative, flexiblere Lösung für euch:
Im Rahmen einer Projektumsetzung entwickelten wir eine Cache-Komponente, um oft benötigte Daten aus externen Systemen (CRM Online, eine SQL-DB) zwischenzuspeichern. Die Performance sollte durch Einsparung von ziemlich langsamen Queries auf die externen Systeme verbessert werden und beim SQL Server wollten wir die Anzahl konkurrierender Transaktionen und damit Last und DeadLocks auf dem SQL-Server verringern. Das haben wir erreicht - und es ergaben sich so ganz nebenbei völlig neue Einsatzmöglichkeiten für diese Komponente:
Der Object-Cache ermöglicht nämlich das Schreiben und Lesen von beliebigen .Net Objekten, und zwar aus Orchestration (auch übergreifend) und Maps heraus. Das reduziert den Overhead an Code, im Vergleich zur Nutzung von Helper- oder Property-Schemas.
Nehmen wir oben genannte Fragestellung eines Loopings. In der folgenden Abbildung sehen wir ein solches Szenario:
In dieser Loop werden jeweils 100 Records einer Message vereinzelt und als Einzelmessage zur weiteren Verarbeitung in die MessageBox gesendet. In der Loop wird eine Variable für den Rekordindex (EntityIndex) hochgezählt.
In dem Expressionshape ‚Index_2_Cache‘ wird dieser Index in den Cache geschrieben. Und zwar mit diesem Code:
Helper.CacheHelper.SetStringItem("GICCache"
,"SplittingIndex"
,EntityIndex.ToString()
,120);
Die Parameter haben folgende Bedeutung:
GICCache: CacheDomainName zur Abgrenzung gegenüber anderen Orchestrations
SplittingIndex: Der Key mit dem der Eintrag abgefragt werden kann
EntityIndex: Das Value, welches in dem Mapping verwendet werden soll
120: Die Lebenszeit des Eintrages in Sekunden (nach Ablauf dieser Zeit wird der Eintrag wieder aus dem Cache entfernt)
In den nächsten Abbildungen sehen wir, wie der Eintrag aus dem Cache geholt wird und für die Auswahl des entsprechenden Rekords verwendet wird.
1. CacheDomainName
2. Key
3. GetItemAsString
Inputparameter
Methodenaufruf
4. Rekordindex
5. = EntityIndex (Verwendung)
Voraussetzung ist natürlich, dass eine Referenz auf die Cache-Komponente dem Projekt hinzugefügt wird.
Dies ist noch ein relativ einfacher Anwendungsfall. In einem anderen Projekt werden komplette Werttransformationen aus einer Config-DB gelesen, in den Cache geschrieben und dann in einem Mapping verwendet. Man kann also auf diese Weise auch den DB-Traffic bei Lookups erheblich minimieren.
In Bezug auf die oben erwähnte Fragestellung lassen sich zum Testen die Werte in einer anderen Map in den Cache schreiben, und dann in dem zu testenden Mapping wieder herausholen. Das sieht dann etwa so aus:
1. CacheDomainName
2. Key
3. Value
4. LifeTime
5. Methodenaufruf
Der Scripting-Functoid sieht dann so aus:
Wir hoffen sehr, das dieser Beitrag euch dabei hilft, bestimmte Problemstellungen gerne mal aus einem anderen Blickwinkel zu betrachten und bessere und performantere Lösungen zu finden.
