Inhalt
5 Praktische Durchführung
5.1 Erstellen eines Anforderungskatalogs
Gemeinsam mit den Verantwortlichen der BTC wurde eine Liste mit Anforderungen ausgearbeitet, die an das System BizTalk Server gestellt werden. Die komplette Liste ist im Anhang A zu sehen, hier soll nur auf die wichtigsten Punkte davon eingegangen werden. Diese sind entscheidend für einen Einsatz von BizTalk Server im Projekt eBridges.
a.) Die Systemanforderungen müssen zur bestehenden IT-Landschaft der BTC passen.
b.) Administration und Konfiguration des Systems müssen mit wenig Einarbeitungszeit und ohne großen Aufwand möglich sein.
c.) Das System muss mit einem Minimum an Wartung stabil und performant laufen. Auftretende Lastspitzen müssen zuverlässig abgearbeitet werden, ohne den Betrieb dauerhaft zu beeinträchtigen.
d.) Das System muss mit Flatfiles und XML-Dateien umgehen können und sollte Daten per FTP, Email und SQL empfangen und senden können. Weitere Adapter - beispielsweise zur Verwendung von OFTP - sollen nachrüstbar sein. Vorteilhaft wäre auch die Behandlung von anderen Dateien wie Office oder PDF.
e.) Das Einspielen von neuen Geschäftslogiken muss in einem einfachen Vorgang machbar sein und darf den aktiven Ablauf nicht beeinflussen.
f.) Die Anbindung an das ERP-System Microsoft Business Solutions Navision ist besonders wichtig.
g.) Während Daten das System durchlaufen, sollen diese verarbeitet und unter anderem auf inhaltliche Plausibilitäten überprüft werden können.
h.) Ein weiterer Aspekt ist die Sicherheit der Daten und die Zugriffsberechtigungen.
Der Anforderungskatalog enthält sowohl Kriterien, die das System einhalten muss, als auch weitere Aspekte und Fragen, die überprüft werden sollen. Hierfür boten sich je nach Art der Anforderung verschiedene Methoden an. Es wurden die vorhandene Literatur und Systemdokumentationen verwendet, um die benötigten Informationen zu erhalten. Aufbauend auf den Fragen wurden außerdem die Testszenarien ausgearbeitet, die in Teilaufgabe 4 umgesetzt wurden.
5.2 Aufbau und Konfiguration einer Testumgebung
Zunächst musste eine Testumgebung aufgebaut werden, um alle Anforderungen der Diplomarbeit umsetzen zu können. Hierzu wurden alle Programme auf einem einzigen Rechner installiert. Dies entspricht aus Performancegründen nicht der üblichen Vorgehensweise in einem Produktivsystem, vereinfacht das Vorhaben zunächst aber deutlich und ist für diese Testzwecke völlig ausreichend. Die Installation in einer verteilten Umgebung erfolgt ähnlich. Die Vorgehensweise richtete sich in den Grundzügen nach der von Microsoft gegebenen Anleitung.
Aufgrund ihrer Erfahrungen gab das MBSP die Empfehlung, alle betroffenen Programme soweit möglich in der englischen Variante zu verwenden. Dies verhindert Probleme beim Zusammenspiel unterschiedlicher Sprachversionen, die vor allem auftreten könnten, wenn BizTalk Server und SQL Server in verschiedenen Sprachen installiert sind. Außerdem ist ein besserer Support gewährleistet, da Patches und Updates für die englische Version meist schneller verfügbar sind als für andere Sprachversionen. Dieser Empfehlung wurde nachgegangen, ohne den Sachverhalt weiter zu prüfen.
Betriebssystem
Als Betriebssystem diente eine Testversion von Windows 2003 Server. Nach der Standardinstallation bekam dieses als Rolle "Application Server" mit der Option ASP.NET und ohne die Frontpage-Serverextensions zugewiesen. Schließlich wurde der Rechner in die BTC-Domäne des Active Directory aufgenommen und das Windows Update mit allen zur Verfügung gestellten Komponenten durchgeführt. Für alle diese und weiteren Tätigkeiten wurde das lokale Benutzerkonto "Administrator" verwendet.
SQL Server
Der nächste Schritt war die Installation einer Trialversion von Microsoft SQL Server 2000 Release A, das man von der Microsoft Internetseite herunterladen kann. Um alle Monitoring- und Debuggingmöglichkeiten des BizTalk Servers verwenden zu können, wurden auch die SQL Analysis Services installiert.
Damit SQL Server auf Windows 2003 Server einwandfrei funktioniert, mussten noch die SQL Server Service Packs 3a für SQL Server und SQL Server Analysis Services installiert werden.
BizTalk Server
BizTalk Server setzt mindestens folgende Komponenten voraus, die daher im nächsten Schritt installiert wurden:
* SQLXML 3.0 SP2
* MSXML 4.0 SP 2 (nur Parser, ohne SDK) und MSXML 3.0 SP 4
* Patch zu MS Knowledge Base Articles 838166 und 831950, damit BizTalk Server und SQL Server zusammenspielen
* Für das Health- und Activity-Tracking wird MS Office XP Tool: WebComponents (OWC10) benötigt
Einige Komponenten sind bei BizTalk Server zwar mitgeliefert, mussten aber vor Benutzung extra installiert/aktiviert werden. So beispielsweise ein Generatortool, das aus gegebenen DTD-Dateien dazu passende XML-Schemata generiert.
Es folgte die eigentliche Installation von BizTalk Server. Auch hierfür wurde eine Testversion gewählt, die bei Microsoft herunterzuladen ist. Das Installationsprogramm bietet im "Custom"-Modus eine Auswahl an Komponenten, die man installieren kann. Hier wurden die Punkte "Development" und "Business Activity Services" deaktiviert. Development fügt die BizTalk-Editoren einer vorhandenen Installation von Visual Studio hinzu, welche hier jedoch noch nicht vorhanden war. Die Business Activity Services wurden in dem Projekt nicht eingesetzt und daher auch nicht installiert.
Das Installationsprogramm benötigt ansonsten keine weiteren Eingaben. Nach dem Abschluss der Installation startet automatisch der BizTalk Configuration Wizard. Hierin wurden die meisten Standardeinstellungen übernommen. Das Konfigurationsprogramm legt die vorgeschlagenen Benutzergruppen automatisch auf dem Installations-PC an. In einer verteilten Umgebung muss man diese zusätzlich manuell auf dem SQL-Server oder im Active Directory anlegen. Als Benutzerkonto für die Services wurde jeweils das lokale Administratorkonto angegeben.
Zum Abschluss wurde noch das BizTalk Server Service Pack 1 installiert.
Microsoft Business Solutions - Navision
Für ein funktionsfähiges Navision-System wurden zwei Komponenten der Software Microsoft Business Solutions Navision installiert: Navision Server und Navision Client, beide in der aktuell von der BTC Germany eingesetzten Version 3.70B und auch beide in der deutschen Sprachversion.
Die Installation des Servers benötigte keine weiteren Angaben. Die Installation des Clients muss "benutzerdefiniert" ablaufen. Hier kann die Demodatenbank deaktiviert werden. Der Punkt "Commerce Integration" ist zwingend notwendig.
Der Vertriebsservice stellte eine Datenbankdatei zur Verfügung, die einen Teil der Produktivdatenbank enthält. Mit dem Menüpunkt Datei --> Datenbank öffnen im Navision Client musste der Pfad zu dieser Datei ohne Angabe eines Datenbankservers eingetragen werden. Da diese Datenbankdatei nicht auf dem aktuellsten Stand war, wurden manuell nachträglich einige Datenbankobjekte importiert.
Die Verbindung zwischen dem Navision-System und BizTalk Server stellt man ebenfalls über den Navisionclient ein. Zu jedem Client, der auf einem anderen PC installiert ist als der BizTalk Server, muss schließlich noch ein Patch in Form einer Windows-Registrierungsdatei eingespielt werden. Dieser ist jedoch nicht im Internet verfügbar, sondern wurde vom MBSP zur Verfügung gestellt.
Commerce Gateway Request Server
Die Installation des Commerce Gateway Request Server (CGRS) erfolgte mit allen vorgegebenen Einstellungen. Da dieser zum Navisionsystem gehört, befindet sich die Installationsdatei auch auf der Navision-CD.
Zu Beachten ist hierbei, dass der Dienst standardmäßig im Benutzerkontext "Local System" läuft. Dieses musste über die Windows-Diensteverwaltung geändert werden in einen Benutzer, der Zugriffsrechte auf die SQL Server Datenbank besitzt. Auch hier wurde der lokale Benutzer "Administrator" eingetragen.
Microsoft Visual Studio .NET 2003
Es ist empfehlenswert, Visual Studio als erstes einzurichten, damit das Installationsprogramm von BizTalk Server die dazugehörigen Editoren gleich hier mit einbauen kann. Aufgrund von Lieferschwierigkeiten der Software konnte dies in diesem Fall jedoch erst nachträglich durchgeführt werden.
Die Installation erfolgte genau nach Vorgabe, ohne irgendwelche Einstellungen zu ändern. Zunächst wurden die vorgegebenen Prerequisites installiert, anschließend Visual Studio selbst. Zum Abschluss folgte die Installation der MSDN. Hierin wurden die relevanten Komponenten für eine Installation auf der Festplatte ausgewählt, alle anderen blieben bei der Einstellung "Von CD ausführen".
Abschließend musste in der Systemsteuerung unter "Add or Remove Programs" BizTalk Server ausgewählt und "modify" geklickt werden. Es erscheint erneut eine Auflistung aller BizTalk Komponenten, diesmal konnte der Punkt "Development" angewählt und dadurch nachinstalliert werden.
5.3 Analyse der Ein- und Ausgabedaten
Nachrichtentypen
Die bisher implementierte Lösung überträgt die Nachrichtentypen OrderCreate und OrderResponse zur Bestellungsabwicklung. Weitere Nachrichten, die aufgrund der Häufigkeit ihrer Versendung und der Möglichkeit, sie zu automatisieren, für einen zukünftigen elektronischen Versand geeignet sind, lauten
# OrderChange zum Ändern einer bestehenden Bestellung,
# ShipNotice als Information über eine abgewickelte Lieferung,
# Invoice als elektronische Rechnung und
# verschiedene weitere Nachrichten speziell zur Kommunikation mit Logistikpartnern.
Für die Vorgehensweise im Projekt eBridges gibt es zwei grundsätzliche Möglichkeiten:
A. Zunächst bleibt die bisherige Lösung zum Übertragen von OrderCreate und OrderResponse bestehen und neue Nachrichtentypen werden im Projekt eBridges implementiert. Nach der erfolgreichen Umsetzung dieser Nachrichtentypen folgt erst im zweiten Schritt die Implementierung von OrderCreate und OrderResponse auf der neuen Plattform.
B. Die bisherige Lösung wird ersetzt, indem OrderCreate und OrderResponse auf der neuen Plattform implementiert werden. Die Umsetzung anderer Nachrichtentypen folgt erst im weiteren Verlauf des Projektes, wenn der erste Schritt erfolgreich abgeschlossen ist.
Variante A hätte den Vorteil, dass nach kürzerer Zeit insgesamt mehr Nachrichtentypen elektronisch übertragen werden können. Da die bisherige Übertragung per Flatfile grundsätzlich funktioniert, besteht kein zwingender Grund, diese abzuschaffen. Sie kann weiterhin genutzt werden, während man Erfahrungen mit der neuen EAI-Plattform ebenso mit neuen Nachrichtentypen sammeln kann.
Allerdings wären auf diese Weise zwei unterschiedliche Verfahren zur Datenübertragung parallel im Einsatz. Dies erhöht die Komplexität und den Administrationsaufwand der Gesamtlösung. Weiterhin ist abzusehen, dass in naher Zukunft inhaltliche Änderungen an den bisher übertragenen Nachrichten OrderCreate und OrderResponse durchzuführen sind, da die Lösung den Anforderungen nicht mehr genügt. Diese Änderungen wären bei Variante B nicht mehr nötig, da sie gleich in die neue Lösung mit eingebracht werden können.
Aufgrund dieser Überlegungen ist Variante B eher zu empfehlen. Die endgültige Entscheidung hierüber wird zu einem späteren Zeitpunkt im Projektverlauf anstehen. Unabhängig von der gewählten Variante wird der automatisierte Austausch von Daten mit der BASF nach Implementierung aller oben genannten Nachrichtentypen eine deutliche Erleichterung und Beschleunigung der damit verbundenen Prozesse hervorbringen.
Datenformate
Als Standard zur Datenübertragung in der Chemiebranche hat sich CIDX durchgesetzt. Von den verfügbaren Versionen des CIDX Chem eStandards kommen Version 2.02 in Frage, weil die BASF hauptsächlich diese verwendet, und Version 4.0, weil sie die aktuellste ist.
Neben der Behandlung neuer Nachrichtentypen sind die Unterschiede zwischen den Versionen nicht sehr umfangreich. Die Spezifikationen von Version 4 sind im Gegensatz zu den DTDs der älteren Versionen als XML Schemata erhältlich, wodurch sie präziser werden und mehr Einschränkungen erlauben. Auf der inhaltlichen Seite ist die größte Änderung das Hinzukommen neuer Felder und die Änderung bestehender Felder. Hierdurch können umfangreichere Inhalte flexibler abgebildet werden. So wurde beispielsweise das Feld für die Faxnummer eines Partners entfernt, für die nun das Feld für eine "alternative Kommunikationsmethode" verwendet werden muss. Bei einigen Feldern änderte sich lediglich die Bezeichnung in eine passendere.
Wenn die Anbindung an den Mercator der BASF erfolgt, dann ist es prinzipiell kaum von Bedeutung, in welchem Format die Daten übertragen werden. Denn der Mercator kann als EAI-System genauso wie BizTalk Server ein Mapping in jedes beliebige Format, das bei der BASF benötigt wird, durchführen. In diesem Fall würde der BizTalk Server bei der BTC für dieses Projekt nicht mehr zwingend benötigt werden. Aus mehreren Gründen ist die Verarbeitung über ein eigenes EAI-System dennoch von Vorteil:
+ Das Mapping wird auf einem System im eigenen Haus durchgeführt, wodurch flexibler darin eingegriffen werden kann.
+ Es besteht eine eigene Zugriffsmöglichkeit auf Monitoring-Funktionen.
+ Erweiterte Funktionalitäten und Logik können hier eingebunden werden. Ohne eigene EAI-Software müsste diese in dem ERP-System der BTC oder in das EAI-System der BASF AG eingebunden werden, was beides aufwändigere Optionen sind.
+ Wenn ein System bei der BTC die Daten bereits in ein passendes Endformat umsetzt, entfällt eine weitere Konvertierung im Mercator. Hierdurch wird dieser unter Umständen als mögliche Fehlerquelle ausgeschlossen.
+ Das EAI-System wird für andere Projekte bei der BTC ohnehin angeschafft. Je mehr Projekte es sinnvoll für sich einsetzen, desto eher rentieren sich diese Anschaffungskosten.
Aufgrund der oben genannten Tatsachen ist eine endgültige Entscheidung für ein spezielles Datenformat und den Einsatz von BizTalk Server oder einer anderen EAI-Software an dieser Stelle nicht möglich. Als sinnvolle Lösung wird jedoch der Einsatz von BizTalk Server bei der BTC und Übertragung der Daten im CIDX-Format angesehen, um möglichst viel Funktionalität im eigenen Hause zu haben. Die endgültige Entscheidung kann auch hier erst im weiteren Verlauf des Projektes eBridges getroffen werden.
Elemica
Elemica ist ein Marktplatz der chemischen Industrie, über den Firmen als Käufer und Verkäufer agieren und untereinander elektronische Daten austauschen können.
Die BASF ist über ihr EAI-System Mercator an Elemica angebunden. Dies bedeutet, dass die BTC durch eine Anbindung an den Mercator automatisch auch diese Kommunikationsmöglichkeit über Elemica mitnutzen kann. Hierfür muss allerdings die entsprechende Geschäftslogik implementiert sein, um Nachrichten automatisiert verarbeiten zu können. Die Nutzung von Elemica verursacht auch zusätzliche Kosten, die zu berücksichtigen sind.
Der Datenaustausch über Elemica wird zunächst nicht in das Projekt eingebunden. Allerdings sollte diese Möglichkeit bei Entscheidungen mitbedacht werden, um eine zukünftige Nutzung des Marktplatzes zu erleichtern.
5.4 Durchführen von Tests
5.4.2 Versionierungsverhalten von BizTalk Server
In zukünftigen Projekten, die komplexere Geschäftsprozesse abbilden werden, wird es notwendig sein, auch während des Produktivbetriebes die abgebildete Logik weiterzuentwickeln und zu ändern. Ein wichtiger Aspekt hierbei ist das Verhalten des Systems bei einer Änderung. Falls zum Zeitpunkt der Änderung eine oder mehrere langlaufende Instanzen des Prozesses im System noch nicht zu Ende abgearbeitet sind, weil sie beispielsweise auf weitere Eingabedaten warten, können diese Instanzen unter Umständen nicht mit der neu eingespielten Version weiterarbeiten. Probleme treten auf, da die Daten inkonsistent werden oder sogar kein passender Einsprungpunkt in der neuen Version vorhanden ist. Eine weitere Möglichkeit wäre es, alle Instanzen zu Ende arbeiten zu lassen, bevor Änderungen durchgeführt werden. Bei besonders langlaufenden Prozessen führt dies jedoch zu unerwünschten langen Unterbrechungen des Geschäftsablaufs.
Daher ist es wichtig, dass das verwendete System eine angemessene Versionsverwaltung besitzt. Diese sorgt dafür, dass bestehende Instanzen mit der Logikversion zu Ende geführt werden, mit der sie gestartet wurden. Neue Instanzen verwenden immer die aktuellste vorhandene Version.
BizTalk Server unterstützt dieses Verhalten beim Einsatz des Business Rule Composers (Woodgate et al. 2004, S.331). Es sollte nun untersucht werden, ob dies auch möglich ist, wenn die Prozesslogik direkt in einer Orchestrierung abgebildet ist.
Testszenario
Das folgende Testszenario bietet die Möglichkeit, das Versionierungsverhalten auszutesten. Der Empfang einer XML-Datei, welche den Vor- und Nachnamen einer Person enthält, startet eine Orchestrierung. Innerhalb dieser Orchestrierung bilden Mappingfunktionen aus dem Namen ein dreistelliges Kürzel, welches in einer neu generierten XML-Nachricht abgespeichert wird. Anschließend wartet die Orchestrierung auf die Eingabe einer weiteren XML-Datei, welche das soeben erzeugte Kürzel enthält. Trifft diese Datei ein, kann die Orchestrierung zu Ende laufen und eine weitere Ausgabedatei schreiben. Zur Kontrolle des Ergebnisses wird in dieser Ausgabedatei ein Attribut mit der Versionsnummer der Orchestrierung und der aktuellen Uhrzeit gesetzt.
Es muss definiert werden, welche Dateien zueinander gehören. Schließlich soll es möglich sein, mehrere der Namens-Dateien und anschließenden Kürzel-Dateien zu verarbeiten, wobei eine Namens-Datei jeweils eine neue Instanz des Prozesses startet und die Kürzel-Datei stets einer bestehenden Instanz anhand des darin erzeugten Kürzels zugeordnet wird. Um dies zu erreichen, muss man in der Orchestrierung ein "Correlation Set" definieren. In diesem wird ein Attribut angegeben, anhand dessen die einzelnen Meldungen einander zugeordnet werden können; in diesem Fall ist dies das Kürzel. Bei den Receive- und Sendshapes wird entsprechend eingestellt, ob diese ein neues Correlation Set initialisieren oder ein bestehendes weiterführen.
Versionierung bei Orchestrierungen
Vor dem Generieren einer Assembly aus einem Projekt kann man für dieses jeweils eine Versionsnummer angeben. Diese lässt sich sowohl in der dll-Datei als auch in den Tools des BizTalk Servers auslesen, um unterschiedliche Versionen leicht auseinander halten zu können.
Das Verhalten des Systems unterscheidet sich, je nachdem, ob man die Receive- und Sendports bereits mit der Orchestrierung komplett definiert hat ("specify now") oder diese erst später einrichtet ("specify later").
Wenn die Ports bereits in der Assembly eingerichtet waren, gab es beim Testen am meisten Schwierigkeiten. Beim Einspielen einer neuen Version der Assembly kam eine Fehlermeldung, dass die angegebenen Receivelocations bereits verwendet werden. Diese Meldung kommt daher, dass BizTalk Server neue Receiveports einschließlich den Receivelocations für die neue Assembly anlegen will, welche im Normalfall die gleichen Werte besitzen wie die bereits bestehenden. Beim Stoppen und Unenlist einer aktiven Orchestrierung kann man angeben, laufende Instanzen nicht abzubrechen. Diese konnten jedoch nur mit der gleichen Version wieder aufgenommen werden. Die Assembly beizubehalten und nur die gebundenen Receiveports auf die neue Assembly umzulegen war ebenfalls nicht möglich, solange noch Instanzen bestanden, die nicht komplett abgearbeitet waren.
Beim manuellen Binden der Ports hingegen war es problemlos möglich, zwei verschiedene Versionen der gleichen Assembly gleichzeitig laufen zu lassen. Die alte Orchestrierung durfte nicht entfernt werden, konnte aber gestoppt werden. Es konnten einfach beide Versionen an die gleichen, bestehenden Ports gebunden werden. Trotz des Stop-Status wurden Instanzen, die vor dem Einspielen der neuen Version gestartet wurden, ordnungsgemäß beendet. Ohne eine detaillierte Zuordnung zwischen auslösender und beendender Nachricht anhand Correlation Sets ist jedoch je nach Anwendungsfall auch dieses Verhalten nicht unbedingt gewährleistet.
Wenn eine neue Nachricht ankam, die die Orchestrierung startete, wurde von jeder Version je eine Instanz angelegt. Die Instanz der neuen Orchestrierung wurde normal gestartet und ausgeführt, während die Instanz der alten Version sofort wieder angehalten wurde, da die Orchestrierung ja den Status "Stop" hatte. Daher muss beachtet werden, die alte Orchestrierung nicht mehr zu starten und die angehaltene Instanz manuell zu beenden. Ansonsten treten doppelte Instanzen auf, welche nicht gewünscht sind.
Versionierung bei Business RulesIm nächsten Schritt wurde die Orchestrierung so umgestellt, dass sie separat definierte Geschäftsregeln verwendet. Diese werden mit dem Business Rule Composer aufgestellt. Mehrere Regeln sind zu einer Policy zusammengefasst. Innerhalb der Regeln können unter anderem Attribute aus XML-Dateien ausgewertet und gesetzt werden. Diese XML-Dateien entsprechen Nachrichten, die von der Orchestrierung beim Aufruf der Business Rule übergeben werden. Es wurden zwei Versionen einer Policy erstellt, die beide das Attribut "Version" der übergebenen Nachricht, welche später in die Ausgabedatei geschrieben wird, auf den Wert ihrer Versionsnummer setzten. Somit konnte anhand der Ausgabedatei einfach überprüft werden, welche Version der Policy bis zum Ende der Instanz ausgeführt wurde. Das Ergebnis fiel aus wie erwartet: # Die Instanz, die vor dem Einspielen der neuen Version gestartet und anschließend beendet wurde, wurde mit der alten Version bis zum Ende durchgeführt. # Für eine Instanz, die erst nach dem Einspielen der neuen Version gestartet wurde, wurde die neue Version verwendet. # Bei einem dritten Test wurde zunächst eine Instanz gestartet. Anschließend wurde die neue Version der Policy eingespielt und die alte entfernt. Die betroffene Instanz wurde ordnungsgemäß zu Ende geführt, jedoch mit der neuen Version der Policy. |
|
5.4.3 Möglichkeiten zum Emailversand
BizTalk Server bietet mit seinem mitgelieferten SMTP-Adapter die Möglichkeit, Emails zu versenden. Dies sollte genauer untersucht werden, besonders hinsichtlich des Versandes von XML-Nachrichten und beliebigen anderen Dateien als Emailanhänge.
Testszenario
Für komfortable Funktionen bezüglich Emailversand wird eine kleine Erweiterung benötigt, die sich SMTPUtils nennt und auf vielen Internetseiten zum Thema BizTalk heruntergeladen werden kann (z.B. hier und hier). Diese enthält Methoden zum Verwalten von Emailanhängen und eine RawString-Klasse, welche benötigt wird, um reinen Text - beispielsweise für den Emailtext - zu speichern. Auf die entsprechenden Klassen können BizTalk-Projekte Referenzen enthalten und diese somit verwenden. Sie werden jedoch nicht automatisch mit in die Assembly kompiliert sondern müssen separat im Global Assembly Cache bereitgestellt werden.
Eine eingehende XML-Datei, welche erfundene Mitarbeiterdaten (Vor- und Nachname sowie einen Level) enthält, startet eine Orchestrierung. Diese schreibt zur Kontrolle die Nachricht unverändert in ein Ausgabeverzeichnis. Anschließend wird eine neue Multipart-Message erzeugt, welche aus einem Textteil und einem XML-Dokument besteht. In einem MessageAssignment-Shape in der Orchestrierung weisen einige Codezeilen dem Textteil einen neuen RawString mit dem gewünschten Emailtext und dem XML-Teil die eingegangene Nachricht zu. Zusätzlich setzen sie durch die entsprechende Methode der SMTPUtils den Contenttype jeweils auf "text/html" oder "text/xml". Auch der Dateiname des Anhangs und der Emailbetreff können hier bestimmt werden. Weiterhin wird eine Sendpipeline benötigt, welche eine "MIME/SMIME encoder"-Stufe enthält und beim Versand die Email mit Anhang generiert.
Der Emailempfänger und der zu verwendende SMTP-Server werden im Sendport definiert. Als SMTP-Server wurde in den Tests der vorhandene Lotus Notes Server der BTC verwendet.
Weitere Funktionalitäten, die in den Tests umgesetzt wurden, sind das Verwenden von HTML im Emailtext, das Einfügen eines Wertes aus der Nachricht in Emailtext oder betreff und das Festlegen der Emailadresse zur Laufzeit bei Verwendung eines dynamischen Sendports.
Ohne die Verwendung der SMTPUtils war es lediglich möglich, eine XML Nachricht als Emailtext oder als Emailanhang zu verwenden. Kombinationen davon waren nicht umsetzbar.
Versenden beliebiger Dateien
Auf ähnlichem Weg wie oben beschrieben ist es möglich, beliebige Dateien als Anhang zu versenden. Als Receive-Pipeline wird diesmal die PassThruReceive verwendet, die alle Daten unverändert durchreicht, im Gegensatz zur XMLReceive, die stets beim Empfang von XML-Daten verwendet wird. Der eingehenden Nachricht wird kein Schema sondern der Typ "XmlDocument" zugewiesen. Diese Nachricht kann dann als Anhangteil der Multipartmessage verwendet werden. Es ist wichtig, den Contenttype des Anhangs auf den richtigen Wert zu setzen, wie beispielsweise "application/pdf" für PDF-Dateien, damit der Empfänger die Datei mit dem richtigen Programm öffnen kann. Ob diese Angabe tatsächlich berücksichtigt wurde oder nur die Dateiendung ausgewertet wurde, war in den Tests abhängig vom verwendeten Emailclient beim Empfänger.
5.4.4 CIDX-Mapping
Als Vorbereitung für das Projekt eBridges sollten reale Bestellungsdaten in das CIDX-Format konvertiert werden. Anhand dieses Tests können Probleme mit der Umwandlung der Daten frühzeitig erkannt werden.
Testszenario
Im Produktivbetrieb werden die entsprechenden Daten per Commerce Gateway an BizTalk Server übergeben werden. Die Programmierung hierfür erfordert spezielle Kenntnisse im Bereich Navision, welche nur beim MBSP vorhanden sind. Um davon unabhängig zu sein, wurden stattdessen in diesem Test die Flatfiles der bisher bestehenden Lösung in BizTalk eingelesen und verwendet, denn diese enthalten alle relevanten Daten.
Ein solches Order-Flatfile besteht aus mehreren Teilen, welche in entsprechenden Schemata abgebildet wurden:
-- Eine Einleitungszeile
-- Mehrere Bestellungen, welche je aus einem Header, einer oder mehreren Bestellzeilen und einer Endzeile bestehen. Die Bestellzeile wurde in einem separaten Schema definiert und in das Schema der Bestellung eingebunden.
-- Eine Endzeile
Da eine CIDX-Datei nur je eine Bestellung enthalten kann, müssen die Flatfiles in mehrere Nachrichten aufgeteilt werden. In der Receive-Pipeline in der Stufe ?Flatfile disassemble? kann man hierfür bis zu drei Schemata eingeben (je eines für das Dokument, den Kopf und das Ende). Kopf und Ende werden verworfen und jedes eigentliche Dokument (also jede Bestellung) einzeln weitergereicht, wodurch je Bestellung eine eigene Instanz der Orchestrierung gestartet wird. In dieser wurden zwei Mappings durchgeführt und somit zwei Nachrichten erstellt, je eine im Format CIDX 2.02 und CIDX 4.0. Diese wurden schließlich als Dateien in getrennte Verzeichnisse geschrieben.
Die Wahl der CIDX-Versionen fiel auf 2.0.2 und 4.0, da diese am wahrscheinlichsten für das Projekt eBridges Verwendung finden werden. Es werden alle Felder gemappt, die in den Flatfiles mit Daten belegt sind und den CIDX-Feldern zugeordnet werden konnten. Die Zuordnung einiger Felder war noch nicht möglich, da die Herkunft und Bedeutung der Daten unklar war. Für viele solcher Felder, die laut Schema nicht leer sein dürfen, wurde daher beim Kompilieren des Mappings eine Warnung ausgegeben. Diese Warnungen wurden zunächst ignoriert und die Felder leer belassen. Die hierfür notwendigen Recherchen zur Datenherkunft und -zuordnung werden im weiteren eBridges-Projektverlauf Personen durchführen müssen, denen die inhaltliche Bedeutung besser bekannt ist.
Die CIDX-Schemata sind zur besseren Wiederverwendung der einzelnen Elemente auf mehrere Dateien aufgeteilt. Diese sind alle Teil des Visual Studio Projekts und verursachen viel Aufwand beim Kompilieren Aus diesem Grund wurden die CIDX-Schema-Dateien in ein separates Projekt ausgelagert und eine Referenz darauf angelegt. Somit muss dieser Teil nicht bei jedem Kompilieren berücksichtigt werden, was den Vorgang deutlich beschleunigt.
5.4.5 Plausibilitätsprüfungen
Bei den versendeten Daten kann es vorkommen, dass diese zwar problemlos generiert und zum Empfänger übertragen werden, jedoch bestimmten inhaltlichen Kriterien nicht genügen. Je später auf dem Weg der Nachrichten ein solcher Fehler erkannt wird, umso aufwändiger ist dessen Rückmeldung und Korrektur. Daher sollen die Nachrichten bereits beim Durchlaufen des BizTalk Servers auf die Plausibilitätskriterien überprüft werden. Weiterhin sollen die Plausibilitätsregeln möglichst einfach zu ändern und zu erweitern sein.
Es sollten mehrere mögliche Varianten erarbeitet und evaluiert werden, durch die Plausibilitätsprüfungen unterschiedlicher Komplexität durchgeführt werden können. Die Varianten sollten nach ihrer Umsetzbarkeit und Praktikabilität bewertet werden. Für die Tests wurden entweder erfundene Daten oder das obige Szenario zum Einlesen der Flatfiles und Umwandeln in das CIDX-Format verwendet.
Test per Business Rules
Die Durchführung der Prüfungen in extern definierten Business Rules hätte den Vorteil, dass Änderungen an den Anforderungen umgesetzt werden können, ohne die Orchestrierung zu ändern und neu einspielen zu müssen (vergleiche Abschnitt 5.4.2).
Es wurden je ein Schema für Eingabedaten und eines für Ausgabedaten angelegt. Als Eingabe dienen die zu prüfenden Daten in einer XML-Datei und die Ausgabe ist ein Flatfile, in das das Ergebnis geschrieben wird.
Eine eingehende Nachricht startet die Orchestrierung. Hierin generiert ein Mapping, das keine Feldzuordnungen enthält, eine leere Ausgabenachricht. Beide Nachrichten werden als Parameter an eine Business Rule übergeben. Diese schreibt einen Wert der Eingangsnachricht in ein Feld der Ausgabenachricht. Schließlich wird diese als Datei ausgegeben.
Durch diesen Test wurde gezeigt, dass es grundsätzlich möglich ist, in Business Rules Daten auszuwerten und auszugeben. Da Business Rules jedoch nicht grundsätzlich auf Werte in Nachrichten zugreifen können, müssten weitere Werte im Schema höher gestuft werden, wenn diese in der Anforderung neu zu berücksichtigen sind. Dadurch muss man auch meist das komplette Projekt neu kompilieren und einspielen, was den größten Vorteil der Verwendung von Business Rules zunichte macht. Weiterhin sind im Business Rule Composer komplexere Operationen (beispielsweise Stringoperationen zum Verketten von Text oder Prüfen auf Umlaute) nicht möglich. Dies wird aber für das Testen und Zusammenstellen der Fehlerbeschreibung benötigt.
Schemavalidierung in der Receive-Pipeline
Der obige Test zum Emailversand wurde durch eine eigene Receive-Pipeline erweitert. Diese enthält eine XML-disassembler-Stufe, in welcher das Schema der Eingangsnachrichten angegeben wurde und die Optionen so eingestellt wurden, dass nur Nachrichten weiterverarbeitet werden, die genau diesem Schema entsprechen.
Hierbei sind Prüfungen gegen leere Felder möglich. Auch Testen gegen eine Werteliste wäre denkbar. Komplexere Abfragen sind jedoch nicht machbar.
Wenn die Validierung fehlschlägt, wird im HAT-Tool eine Fehlermeldung angezeigt, welche aussagekräftige Beschreibungen des Fehlers enthält. Weitere Benachrichtigungen - beispielsweise per Email - konnten jedoch nicht erzeugt werden.
Test in der Orchestrierung per Expression Shape
Die zunächst offensichtlichste Möglichkeit, um in einer Orchestrierung Daten auszuwerten und einen entsprechenden Ergebnistext auszugeben, war das Schreiben des entsprechenden Codes direkt in ein Expression Shape im Ablauf der Orchestrierung. Hierin kann auf Werte zugegriffen werden, die höher gestuft sind.
In Expression Shapes sind jedoch keine Programmierkonstrukte wie if-Abfragen möglich. Dies schränkte die Möglichkeiten zu stark ein, so dass die benötigten Prüfungen nicht durchgeführt werden konnten.
Test in der Orchestrierung per Decide Shapes
Um bedingte Verzweigungen direkt in Orchestrierungen zu erreichen, können Decide Shapes angelegt werden. In einer Orchestrierung wurden mehrere solcher Shapes angelegt, die jeweils einen Wert überprüfen und bei einem gefundenen Fehler eine Textvariable um die entsprechende Fehlerbeschreibung ergänzen.
Der Text mit den Fehlerbeschreibungen wird schließlich als Text einer Email verwendet und die ausgewertete Nachricht als Anhang hinzugefügt. Zusätzlich ist es möglich, anhand einer booleschen Variable zu speichern, ob Fehler aufgetreten sind und nur dann die Email zu schicken. Der Rest der Orchestrierung wurde von dem Szenario zum Einlesen der Flatfiles übernommen.
Dieses Vorgehen ist sehr umständlich, da bei umfangreichen Plausibilitätsprüfungen viele Shapes angelegt werden müssten. Außerdem sind auch hier keine komplexen Operationen wie Stringoperationen zum Testen auf Umlaute möglich.
| Tests auslagern in programmiertes ModulIn einem zusätzlichen Projekt wurde eine C#-Klasse programmiert. Um die Klasse verwenden zu können, muss die hieraus kompilierte Assembly ebenfalls im GAC bereitgestellt werden. Die Klasse hat Methoden, in denen Prüfoperationen auf die übergebenen Variablen durchgeführt werden. In diesen Methoden wird ein String zusammengesetzt, der die entsprechenden Fehlerbeschreibungen enthält. Der Gesamtstring kann am Ende ausgelesen und als Text für die Email verwendet werden. Bei der Implementierung dieses Szenarios wurde eine weitere Schwierigkeit festgestellt: Es können nur Werte höher gestuft werden, die laut Schema nur einmal in einer Nachricht vorkommen. Jede Bestellung kann jedoch mehrere Bestellzeilen enthalten, deren Daten verwendet werden müssen. Darum wurde die Beschreibung der Zeilen in ein separates Schema ausgelagert, in dem somit ein Höherstufen der Werte möglich war. Dieses Schema wurde in der Bestellung wiederum importiert mit der Erlaubnis, dass es mehrfach vorkommen darf. Die Plausibilitätsprüfungen müssen für jede Bestellzeile einzeln durchgeführt werden. In der Orchestrierung sind dafür mehrere Variablen notwendig. Zunächst sind das eine Zählvariable und eine Variable mit der Gesamtzahl der Zeilen, um in einer Schleife alle Zeilen durchlaufen zu können. Die Gesamtzahl wurde mit einem ent¬sprechenden xPath-Ausdruck ausgelesen. Weiterhin gibt es eine Variable xDoc vom Typ XmlDocument. In der Schleife wird nun pro Durchlauf ein Line-Knoten (entspricht einer Zeile im Flatfile) per xPath und der aktuellen Schleifennummer ausgelesen und der Variable xDoc zugewiesen. Aus dieser wird anschließend eine Nachricht des Zeilenschemas erstellt. Am Ende der Schleife wird die Zählvariable um eins erhöht, um diese als Abbruchkriterium mit der Gesamtzahl an Zeilen vergleichen zu können. Eine weitere Variable ist eine Instanz der Klasse CheckPlaus.cs. Deren Methoden werden in Expression Shapes aufgerufen, um vor der Schleife die Werte des Bestellkopfes und in der Schleife bei jedem Durchlauf die Werte der aktuellen Bestellzeile zu prüfen. Zuletzt wird von dieser Instanz der komplette Fehlertext ausgelesen und als Text der Email verwendet. Der weitere Verlauf ist analog zu den obigen Varianten. Diese Methode zur Prüfung von Feldern auf Plausibilitäten ist die flexibelste. In der externen Klasse kann beliebiger Code ausgeführt werden. Ähnlich zu diesem Szenario wäre es auch denkbar, die Prüfung durch eigenen Code in der Receive-Pipeline, im Mapping oder in Business Rules durchzuführen. |
5.4.6 Probleme beim Testen
Enlist per Deployment Wizard
Das Einspielen der ersten Assembly auf einem neu installierten System scheitert meist mit einer FileNotFoundException. Laut Aussage des MBSP ist dies ein reproduzierbarer Fehler. Dieser trat bei den Tests teilweise auch auf einem bestehenden System beim ersten Einspielen einer neuen Assembly auf.
Umgehen kann man das Problem, wenn man die Assembly nicht mit dem BizTalk Server Deployment Wizard einspielt, sondern den entsprechenden Menüpunkt in Visual Studio oder das Kommandozeilentool gacutil verwendet. Beim Aktualisieren einer bereits eingespielten Assembly tritt das Problem auch mit dem Deployment Wizard nicht mehr auf.
Neustarten des BizTalk Services
Gelegentlich kam es vor, dass Änderungen an der Konfiguration der Receive- und Sendports nicht berücksichtigt wurden. Ein weiteres Problem war, dass Makros zum Einsetzen von Werten (beispielsweise einer Nachrichten-ID) in den Namen von Ausgabedateien nicht funktionierten.
In diesen Fällen und bei weiteren unerklärlichen Fehlermeldungen war es meist hilfreich, über die BizTalk Administration Console den aktiven BizTalk Service neu zu starten.
Versionen von Hilfsassemblies
In Projekten, die andere Projekte (beispielsweise SMTPUtils) benötigen, trat manchmal die Fehlermeldung auf, dass dieses referenzierte Projekt nicht gefunden werden kann, obwohl die entsprechende Assembly definitiv im GAC vorhanden war.
Nach einigen Untersuchungen kam folgender Sachverhalt heraus:
Wenn ein Visual Studio Projekt eine Referenz auf ein anderes Projekt enthält, wird hierbei jeweils die aktuelle Versionsnummer des referenzierten Projekts gespeichert. Anhand dieser Nummer kann die korrekte Version im GAC gefunden und verwendet werden. Wenn jedoch die Version des referenzierten Projektes im GAC und die gespeicherte Versionsnummer im referenzierenden Projekt nicht übereinstimmen, ist keine Zuordnung möglich.
Bei Referenzen auf BizTalk-Projekte trat dieses Problem nicht auf. Hier wird die Versionsnummer in einem Eigenschaften-Dialog eingegeben und ändert sich nicht automatisch. Bei C#-Projekten steht die Versionsnummer jedoch in einer speziellen Datei AssemblyInfo.cs. Hier sind standardmäßig Platzhalter eingetragen, die bei jedem Kompilieren automatisch hochgezählt werden, um eindeutige Assemblies zu erhalten. Die Versionsnummer in den Referenzen hierauf werden bei Änderungen auch automatisch angepasst. Dadurch müssen aber auch jeweils die referenzierte Assembly und alle referenzierenden Assemblies zusammen erneut in den GAC aufgenommen werden.
Da es bei den meisten Änderungen am Code jedoch nicht notwendig ist, alles neu in den GAC zu laden, musste hier der Platzhalter in der Versionsnummer durch einen festen Wert ersetzt werden. Somit besitzt die Assembly immer die gleiche Version und es treten bei Änderungen keine Konflikte mehr auf.
5.5 Bericht über die Ergebnisse
5.5.1 Anforderungskatalog
Zu allen Punkten des Anforderungskatalogs wurden die benötigten Informationen aus der vorhandenen Literatur und Internetquellen gesammelt. Praktische Erfahrungen stammen aus den oben beschriebenen Tests. Aufgrund dieser Informationen war eine Bewertung der Anforderungen und deren Einhaltung durch BizTalk Server ebenso möglich wie die Beantwortung weitergehender Fragen. Die ausführliche Darstellung dieser Punkte befindet sich in Anhang B. Im folgenden werden wiederum nur die wichtigsten Punkte aufgeführt (vergleiche Abschnitt 5.1).
a.) In der BTC werden ausschließlich Windows-Betriebssysteme eingesetzt. Ein SQL Server ist bereits vorhanden. In diese Systemlandschaft lässt sich BizTalk Server sehr gut einbinden, da er auf Windowssystemen installiert werden muss und einen SQL Server zur Datenhaltung benötigt. Bezüglich des Betriebs in einer virtuellen Maschine, welche bei der BTC für manche Server genutzt wird, sind keine Probleme bekannt.
b.) Die Installation des Systems sollte von Personen durchgeführt werden, die einige Erfahrung damit besitzen. Nach der Installation erfordert BizTalk Server kaum Administrationsaufwand.
Das Einspielen von Assemblies ist ohne Erfahrung zunächst ein wenig verwirrend, lässt sich mit einer kurzen Anleitung jedoch relativ einfach durchführen.
c.) Sowohl das bestehende Produktivsystem als auch das Testsystem arbeiteten ? allerdings auf geringer Last ? über den Zeitraum dieser Diplomarbeit ohne Probleme durch. Bekannte Wartungsarbeiten sind das Überprüfen der Loggingeinträge auf mögliche Fehler und gegebenenfalls das Archivieren von Daten aus der Tracking-Datenbank, um deren Größe in Grenzen zu halten.
Lastspitzen wurden in den Tests nicht simuliert. Aufgrund der Architektur des Systems ist jedoch davon auszugehen, dass bei übermäßiger Zahl an auftretenden Nachrichten diese wie in Warteschlangen gesammelt werden, bis entsprechende Ressourcen zur Verfügung stehen. Mit Beeinträch¬tigungen des Betriebs ist hierbei nicht zu rechnen. Falls ein besonders hohes Kommunikationsaufkommen auf dem System zu erwarten ist, müssten vorher tiefergehendere Tests zum Lastverhalten durchgeführt werden.
Skalieren des BizTalk Servers auf mehrere Rechner oder mehrere Datenbanken ist nur in der Enterprise Edition möglich.
d.) BizTalk Server kann XML-Dateien und Flatfiles senden und empfangen. Die Einstellung der Schemata dieser Dateien ist sehr detailliert möglich. Das System kann auch Dateien, die mehrere Datensätze enthalten, auf entsprechend mehrere einzelne Nachrichten aufteilen. Datenübertragung zwischen beliebigen Nachrichtentypen ist möglich. Sonstige Dateiformate wie Microsoft Office- oder PDF-Dateien kann BizTalk Server nur unverändert als Ganzes durchreichen und die Inhalte nicht auslesen oder bearbeiten.
Die vorhandenen Adapter können Dateien auf lokalen Datenträgern, Netzwerkverzeichnissen und FTP-Verzeichnissen lesen und schreiben. Nachrichten können in Emails als Text oder Anhang versendet werden. Auch der Zugriff auf einen SQL Server ist lesend und schreibend möglich. Für weitere Kommunikationsarten wie ODBC, OFTP oder POP3 gibt es Adapter zu kaufen und teilweise frei im Internet zu finden.
e.) Das Einspielen neuer Assemblies und Austauschen bestehender Assemblies gegen neue Versionen lässt sich mit einer entsprechenden Anleitung (siehe Anhang F) durchführen. Das Verhalten von BizTalk Server, wenn die Logik einer langlaufenden Transaktion ausgetauscht werden soll, ist nicht optimal. Es gibt für diesen Fall keine automatische Versionsverwaltung für Orchestrierungen sondern nur für extern definierte Business Rules.
f.) Die Anbindung von BizTalk Server an Microsoft Business Solutions Navision erfolgt per Commerce Gateway, welches für diesen Zweck entwickelt wurde. Ausgelöst von Ereignissen wie der Auswahl eines speziellen Menüpunktes werden aus den entsprechenden Daten XML-Nachrichten erstellt und an BizTalk Server weitergereicht. Hierfür ist meist zusätzliche Programmierung im Navisionsystem notwendig.
g.) Der Zugriff auf die verarbeiteten Daten ist sowohl lesend als auch schreibend möglich. Zum Prüfen der Werte gegen Plausibilitätsregeln stehen grundsätzlich mehrere Möglichkeiten zur Verfügung: Validierung durch XML Schema, Prüfen durch Business Rules, Prüfen durch Logik in Orchestrierungen oder Einsatz eines eigens programmierten Moduls. Alle Optionen haben einige Nachteile. Am besten eignet sich ein dafür programmiertes Modul, da dieses beliebige Funktionalitäten durchführen kann.
h.) Die Sicherheit des Systems hängt größtenteils von den Zugriffsmöglichkeiten auf den Rechner mit dem BizTalk Server, die verwendete SQL Datenbank und die Receive- und Send-Locations ab. Wenn diese abgesichert sind, ist ohne Weiteres kein Einsehen der verarbeiteten Daten möglich.
Um Nachrichten auf dem Übertragungsweg zu schützen, können diese beim Versenden verschlüsselt und zertifiziert oder beim Empfangen entschlüsselt und das Zertifikat überprüft werden.
Die Projektverantwortlichen der BTC bestätigten, dass der Anforderungskatalog und die Ergebnisse dazu laut aktuellem Projektstand vollständig sind und als Grundlage für Entscheidungen im weiteren Projektverlauf dienen können.