SQL Practice Blog – SQL Server, BizTalk und .NET Erfahrungen

Archive for the ‘BizTalk’ Category

BizTalk Open Space in München

leave a comment »

Nach langer Bloggerabwesenheit möchte ich mich nun mal wieder mit einer interessanten News melden. Am 04. – 05.09.2010 veranstalten wir einen BizTalk Open Space in München.

Wir möchten zu diesem Wochenende alle BizTalk Entwickler, Architekten oder einfach nur Interessierte einladen um mit uns über BizTalk, SOA, BPM und Integrationslösungen im Allgemeinen zu reden. Der Open Space ist eine Unkonferenz, das bedeutet es wird keine festen Sprecher, Themen und auch kein starres Programm geben. Es wird über das geredet, was euch interessiert und wo ihr Problemen, Ideen oder Lösungen habt. Jeder ist willkommen beim BizTalk Open Space! Wer auch immer kommt ist der Richtige! Es gibt keinen Eintrittspreis, jedoch freuen wir uns, wenn ihr uns mit einer Spende unterstützen würdet.

Um an diesem Wochenende doch ein wenig Struktur hereinzubringen, haben wir folgende Themengebiete erstellt:

  • BizTalk 2010
  • EAI / SOA
  • Enterprise Service Bus
  • LOB Adapter
  • Cloud Computing
  • WF 4.0 / WCF 4.0
  • Deployment

Natürlich dürft ihr auch eigene Themengebiete einbringen. Es gibt keine Einschränkungen! Am Samstagabend wird es ein geselliges Beisammensein geben in einer der vielen Kneipen in München.

Euer Interesse ist geweckt? Mehr Informationen findet ihr auf unserer BizTalk Open Space Seite. Meldet euch doch am besten gleich an (Anmeldung)! 🙂

Advertisements

Written by Robert Meyer

Juni 29, 2010 at 21:34

Veröffentlicht in BizTalk, Sonstiges

Tagged with , , , ,

Dokumentation von BizTalk Solutions

leave a comment »

Ich werde immer häufiger gefragt, wie man am besten eine BizTalk Anwendung dokumentiert. Aus meinen Erfahrungen heraus reichen hierfür im wesentlichen zwei Programme von Microsoft und ein ganz klassisches Werkzeug:

  • Microsoft Word
  • Microsoft Visio
  • Flipchart oder Whiteboard

Bevor man mit der Entwicklung einer BizTalk Anwendung beginnt, sollte man sich im klaren darüber sein welche Probleme die Anwendung lösen soll und vor allem welche Systeme und Softwareprodukte in die Lösung integriert werden sollen. Hierzu empfiehlt es sich die gegebenen Anwendungen und Systemlandschadt auf einem Flipchart oder Whiteboard aufzuzeichnen. Wieso sollte dies nicht Initial in Visio geschehen? Es ist bewiesen das Menschen unkreativer und auf die technischen Möglichkeiten des Programms das sie nutzen fixiert sind, wenn sie am Computer arbeiten. Deswegen einfach das Notebook mal zu Seite stellen, sich einen Stift nehmen und seiner Kreativität und Ideen freien lauf lassen. Man wird bei Zeiten merken das gerade wenn man diese Arbeit mit mehreren Personen durchführt, sehr interessant und auch gute Lösungsansätze ent-stehen werden, welche allein am Computer so evtl. nicht möglich gewesen wären.

Dokumentation der BizTalk Architektur

Wer die Systemlandschaft bzw. die Architektur der BizTalk Anwendung danach gern in Visio darstellen möchte, dem kann ich folgende Visio Shapes empfehlen:

Alle Visio Shapes funktionieren auch mit Visio 2010.

image

Dokumentation der Geschäftsprozesse (BPM)

Die Dokumentation von Prozessen kann man besten über Microsoft Word und Visio realisiert werden. Die textuelle Beschreibung der Prozesse inkl. der Akteure geschieht am besten in Word. Die Prozesse selbst lassen sich dann super mit der Hilfe der Unified Modeling Language (UML) und einen Aktivitätsdiagramm abbilden. Das Zusammenspiel von Akteuren und verschiedenen Prozessen, lässt sich mit Hilfe eines UML Sequenz-diagramms darstellen.

Automatische Dokumentation einer BizTalk Anwendungen

Es gibt natürlich auch die Möglichkeit eine bestehende BizTalk Anwendung automatisch dokumentieren zu lassen. Die .NET Entwickler kennen ähnliche Ansetze aus der .NET Entwicklung, wo man mit Hilfe von Sandcastle automatisch eine .chm Datei erzeugen kann. Diese .chm Datei ist von der Struktur her, nach der Architektur der Anwendung erstellt und beinhaltet alle Klassen und deren Methoden inkl. der Summary –Dokumentation und Parameter der Funktionen.
Den gleichen Ansatz gibt es auch für BizTalk. Hier werden alle Artefakte und Assemblies dokumentiert, wobei hier auch die Inhalte der Beschreibungsfelder der einzelnen Artefakte mit einbezogen werden. Die Ausgabe der Dokumentation kann als Windows Help File oder HTML Website geschehen.
Des Weiteren ist es möglich neben den normalen Artefakten auch alle Messaging Komponenten und die Business Rules mit Hilfe der Tools zu dokumentieren.

image
Folgende Tools kann ich besonders empfehlen und funktionieren auch schon mit dem BizTalk Server 2010:

Ich hoffe damit einen kleinen Überblick über die Dokumentationsmöglichkeiten und –Werkzeuge des BizTalk Servers gegeben zu haben.

Written by Robert Meyer

Juni 3, 2010 at 10:28

Veröffentlicht in BizTalk

Tagged with , , , , ,

BizTalk Server 2010 Beta erschienen

leave a comment »

Endlich ist es soweit! Viele BizTalk Entwickler warten sicher schon eine ganze Weile auf den Tag, an die erste offene Beta des BizTalk Server 2010 erscheinen wird. Heute ist dieser Tag!
Aber Moment mal! Wieso BizTalk Server 2010 und nicht 2009 R2? Die Lösung ist wie so oft äußerst simple. Microsoft hat beschlossen das der nächste BizTalk Server nicht 2009 R2 genannt werden soll, sondern 2010, damit es deutlich wird das er eine Interaktion mit den 2010er Produkten erlaubt. Da wäre z.B. SQL Server 2008 R2, SharePoint 2010, Office 2010 und natürlich Visual Studio 2010 mit dem .NET Framework 4.0.

Aber was genau sind nun die Neuerungen des BizTalk Servers 2010? Hier ein kurzer Überblick, welchen ich in Zukunft sicher noch verfeinern werden.

  • Verbessertes Trading-Partner Management
  • Ein neuer und übersichtlicherer BizTalk Mapper mit Suchfunktionen
  • Ein Management Dashboard zum einfachen Sichern und Wiederherstellen von Daten (Compressed Backup ist nun möglich!)
  • Es wird endlich einen FTPS Adapter geben
  • Integration in die WF 4.0
  • ESB Toolkit 2.1 Beta
  • Upgrade von BizTalk Server 2006R2 bzw. BizTalk Server 2009 problemlos möglich!
  • Und vieles mehr!

Den Download des BizTalk Servers findet ihr hier im Downloadbereich von Microsoft. Wer mehr Informationen in Form von Webcast zu AppFabric RC und BizTalk 2010 haben möchte, wird auf dem Microsoft Application Infrastructure virtual launch event fündig 🙂

Ich werde in den nächsten Tagen sicherlich noch einige Erfahrungen, welche ich mit dem BizTalk Server 2010 machen konnte, posten!

Written by Robert Meyer

Mai 20, 2010 at 18:28

Veröffentlicht in BizTalk

Tagged with , , ,

Kopieren von Assemblies in den GAC mit dem Post-Build Event

leave a comment »

Heute stand ich mal wieder vor dem leidigen Problem ein Assembly dem Global Assembly Cache (GAC) hinzufügen zu müssen. Dieses Szenario ist wohl jedem BizTalk Entwickler bestens bekannt. Man baut sich eine Helper-Klasse mit diversen Funktionen wie z.B. Datenbankzugriff, Berechnungsfunktionen oder Zugriffs-funktionen auf entfernte Systemlandschaften um die Funktionalität von BizTalk zu erweitern.

Möchte man dieses Assembly nun von einem BizTalk Artefakt z.B. einer Orchestration aus aufrufen, so setzt BizTalk voraus das sich dieses Assembly, mit einem Strong Name Key versehen, im GAC befindet. Jetzt kann man einfach nach jedem erfolgreichen kompilieren das Assembly händig in den GAC ziehen oder ein Batch starten der dies erledigt. Viel einfacher ist es jedoch das Assembly mit einem Post-Build Commandline Event direkt nach dem kompilieren in den GAC zu kopieren.
Hierfür bedienen wir uns dem GACUtil aus dem Visual Studio SDK, welches eben für solche Tätigkeit zuständig ist.

Das Script dafür ist äußerst einfach:

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i $(TargetPath)

Wer sich jetzt nicht ganz sicher ist, wo er diese Befehlszeile unterbringen soll, kann sich an diesem Screenshot orientieren.

image

Mit der Eigenschaft Run the post-build event: On successful build, kann man sichergehen das dieses Assembly wirklich nur in den GAC kopiert wird, wenn es erfolgreich kompiliert wurde.

Written by Robert Meyer

Mai 18, 2010 at 20:17

Veröffentlicht in BizTalk

Tagged with , , ,

BizTalk Server: Properties in Dateinamen verwenden

leave a comment »

Ich stand heute vor dem Problem, das ich einen Teil der Inhalte einer XML Datei, welche ich mit BizTalk eingelesen habe, bei der Ausgabe im Dateinamen mit unterbringen wollte.

Wenn man in BizTalk einen Send Port mit dem FILE Adapter definiert, so steht im Feld des Dateinamens folgendes: %MessageID%.xml. Hier hat man als Entwickler die Möglichkeit neben dem MessageID Makro auch noch folgende Makros einzusetzen:

Makro

Definition

%datetime%

Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).

%datetime_bts2000%

UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).

%datetime.tz%

Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).

%DestinationParty%

Name of the destination party. The value comes from the message context property BTS.DestinationParty.

%MessageID%

Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.

%SourceFileName%

Name of the file from where the File adapter read the message. The file name includes the extension and excludes the file path, for example, Sample.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if a message was received on an adapter other than the File adapter, the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).

%SourceParty%

Name of the source party from which the File adapter received the message.

%SourcePartyQualifier%

Qualifier of the source party from which the File adapter received the message.

%time%

UTC time in the format hhmmss.

%time.tz%

Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).

 

Möchte man jedoch den Wert eines Elements der eingelesenen XML Datei, wie z.B. den Firmennamen, mit im Dateinamen unterbringen, ist man schnell an den Grenzen der Makros angekommen. Hierfür gibt es jedoch einen ganz einfachen Trick. Dazu muss man wissen das die Makros wie SourceFileName oder MessageID eigentlich nichts anderes sind als Properties eines PropertySchemas.
Als BizTalk Entwickler könnte man jetzt auf die folgende Idee kommen. Man legt im XSD Schema der eingehenden Nachricht ein PropertyPromotion Schema fest, welches z.B. für die bestehenden Makros genutzt wird. Ganz konkret werden wir das Makro %SourceFileName% überschreiben.

  1. Man klickt in dem gewünschten XSD Schema mit der rechten Maustaste auf Schema und wählt dort unter dem Menupunkt Promotion einfach Show Promotion aus.
  2. In dem sich nun öffnenden Fenster selektiert man den Reiter Property Fields und klickt auf das Ordnersymbol um ein bestehendes PropertySchema zu öffnen.
  3. In dem folgenden Fenster wählt man den Punkt References und dann Microsoft.BizTalk.GlobalPropertySchemas aus und selektiert das Schema FILE.bts_file_properties.
  4. Nun befindet man sich wieder in dem Fenster mit dem Reiter Property Fields und fügt der unteren Liste das gewünschte Feld aus dem Schema hinzu. Dann wählt man in der unteren Liste für den eben hinzugefügten Eintrag die Node ReceivedFileName aus. Auf diese Node greift das Makro
    %SourceFileName%  zu, welches wir jetzt im Filename des Adapter verwenden und damit den Inhalt einer Property der XML Nachricht im Filename verarbeiten können.

Manchmal kann man dem BizTalk Server eben nur mit Tricks beikommen 🙂 Dieser Trick funktioniert mit dem BizTalk Server 2006 und 2009.

Written by Robert Meyer

Mai 11, 2010 at 15:05

Veröffentlicht in BizTalk

Tagged with , , , ,

BizTalk Server 2009: Failed message routing

leave a comment »

Es gibt bei dem BizTalk Server zwei Wege um fehlgeschlagene Nachrichten abzufangen. Standardmäßig werden fehlgeschlagene Nachrichten in der MessageBox als Suspended Items abgelegt, welche unter bestimmten Bedingungen fortgesetzt werden können.

Seit dem BizTalk Server 2006 gibt es noch einen weiteren Weg fehlgeschlagene Nachrichten zu verarbeiten. Hier ist es möglich korrupte Nachrichten über einen Send Port oder eine Orchestration an einem Ort außerhalb der MessageBox zu sammeln. Dies ist besonders sinnvoll, wenn öfters fehlerhafte Nachrichten erwartet werden und diese nicht die MessageBox voll laufen lassen sollen bzw. die fehlerhafte Nachricht bearbeitet werden soll.

Um dies zu aktivieren öffnet man einen beliebigen Receive Port und markiert die Option “Enable routing for failed messages”. Standardmäßig ist dieses Checkbox nicht markiert.

image

Ist diese Checkbox markiert, so werden einige Properties promoted.

  • ErrorReport.ErrorType
  • ErrorReport.Description
  • ErrorReport.FailureCode
  • ErrorReport.MessageType
  • ErrorReport.ReceivePortName
  • ErrorReport.SendPortName
  • ErrorReport.InboundTransportLocation
  • ErrorReport.OutboundTransportLocation
  • ErrorReport.RoutingFailureReportID

Als nächsten Schritt können die fehlerhaften Nachrichten in einer Orchestration oder einem Send Port verarbeitet werden. Dazu können die Nachrichten z.B. über die Promoted Properties auf verschiedene Ziele / Orchestrations verteilt werden. Im folgenden Screenshot sieht man eine Filterkonfiguration eines Send Ports der fehlerhafte Nachrichten eines speziellen Receive Ports weiterleitet.

image

Written by Robert Meyer

Mai 4, 2010 at 09:00

Veröffentlicht in BizTalk

Tagged with , , ,

Unit Tests mit dem BizTalk Server 2009

leave a comment »

Es ist mal wieder an der Zeit einen technologischen Blog Post zu schreiben. Nachdem ich den ganzen Vormittag über mit Unit Tests für BizTalk Server 2009 Projekte verbracht habe, was würde sich da besser anbieten als darüber gleich einen Blogeintrag zu schreiben.

Mit dem BizTalk Server 2009 und Visual Studio 2008 ist es Entwicklern möglich für ihre BizTalk Projekte Unit Tests zu schreiben. Hierbei werden logischer Weiße nicht die Projekte sondern die Artefakte in den Projekten getestet. Wenn wir von Artefakten reden, meinen wir damit Schemas, Maps und Pipelines.
Im Prinzip ist das Erstellen von Testprojekten recht identisch mit dem Erstellen von normalen Testprojekten für .NET Anwendungen. Hierbei kommt standardmäßig Microsofts Testframework MSTest zum Einsatz. Alternativ kann aber auch z.B. NUnit genutzt werden.

projektmappe Um die Komplexität des Blogeintrages ein wenig in Grenzen zu halten, werde ich mich hier nur auf das Testen von Schemas und Maps beziehen.
Wir starten mit der Projektstruktur, welche auf dem linken Screenshot zu sehen ist.

Hierbei handelt es sich um vier BizTalk Projekte. OrderSystem.Maps beinhaltet alle Maps der Applikation, OrderSystem.Messaging verwaltet alle Message Schemas für die BizTalk Applikation, OrderSystem.Processes ist für die Orchestrations zuständig und OrderSystem.Services beherbergt alle Komponenten für den Zugriffe aus diverse WCF Services. Uns interessieren hierbei jedoch nur die Projekte OrderSystem.Maps, OrderSystem.Messaging und OrderSystem.Tests, in dem sich die Unit Tests später befinden werden.
Wir arbeiten hierbei mit zwei Schemas, eine InputOrder.xsd (Eigehende Bestellung) und eine OutputOrder.xsd (Bearbeitete Bestellung). Desweiteren haben wir in unserem Beispiel noch eine Map, welche die beiden Schemas verbindet.

Aktivieren_UnitTestsBevor ich bei BizTalk Server 2009 Projekten mit dem implementieren für Unit Tests beginnen kann, muss ich die Projekten erst richtig kon-figurieren. Dazu markiere ich mein BizTalk Projekt mit der rechten Maustaste und gehen in die Eigenschaften des Projekts. Unter dem Punkt Bereitstellung (Deployment) muss ich das KeyValue Pair Komponententests aktivieren auf True setzen. Dies muss ich bei jeden BizTalk Assembly tun, welches von den Unit Tests betroffen ist. Sollte ich dies vergessen, so stehen mir zum Zeitpunkt der Implementierung des Tests wichtige Testfunktionen nicht zu Verfügung.

Als nächsten Schritt sollte man ein Test Projekt in Visual Studio anlegen, falls dieses noch nicht existieren sollte. Am einfachsten geht das, wenn man ein BizTalk Projekt markiert und über die Visual Studie Menuleiste auf Tests und dann Test erstellen klickt. Als erstes muss man nun in dem Testprojekt alle benötigten Abhängigkeiten zu euren BizTalk Anwendungen und sonstigen Assemblies einpflegen. Was wird neben euren Projekten noch benötigt? Ihr benötigt unbedingt noch die Microsoft.BizTalk.TestTools und die Micrososft.XLANGs.BaseTypes. Solltet Ihr Pipelines testen wollen, so benötigt ihr außerdem noch die Assemblies Microsoft.BizTalk.Pipeline und Microsoft.BizTalk.PipelineOM.

Das Testen von Schemas

Zum Testen von Schemas benötigt ihr immer eine Inputinstance, dies kann eine native Datei oder eine XML Datei sein. Je nachdem welches Schema man testen möchte. Danach wird eine neue Instance des Schemas erstellt (Achtung! Referenz muss vorhanden sein!), welche dann über die Funktion ValidateInstance prüft ob sie mit der Inputinstance identisch ist. Das ganze sieht im Code dann so aus:

Schema_UnitTest

Das Testen von Maps

Bei dem Testen von Maps ist das Vorgehen ganz ähnlich. Hierzu benötigt man ebenfalls eine InputInstance welche dem Source Schema der Map entspricht. Diese übergibt man der vorher instanziierten Map und bekommt ein OutputSchema zurück, welches man im TestRun Order speichert. Nun muss der selbe Testschritt wie bei den Schemas durchgeführt werden, in dem geprüft wird ob die zurückgegebene Instanz zu dem erwarteten Schema passt. Sollte in dem Mapping ein Fehler auftreten, so sieht der Entwickler das nicht direkt, sondern erhält eine leere Datei als OutputInstance. Deshalb prüft man am Ende diese Datei nochmal gegen das erwartete Schema. Das ganze schaut aus wie folgt:

Map_UnitTest

Hierbei gilt es zu beachten, wenn man Beispielsweise in der Map eine Source aus zwei oder mehr Schemas hat, welche auch noch über verschiedene Projekte verteilt sind, so kann es bei den Test der Maps zu Problemen kommen.

Fazit

Mit Unit Tests ist es auch in BizTalk Server Projekten möglich seine Komponenten einzelnen oder als gesamtes Paket zu testen. Dieser Mehrwert rückt vor allem stark in den Vordergrund wenn eine Team Foundation Server im Einsatz ist, welcher die Tests Automatisiert durchführt. Dies kann die Zusammenarbeit in großen und kleinen Teams ungemein bereichern.

Written by Robert Meyer

März 5, 2010 at 16:26

Veröffentlicht in BizTalk

Tagged with , , ,