BizTalk Mappings zur Laufzeit

Lorenz GoebelIntegration mit BizTalk Server, Sunato-Press

Gaming Freak

In vielen Kundenprojekten haben wir die Herausforderung, dass BizTalk-Mappings eine gewisse Flexibilität zur Laufzeit erfordern. Es gibt mehrere Ansätze, wie diese Flexibilität gewährleistet werden kann. In unseren Projekten haben wir über den BizTalk-Tellerrand hinausgeschaut und uns eine innovative Technologie aus dem Gaming-Kontext zu Nutze gemacht.  In diesem Beitrag möchten wir gerne beschreiben, wie wir zur dieser Technologie gekommen sind und was die Ergebnisse sind.

Viel Spaß beim Lesen!

Ausgangspunkt

Im Standardfall werden Mappings vom Entwickler nach Mappingvorgaben des Kunden erstellt und gegen statische Inhalte getestet.  Nach einem erfolgreichen Test werden Mappings mit der Lösung  ausgeliefert. Oft müssen Mappings aber im laufenden Betrieb umkonfiguriert werden, weil sich Kundendaten oder Formate schnell ändern. Eine solche Anforderung führt zur Änderungen an den Mappings und zum Redeployment der Lösung. Dies ist mit einer gewissen Downtime des Gesamtsystems verbunden oder führt zu komplizierten Deployments in der Produktion. In der Entwicklungsumgebung kann eine solche Situation zum Restart von Visual Studio führen, was die Produktivität des Entwicklers nicht steigert…

 

Lösungsansatz

Um der oben genannten Situation vorzubeugen, können die Mappings so erstellt werden, dass Mapping-Anweisungen teilweise als dynamische Konfiguration ausgelagert werden. Dafür sind einige klassische Lösungsansätze bekannt:

  • Auslagerung von Mapping-Werten
    • in der Registry,
    • in einer Config-Datei,
    • in einer Datenbank,
  • Auslagerung von Mappingfunktionen in .NET-Dlls / Helper.

Bei der Auslagerung von Mapping-Werten wird aus unserer Sicht das Problem nur zur Hälfte gelöst, da wir nur Werte und nicht das eigentliche Verhalten eines Mappings auslagern. Dazu kommt der Overhead zum Lesen der Daten aus einer Datenbank oder das der Registry.

Bei der Auslagerung von Mappingfunktionen in  .NET-Dlls / Helper können zwar Werte und Mapping-Verhalten ausgelagert werden, das Problem mit dem Redeployment (mehrere DLL-Versionen, GAC-Deployment, Visual Studio Restart etc.) bleibt aber bestehen.

Es stellt sich deshalb die Frage, welche Wege es noch gibt, um ein Mapping zur Laufzeit schnell und einfach zu konfigurieren.

Eine elegante Antwort liefern die aktuellen Gaming-Technologien. Diese setzen für flexible Konfigurationen insbesondere im UI-Bereich auf die Verwendung von dynamischen Skriptsprachen wie z.B. Lua (alternativ JavaScript, Python etc.). Verhalten und Werte von Oberflächen werden dem Spiel zur Laufzeit durch das Ausführen eines Konfigurationsscripts vorgegeben.

Mit einigen Handgriffen funktioniert dieser Ansatz auch im BizTalk Kontext. Das zu dynamisierende Verhalten lagern wir in eine externe Script-Datei aus. Damit diese aus BizTalk-Mappings aufgerufen werden kann, muss ein C#-Wrapper erstellt werden, welcher die Script-Datei mit Parametern aus dem Mapping aufruft und das Ergebnis an das Mapping zurückliefert. Für die Erstellung eines C#-Wrappers wird ein C# Interpreter für die jeweilige Skriptsprache benötigt, in diesem Fall MoonSharp.

Dadurch haben wir eine stabile Schnittstelle zwischen einem BizTalk-Mapping und der Script-Datei geschaffen. Auf dieser Weise können Änderungen im laufenden Betrieb schnell und einfach durch Änderungen oder Austausche der Script-Datei umgesetzt werden.

Im folgendem stellen wir ein kleines Beispiel prototypisch vor.

 

Anwendungsbeispiel

Folgendes Lua-Script implementiert eine Filter-Funktion innerhalb eines Mappings. Die Filterwerte sowie das Verhalten des Filters können zur Laufzeit geändert werden.

Der Script wird vom folgenden C#-Wrapper aufgerufen.

BizTalk C#-Wrapper

Die Anbindung des Scripts im Mapping erfolgt im grafischen Mapper aus Visual Studio.

BizTalk Mapping

Die Erstellung von Lua-Scripts ist via Visual Studio mit dem Lua Plugin komfortabel möglich.

Abschließende Worte

Die Performance von Lua-Script hat bei meinen Tests keinen negativen Unterschied zu C# Code gezeigt und wurde somit von uns für den produktiven Einsatz beim Kunden freigegeben.

Weiterführende Links

http://www.moonsharp.org/

https://www.lua.org/

http://gamedev.stackexchange.com/questions/73728/how-does-lua-work-as-a-scripting-language-in-games