Custom Pipeline Components - Update

Seit meinem ersten Eintrag zum selber schreiben von Custom Pipeline Components (http://justacodeblog.blogspot.com/2008/05/custom-pipeline-components-wizard.html) hab ich inzwischen soviel Erfahrungen zu dem Thema gesammelt, das ich hierzu ein Update verfassen muss.

Ein paar Anmerkungen zum arbeiten mit Martijn Hoogendoorn's Component Wizard und Pipeline Komponenten generell:

- Der Beste Ansatz um die erstellten Komponenten stressfrei zu deployen und in der Toolbox des Pipeline Projektes zu verwenden ist es die fertige DLL Komponente: 1.) in den GAC zu deployen 2.) in das Pipeline Component Verzeichnis von Biztalk zu deployen (z.B.: C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components) Beides kann man gut im Post Built Event erledigen z.B. wie folgt (für 64Bit Windows mit angepasst, darum die relativen Pfade) "$(DevEnvDir)..\..\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetPath)" xcopy "$(TargetPath)" "$(DevEnvDir)..\..\..\Microsoft BizTalk Server 2006\Pipeline Components" /R /Y

- Log4Net und 64Bit Windows können Probleme in Verbindung mit der Biztalk Toolbox Erkennung bereiten. Dabei kann entweder die korrekte Namenserkennung der Komponente, oder gar die komplete Komponenten Erkennung fehlschlagen. Das Problem vermute ich in den Windows Sicherheitseinstellungen (?). Ansonsten hilft als "Workaround" nur das komplette Entfernen von Log4Net aus der Komponente

- Beim Umbennen einer Pipeline Komponente (Namespace und/oder Klassenname) muss man zwei weitere Punkte beachten für die korrekte Anzeige in der Toolbox später. 1.) Unterhalb der Kompenenten Klassendeklaration wird der Name registriert:

   1:  private System.Resources.ResourceManager resourceManager = new System.Resources.ResourceManager(

   2:      "<Namespace>.<Pipeline Komponenten Name>",

   3:      Assembly.GetExecutingAssembly());

2.) Im Ressource File selbst: COMPONENTNAME = <Namespace>.<Pipeline Komponenten Name>

- Für einen rundimentären Test ist das pipeline.exe Tool selbst eine schnelle und schöne Sache. Jedoch empfiehlt es sich unbedingt auch eine BizTalk Test Orchestration zusammenzuklicken! Der Umstand ist simpel. Während die pipeline.exe unsere Komponente direkt aus dem lokalen Filesystem aufruft, wird in BizTalk ein COM Aufruf ausgeführt! Dies verändert den Kontext in dem sich der Stream befindet, den man gerade verarbeitet! Simples Beispiel: solange man über die pipeline.exe testet, kann der Stream nach FileStream gecastet werden, um z.B. den File Namen auszulesen. Führt man den selben Aufruf in BizTalk aus, sind die FileStream Informationen gar nicht mehr vorhanden. Ein Cast schlägt fehl!

- Für das Testen mit der pipeline.exe empfiehlt es sich eine eigene Solution Konfiguration anzulegen (z.B. Debug Pipeline). In den Projekteigenschaften konfiguriert man dann unter Debug:

• Start external program: <pfad zum Pipeline Test Tool>\Pipeline.exe
• Command line arguments z.B.: -pt <namespace>.<biztalk pipeline orchestration> -an <custom pipeline component name>-d <input flatfile> -v
• und ggf. noch die Working directory anpassen wenn nötig

(nicht vergessen bei einer neuen Solution Konfiguration unter der Projekteigenschaft Build - Advanced Button die Debug Info mit erzeugen zu lassen (full))

- Bei der Implementierung ist darauf zu achten das BizTalk die Pipeline bei hoher Last automatisch parallel ausführt!! D.h. VORSICHT beim Umgang mit z.B. statischen Elementen, wer nicht darauf verzichten kann, muß Threadsicher programmieren!