Plattform für EAI: BizTalk Server

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Plattform für EAI: BizTalk Server Im Rahmen des Seminars: Enterprise Architecture Management Sebastian Herwig Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Roger Müller Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Motivation von Integrations-Architekturen BizTalk Server 2004 Architektur BizTalk Server 2004 Engine BizTalk Server Messaging BizTalk Server Business Process BizTalk Server Management & Monitoring Technologien für Informationsverarbeiter Human Workflow Services Business Activity Services BizTalk Server 2004 Performance Fazit & Ausblick Literaturverzeichnis II

3 Abstract No application is an island. The BizTalk Server 2004 provides the intention of EAI, to integrate proprietary enterprise applications and business, to create coherent business processes. Build up on the.net Framework, BizTalk Server Architecture is logical divided into two main parts, the BizTalk Server Engine and technologies for information worker. The BizTalk Server Engine provides the core-functionality, messaging and orchestration. Messaging as a so called low-level concept to exchange structured data between different applications, whereas orchestration is the high-level view of a sequence of message exchanges based on messaging, to create integrative, application spanned business processes. The second part of BizTalk Server Architecture, are technologies like Business Activity Services and Human Workflow Services, which allow information workers to interact with business processes. To support this system efficient and easily, the BizTalk Server provides a lot of graphical tools. All this shown aspects of Microsoft BizTalk Server 2004 are part of this paper, especially the core functionality BizTalk Server Engine, with messaging an orchestration. III

4 Kapitel 1: Motivation von Integrations-Architekturen 1 Motivation von Integrations-Architekturen In den 80er und 90er Jahren, teilweise bis hin zur Gegenwart, zeigen sich die IT- Landschaften der Unternehmen geprägt durch heterogene Insellösungen zugekaufter und selbst erstellter Anwendungen. Zu dieser Zeit genügte eine aufwendig explizite Extraktion der Informationen aus den einzelnen Anwendungen, um wesentlichen Geschäftszielen zu entsprechen. [Wood04 Kap.1] Im heutigen 20. Jahrhundert erfahren Unternehmen, getrieben durch Internettechnologien, E-Commerce und die damit verbundene Globalisierung der Märkte sowie dem gestiegenen Wettbewerbsdruck, welcher Flexibilisierungs- und Rationalisierungsbestrebungen fordert, einen enormen Anstieg bezüglich des IT-Einsatzes und somit die Notwenigkeit der Integration heterogener Anwendungslandschaften. Eine gesamtheitlich integrierte Lösung aller Bereiche der betrieblichen Informationsverarbeitung, ist durch die permanente Dynamik der Anforderungen an die Informationsverarbeitung, fast unmöglich. Somit besteht die Herausforderung in der Integration heterogener bereichspezifischer Anwendungen, welche durch Architekturen der Enterprise Application Integration (EAI) [Kell02] aufgenommen wird. EAI ermöglicht durch Einsatz von entsprechenden Tools, die Zusammenführung von heterogenen Anwendungen eines Unternehmens sowie unternehmensübergreifender Anwendungen. Das Bestreben von EAI liegt nicht alleinig in der Anwendungsintegration, sondern vielmehr in der Zusammenführung von anwendungsspezifisch ausgeführten Geschäftsprozessteilen zu anwendungsübergreifend einheitlichen Geschäftsprozessen. Durch diese Integration der Teilaufgaben zu einheitlichen, von allen Anwendungen unterstützen, Geschäftsprozessen lassen sich die Informationsflüsse unternehmensintern wie extern beschleunigen, rationalisieren und flexibilisieren und somit Kostensenkungspotenzial und Wettbewerbsvorteile schaffen. Ein EAI-Tool stellt der Microsoft BizTalk Server 2004 dar. Dieser Integrationsserver realisiert die Intention der EAI, indem getrennte Anwendungen mittels XML und Webservice-Technologien zu einem Gesamtsystem mit einheitlichen Geschäftsprozessen vereint werden. Der BizTalk Server 2004, dessen Komponenten und deren Funktionsweise stellen den Focus dieser Arbeit dar. Beginnend mit einem Überblick über die Architektur des Servers, folgen Ausführungen zum Kern des BizTalk Servers die BizTalk Server 2004 Engine. Kapitel 4 betrachtet Technologien für Informationsverarbeiter. Eine kurze Darstellung von Performancekennzahlen ergeht in Kapitel 5. Abschließend ein Fazit und Ausblick bezüglich des BizTalk Server

5 Kapitel 2: BizTalk Server 2004 Architektur 2 BizTalk Server 2004 Architektur Der Microsoft BizTalk Server 2004 wurde als Intermediär zwischen Anwendungen konstruiert, was sich in dessen nachrichtenbasierter Architektur widerspiegelt. Die BizTalk Server 2004 Architektur, wie in Abb. 2.1 dargestellt, setzt auf Windows Server Systemen auf und basiert auf dem.net Framework. Abb. 2.1 BizTalk 2004 Architektur Die Kernkompetenz des BizTalk Servers liegt in der Bereitstellung einer geeigneten Infrastruktur zum nachrichtenbasierten Datenaustausch und darauf aufbauend, zur Realisierung von einheitlichen Geschäftsprozessen zwischen angebundenen Anwendungen. Daraufhin wartet der BizTalk Server mit einer funktionsspezifischen Schichten-Architektur, vergleichbar mit Abb. 2.1 auf. Die äußerste Schicht, der Transport Adapter, stellt die direkte Schnittstelle zur Anbindung von Anwendungen an den BizTalk Server her. Die nachfolgende Schicht (Message Pipeline) verarbeitet die Nachricht hinsichtlich ihres Formates, um dies zielsetzungsgerecht bereitzustellen. Die dritte Schicht (Message Box) ermöglicht die Persistenz der Nachrichten und übernimmt über das publish & subscribe-konzept das Routing der Nachrichten. Diese 3 Schichten lassen sich unter dem Begriff des Messaging subsumieren und realisieren den einfachen Datenaustausch. Orchestration als vierte Schicht, ermöglicht unter Verwendung des Messaging die Umsetzung von einheitlichen Geschäftsprozessen. Die oberste Schicht der Business Rules, definiert Geschäftslogik und greift somit steuernd in den Geschäftsprozess über die Orchestration ein. Diese 5 Schichten im Zusammenhang, bilden den Kern des BizTalk Server die BizTalk Server Engine. Darüber hinaus stellt der BizTalk Server administrative Tools zur Konfiguration der einzelnen Schichten zur Verfügung. Diese lassen sich in die Architektur, wie in Abb. 2.1 links dargestellt, schichten- 5

6 Kapitel 3: BizTalk Server 2004 Engine übergreifend einordnen. Services bezüglich Monitoring und Debugging von Serveraktivitäten, Analysen über Geschäftsprozesse und die Integration von menschlichen Aktivitäten in Geschäftsprozesse stellt der BizTalk Server auf Basis der BizTalk Server Engine bereit. Somit lassen sich diese Services als Supportfunktionalitäten ebenfalls schichtenübergreifend, wie in Abb. 2.1 rechts dargestellt, in die Architektur einordnen. Detaillierte Ausführungen bzgl. der Komponenten und deren Interaktion, im Hinblick auf die Gesamtfunktionalität des BizTalk Servers, ergehen in den folgenden Kapiteln. 3 BizTalk Server 2004 Engine Die Integration von unternehmensinternen wie externen Anwendungen, sowie die Erstellung von einheitlichen Geschäftsprozessen wird durch die Kerntechnologie des BizTalk Servers die BizTalk Server 2004 Engine, realisiert. Die Komponenten der Engine sowie deren Anordnung zu einer logischen Architektur, werden in Abb. 3.1 dargestellt und darauf Bezug nehmend, in den nachfolgenden Abschnitten detailliert. Abb. 3.1 BizTalk Server 2004 Engine Quelle: Vgl. [UsBT04 S.6] 3.1 BizTalk Server Messaging Das Messaging stellt die grundlegende Funktionalität der BizTalk Server Engine, zum Nachrichtenaustausch zwischen Anwendungen dar und ist damit Basis für Orchestrations und weitere BizTalk Server Funktionen. Die Existenz einer Vielzahl von anwendungsspezifischen Nachrichtenformaten, relativiert der BizTalk Server durch die ausschließliche interne Verarbeitung von Nachrichten im XML-Format. Um dies zu ermöglichen, erfolgt der Ablauf des Messaging wie in Abb. 3.1 dargestellt, indem Nachrichten über einen Adapter empfangen bzw. gesendet, per Pipeline ins bzw. aus 6

7 Kapitel 3: BizTalk Server 2004 Engine dem internen XML-Format konvertiert und über das publish & subscribe-konzept kontextbasiert zur Zielanwendung geleitet werden. Die Schnittstellen des BizTalk Servers zur Interaktion mit dessen Umwelt, werden als Ports bezeichnet. Ports sind für angebundene Anwendung spezifisch definierte, logische Container, welche einen benötigten Adapter und eine zugehörige Pipeline zusammenfassen und über eine Adresse, wie z.b. eine URL, eindeutig identifizierbar sind. Die direkte Interaktion mit der Umwelt des BizTalk Server erfolgt über Adapter, welche als Kommunikationsmechanismus zum protokollspezifischen Nachrichtenaustausch zu verstehen sind. Der BizTalk Server stellt ein Adapter-Framework zur Verfügung, was von SOAP, HTTP/S, FTP, SMTP, SQL bis hin zu EDI-Adaptern reicht, bzw. die Entwicklung von speziellen Adaptern sowie die Konfiguration und das Management von bestehenden Adaptern ermöglicht. Adapter beobachten aktiv die Adressen der Ports, in die sie eingebunden sind, um eingehende Nachrichten entgegenzunehmen und an die nachfolgende Messaging-Instanz die Empfangs-Pipeline, weiter zu reichen. Ausgehende Nachrichten werden mit deren Zieladresse einem Adapter von der Ausgangs-Pipeline übergeben und so an die zugehörige Anwendung übermittelt. Nachdem Nachrichten von Adaptern empfangen wurden, müssen diese eine zugehörige Empfangs-Pipeline passieren. Unter einer Pipeline wir eine sequenzielle Folge von Phasen mit einzelnen.net oder COM-Komponenten verstanden, welche Nachrichten vor bzw. nach der Verarbeitung durch die BizTalk Engine manipulieren. Eine Empfangs-Pipeline besteht standardisiert aus 4 Phasen, welche je nach Portzugehörigkeit bzgl. Decoder, Parser, u.ä. konfiguriert werden müssen. Nachrichten in codierter Form, werden in der ersten Phase über einen passenden Decoder der BizTalk Engine verständlich, als Plain Text bereitgestellt. Die zweite Phase Disassemble, wandelt eingehende Nachrichten entsprechender Formate in das XML-Format, da die BizTalk Server Engine intern nur XML-Dokumente verarbeitet. Um Nachrichten jeglicher Formate in XML konvertieren zu können und somit die Integration sämtlicher Anwendungen zu ermöglichen, muss die Struktur der Nachrichten bekannt und in einem Parser umgesetzt sein. Ein Parser ermöglicht es, auf Grund der bekannten Nachrichtenstruktur, Inhalte zu extrahieren und nach vordefinierten Schemata zu einer neuen Nachricht anzuordnen. Die Phase des Disassemble einer Bestell-Nachricht im FlatFile- Format ist in Abb. 3.2 dargestellt und läuft wie folgt ab. Ein nachrichtenspezifischer Parser scannt die Nachricht, extrahiert die Daten und erzeugt auf Grundlage des 7

8 Kapitel 3: BizTalk Server 2004 Engine zugehörigen, vordefinierten XSD Schemata das dazu passende XML-Dokument. Neben den eigentlichen Informationen der Nachrichten werden die XML-Dokumente um BizTalk Server spezifische Anmerkungen ergänzt, die zur Veröffentlichung des Message-context beitragen. Somit enthält bspw. ein XML-Dokument eines FlatFiles, Anmerkungen bzgl. der Struktur des FlatFiles. Unter dem Message-context werden wiederum identifizierende Eigenschaften bzgl. des Kontexts von Nachrichten, wie Typ (z.b. Bestellung), Ursprung, etc. einer Nachricht, als separates XML-Dokument zusammengefasst. Der Inhalt und die Struktur des Message-context werden ebenfalls über spezifisch definierte XML-Schemata bestimmt. Die Definition aller benötigten Schemata erfolgt, unter Verwendung von XML-Schema XSD über den BizTalk Editor. Neben Standardparsern für FlatFile und XML können weitere Parser für SWIFT, HL7, HIPAA und RosettaNet-Formate eingebunden oder per BizTalk Server SDK individuelle Parser erstellt werden. Die erstellen XML-Dokumente werden in der dritten Phase, mittels Validator, gegen die zugehörigen Schemata auf Gültigkeit geprüft. Die letzte Phase Party Resolution versucht, Nachrichten mit den Signaturen des Absenders zu versehen um diese von Seiten des Empfängers identifizieren zu können. Abb. 3.2 FlatFile Parsing Nachdem die Vorverarbeitung der Nachrichten per Pipeline abgeschlossen ist, werden die Nachrichten sowie deren Message-context in einer SQL-Server-Datenbank der Message Box abgelegt. Dieser Schritt wird auch als publish bezeichnet. Die Message Box beinhaltet eine Reihe von Messaging Funktionalitäten, welche in Form von Prozeduren in dieser Datenbank hinterlegt sind. Wenn eine Nachricht mit zugehörigem Message-context in der Message Box abgelegt wird, werden Prozeduren von der Message Box ausgeführt, um den Message-context mit allen definierten Subscriptions abzugleichen und bei Übereinstimmungen die Nachricht den beigeordneten Ausgangsports zu übergeben. Unter Subscriptions werden in der Konfigurations- Datenbank abgelegte Filterregeln zur Nachrichtenauswahl, auf Basis des Messagecontext verstanden. Diese werden für jeden Ausgangs-Port definiert und steuern somit 8

9 Kapitel 3: BizTalk Server 2004 Engine den Fluss der Nachrichten hin zur Zielanwendung. Eine Subscription kann bspw. so definiert sein, dass nur Nachrichten eines bestimmten Absenders an die zugehörigen Ports und somit an darüber angebundene Anwendungen weitergeleitet werden. Dieser Schritt des Abgleichs von Subscriptions und Message-context wird subscribe genannt und ist Teil des publish & subscribe-konzeptes, welches den Nachrichtenfluss steuert. Empfangene Nachrichten stellen häufig Daten bereit, die zur Generierung weiterer Nachrichten benötigt werden. Dies wird von der XSLT-basierten Mapping Infrastructure aufgegriffen und realisiert, indem Beziehungen zwischen Elementen des Quellschemas und den äquivalenten Elementen des Zielschemas definiert werden, um somit die notwendigen Daten aus der Quell- in die Zielnachricht einzubinden. Neben der Schematransformation, wird die Transformation der Daten per se durch sog. Functoids ermöglicht. Functiods stellen integrierte Funktionen in Form von.net Komponenten dar, welche Quelldaten entgegennehmen und auf Basis dieser, unter Einsatz von Geschäftslogik, zur Laufzeit Daten für eine Zielanwendung generieren. Da die BizTalk Server Architektur eine gewisse Symmetrie aufweist, müssen die Nachrichten auf ihrem Weg zur Zielanwendung, dem Empfangs-Port gleiche Operationen, nur vice versa durchlaufen. Dies bedeutet, in den einzelnen Schritten der Ausgangs-Pipeline, erfahren die im XML-Format vorliegenden Nachrichten eine Konvertierung mittels zugehörigen Parser in ein spezifisches Format der Zielanwendung und können weiterhin Codiert werden, bevor die Nachrichten über einen passenden Adapter an die Zielanwendung weitergeleitet werden. Der durch das Messaging angewendete publish and subscribe-mechanismus, ermöglicht durch die Weiterleitung von Nachrichten an eine oder mehrere Zielanwendungen und durch eine mit minimalen Systemveränderungen verbundene Änderung der BizTalk Server Umgebung, eine flexible Integrationsarchitektur. Weiterführend bietet [Wood04 Part II] tiefere Einblicke in die Technik und die Konfiguration der Messaging Engine. 3.2 BizTalk Server Business Process Die Tatsache, dass Geschäftsaktivitäten mehr sind als nur der einfache Austausch von Nachrichten, wird innerhalb des Messaging vernachlässigt, sodass der BizTalk Server weit mehr darstellt, als nur ein Message-Broker. [Wood04 S.39] Die eigentliche Intention des BizTalk Server besteht darin, die von Anwendungen ausgeführten Geschäftsprozessteilaktivitäten zu gemeinsamen Geschäftsprozessen zu integrieren. 9

10 Kapitel 3: BizTalk Server 2004 Engine Diese Teilaktivitäten werden als Nachrichten, vergleichbar zu Abschnitt 3.1 verstanden, welche zu einem ganzheitlichen Geschäftsprozess, in einer wohlgeordneten Sequenz zusammengefasst werden müssen, was der BizTalk Server über das Konzept der Orchestration ermöglicht. Orchestrations dirigieren die Anwendungsaktivitäten und definieren somit die Geschäftsprozesse, indem sie deren logischen Ablauf darstellen und Regeln dafür festlegen. Nachrichten sind somit ein ebenso wichtiger Bestandteil der Orchestrations, wie des unter 3.1 beschriebenen BizTalk Messaging. Für Orchestrations stellen Nachrichten Träger von Prozessdaten dar, welche von einer Orchestration entgegengenommen, verarbeitet und zum Empfänger geleitet werden, um somit den Geschäftsprozess zu realisieren. Daraus lässt sich ableiten, BizTalk Messaging und Orchestration ergänzen sich, indem die Orchestration den Geschäftsprozess und das Messaging die Operationen bzw. den Nachrichtenaustausch innerhalb des Prozesses bereitstellt. BizTalk Orchestration ist somit koordinierend dem Messaging übergeordnet und nutzt, wie in Abb. 3.1 dargestellt, dessen Funktionalitäten zur Realisierung von Geschäftsprozessen. Um eine Orchestration, respektive einen Geschäftsprozess zu formulieren, stellt die BizTalk Server Engine ein Visual Studio.NET add-in den Orchestration Designer, zur Verfügung. Dieses Tool ermöglicht es Geschäftsprozesse graphisch in Form eines Ablaufdiagramms, unter Verwendung bereitgestellter Shapes zu erstellen, Regeln nach denen der Prozess abläuft zu definieren und die benötigten Messaging-Operationen zu konfigurieren. Zu vordefinierten Shapes zählen u.a. Action-Shapes und Ablauf-Shapes, wobei Aktions-Shapes das Empfangen und Senden von BizTalk Nachrichten modellieren, was letztlich vom BizTalk Messaging realisiert wird, sowie den verschachtelten Aufruf weiterer Orchestrations ermöglichen. Ablauf-Shapes hingegen modellieren neben den Anfangs- und Endpunkt eines Prozesses auch weitere Formen des Ablaufes wie Schleifen und Verzweigungen. Vollständig definierte Orchestrations, werden als XLANG/s spezifische XML-Dokumente in der Orchestrations-Datenbank abgelegt und von der BizTalk Orchestration Engine verwaltet und ausgeführt. Unter Regeln lassen sich aus Geschäftslogik formulierte (Geschäfts-)Bedingungen verstehen, welche den Ablauf der Prozesse durch Ausführung sachgerechter Prozessaktivitäten, wie bspw. an Verzweigungspunkten, determinieren. Diese Regeln können, wie schon erwähnt bei der Erstellung von Orchestrations aufgestellt werden. Der BizTalk Server ermöglicht es weiterhin Regeln getrennt von Orchestrations, über die BizTalk Rules Engine zu definieren. Diese stellt dazu einen graphischen Editor 10

11 Kapitel 3: BizTalk Server 2004 Engine den BizTalk Rule Composer, bereit. Über diesen Composer lassen sich Regeln in Form von if-then-klauseln aufstellen. Fakten stellen dabei die wichtigste Komponente dar und repräsentieren Datenelemente, wie Felder von XML-Dokumenten oder Werte aus Datenbanken. Um Regeln verständlich und einfach zu erstellen, ermöglicht die Rule Engine eine Definition eines Vokabulars. Darunter versteht sich eine Art Verzeichnis, welches Quellpfade von Fakten auf eine verständliche benutzerdefinierte Faktenbezeichnung abbildet. Ein erstelltes Vokabular wird in der Regel-Datenbank abgelegt und ist somit für weitere Regeldefinitionen wieder verwendbar. Über if-then- Klauseln werden Fakten gegenüber anderen Fakten oder vordefinierten Konstanten ausgewertet und entsprechende Aktionen ausgeführt. Das Setzen von Werten in XML- Nachrichten bzw. Datenbanken oder die Ausführung von Aktivitäten außerhalb der Rule Engine, stellen typische Beispiele für Aktionen dar. Exemplarisch kann eine Regel zur Angabe eines Rabattes je nach Bestellmenge wie folgt dargestellt werden: IF BestellungXML.RuleRabatt:/Bestellung/Menge is less then 100 THEN RechnungXML.RuleRabatt:/Rechnung/Abzugsposten/Rabatt = 0.05 Die Elemente Menge bzw. Rabatt der XML-Dokumente BestellungXML sowie RechnungXML werden über XPATH angesteuert und hinsichtlich ihrer Werte behandelt. Regeln, welche sich auf gemeinsame Geschäftsbereiche beziehen, werden zu sog. Policies zusammengefasst. Policies werden wie Regeln als XML-Dokumente, mit BizTalk spezifischen Schemata, in der Rule Engine Datenbank abgelegt. Die Anwendung der Policies bzw. Regeln erfolgt, wie in Abb. 3.1 dargestellt, über Orchestrationen. Unter Verwendung von Entscheidungs-Shapes oder anderen.net- Aufruf erzeugenden Shapes, werden Policies oder einzelne Regeln in den Prozessablauf der Orchestrationen eingebunden. Die Ausführung der Regeln obliegt hingegen der BizTalk Rule Engine. Dieses Konzept der getrennten Definition von Orchestration und Geschäftsregeln birgt einige Vorteile. Einerseits ermöglicht der Rule Composer eine einfache Definition komplexer Regelwerke. Andererseits bedarf es keiner ganzheitlichen Überarbeitung und Ausführung von Orchestrations bei Änderungen von Geschäftsprozessen, sondern nur das Anpassen der betroffenen Regeln, da sich Änderungen von Prozessen meist nur auf Geschäftsbedingungen und somit auf die Regeln auswirken, der Ablauf hingegen recht beständig ist. Somit ermöglicht dieses Konzept eine gewisse Flexibilität und Effektivität. Für detaillierter Ausführungen zur Funktionalität der Business Rule Engine vgl. [BTBR03]. 11

12 Kapitel 3: BizTalk Server 2004 Engine Um die geschilderten Funktionalitäten der einzelnen Komponenten und deren Kooperation zu verdeutlichen, ergeht im Nachfolgenden ein beispielhafter Ablauf eines Geschäftsprozesses in Form einer Bestellung. Ein Kunde stößt mit dem Übersenden einer Bestellung lieferantenseitig einen Bestellprozess an. Diese Nachricht wird von der BizTalk Messaging Engine, wie unter 3.1 beschrieben, in das Lieferantensystem aufgenommen und in die Message Box eingepflegt. Über den publish & subscribe- Mechanismus wird die zum Message-context passende Orchestration aufgerufen, welche den weiteren Fluss des Bestellprozesses regelt und somit alle benötigten Geschäftsregeln und Policies an den vordefinierten Stellen aufruft. Im weiteren Verlauf wird durch die Orchestration, eine Nachricht zur Bonitätsprüfung generiert, über die Messaging-Engine an die Finanzanwendung gesendet und je nach Ergebnis über Regeln entschieden, ob die Bestellung ausgeführt wird. Bei Ablehnung der Bestellung wird eine Nachricht an den Kunden generiert und über einen -Client versand. Anderen Falls wird eine Nachricht an ein Warenwirtschaftssystem generiert, um den Bestand mit der Bestellmenge abzugleichen. Bei der Generierung dieser, wie auch bei anderen Nachrichten, spielt die Mapping-Komponente der BizTalk Engine eine erhebliche Rolle. Diese Komponente extrahiert aus der Bestellnachricht die nötigen Artikeldaten, konvertiert diese und erstellt daraus eine für das Warenwirtschaftsystem verständliche Nachricht. Der Abgleich der Mengen erfolgt ebenfalls über Geschäftsregeln, welche von der Rule-Engine ausgeführt werden und über den weiteren Ablauf des Geschäftsprozesses entscheiden. Bei ausreichender Bevorratung wird durch eine generierte Nachricht an ein Versandsystem ein Versandprozess angestoßen. Parallel dazu wird in einem Buchhaltungssystem durch eine entsprechende Nachricht ein Prozess zur Rechnungserstellung angestoßen und dem Kunden eine Bestätigungsmitteilung zugesandt. Bei unzureichender Bevorratung wird eine Nachricht an das System eines Zulieferers generiert und dort ein neuer Bestellprozess angestoßen. Nach Abschluss dieser Aktivitäten terminiert der initiale Bestellprozess. Somit sei ein beispielhafter Überblick über die Grundfunktionalitäten der Messaging, Orchestration und Business Rule Engine zur Realisierung von Geschäftsprozessen und deren Aktivitäten gegeben. Vertiefend zur Funktionalität der Orchestration sei auf [Wood04 Part III] verwiesen. 3.3 BizTalk Server Management & Monitoring Supportaktivitäten wie Management und Monitoring, werden von jedem auf einer BizTalk Server Engine aufsetzenden Anwendungsfall benötigt, um ein 12

13 Kapitel 3: BizTalk Server 2004 Engine funktionsfähiges, zuverlässiges und skalierbares Gesamtsystem zu ermöglichen. Eine Managementaufgabe besteht darin, eine leitungsfähige, flexible und skalierbare BizTalk Server Topologie zu erstellen. Der Einsatz eines BizTalk Servers erfolgt häufig aus Performance- und Sicherheitsgründen nicht nur auf einem, sondern verteilt auf mehreren Serversystemen, welche Teil einer BizTalk Server Group sind. Um das Management der Serversysteme zu ermöglichen, bedient sich der BizTalk Server des Host-Konzeptes. Unter Hosts werden logische Container für spezifische Funktionen wie Empfang, Orchestration, Senden und Speicherung verstanden, welche Hostinstanzen aufnehmen bzw. abgeben können. Eine Hostinstanz stellt eine Realisierung einer Hostfunktionalität und somit einen Windows Prozess dar, welcher auf einem physischen Server läuft. Somit ist es wie in Abb. 3.3 dargestellt möglich, unter einem logischen Host mehrere Server in Form von Hostinstanzen zu vereinen und ebenfalls auf einem physischen Server mehrere (unterschiedliche) Hostinstanzen in Form von Prozessen auszuführen. Bspw. laufen identische Instanzen des Orchestration-Host auf zwei Servern (A und B), wobei der BizTalk Server das Management übernimmt und die Instanz beansprucht, dessen Server die geringste Auslastung aufweist. Entgegen der Abb. 3.3 befindet sich oft die Datenbank der Message Box nicht auf einem, sondern verteilt auf mehreren Servern, wobei ein Server die Master Message Box enthält, welche die Verwaltung weiterer Message Box Server und das Routing der Nachrichten ausführt. Dadurch wird eine flexible und skalierbare Topologie ermöglicht, da jede Hostinstanz unabhängig als Prozess agiert und von daher je nach Auslastung flexibel in Server eingebunden werden kann und ein Fehlverhalten keinen Einfluss auf andere Hostinstanzen auf dem entsprechenden Server hat. Vergleiche dazu [Wood04 Kap.15]. Quelle: Vgl. [UsBT04 S.19] Abb. 3.3 Bsp. einer BizTalk Server-Topologie mittels Hosts Die BizTalk Server Engine stellt weitere spezifische Management-Tools, wie den Subscription Viewer, zur Betrachtung von Subcriptions oder den BizTalk Deployment Wizard zur Verfügung. Alle Aktivitäten der Management-Tools beruhen auf einer Konfigurations-Datenbank, worin die Einstellungen verzeichnet werden. 13

14 Kapitel 4: Technologien für Informationsverarbeiter Mit dem BizTalk Explorer ist ein weiteres wichtiges Management-Tool gegeben. Der Explorer gibt für jedes Element der BizTalk Engine die Einträge der Konfigurations- Datenbank an und ermöglicht je nach Element gewisse Einstellungen, wie z.b. die Abbildung einer logischen Sicht von Orchestrations (Ablaufdiagramm) auf eine konkrete physiche Sicht (z. B. zugehörige URI s angebundener Anwendungen). Das Monitoring des BizTalk Servers führen sog. Health and Activity Tracking Services (HAT) aus. Diese Services verfügen über eine Tracking-Datenbank (vgl. Abb. 3.1), worin innerhalb der BizTalk Engine ausgeführte Aktivitäten, wie Nachrichten- und Prozessflüsse, Orchestrations, deren Ausführung, u.v.m. gespeichert werden. Der Umfang zu speichernder Aktivitäten kann individuell definiert werden, so dass nicht alle Aktivitäten gespeichert werden. Die HAT Services führen, unter Verwendung eines graphischen Zugriffs auf diese Datenbank, neben dem Debugging von Orchestrations anhand der gespeicherten Abläufe auch Analysen über den Grad der Abarbeitung von Geschäftsprozessen um das operative Geschäft zu unterstützen, sowie Analysen bzgl. Trends und Mustern bei der Ausführung von Prozessen, um daraus Aussagen zur Performance abzuleiten, aus. Einen tieferen Einblick in die Technik des Managements und Monitoring wird in [Wood04 Part V] gegeben. 4 Technologien für Informationsverarbeiter Informationsverarbeiter bezeichnet Akteure wie Geschäftsleute, Geschäftsanwender oder Manager. Diese Akteure befinden sich auf einer operativen Geschäftsebene und stellen somit gesonderte Anforderung an Geschäftsprozesse. Die Betrachtung von geschäftsbezogenen Aspekten der Prozessaktivitäten steht zum einen im Fokus und wird durch die BizTalk Server Komponente der Business Activity Services (BAS) realisiert. Ein weiterer Gesichtspunkt stellt die Integration von menschlichen Aktivitäten in Prozessabläufe dar, welcher durch Human Workflow Services des BizTalk Servers realisiert wird. Diese beiden Technologien werden, wie in [Wood04 Part VI] und [USBT04], nachfolgend detaillierter betrachtet. 4.1 Human Workflow Services Im Geschäftsalltag laufen kaum Prozesse ohne den Eingriff menschlicher Aktivitäten ab. Die BizTalk Server Engine ermöglicht jedoch nur automatisierte Geschäftsprozesse. Um menschlich-orientierte Geschäftsprozesse sog. Workflows, zu realisieren, stellt 14

15 Kapitel 4: Technologien für Informationsverarbeiter der BizTalk Server Human Workflow Services (HWS) bereit. HWS basieren auf einer Workflow-Infrastruktur und setzen auf der BizTalk Server Engine auf. Wie in Abb. 4.1 dargestellt erfolgt die Anbindung menschlicher Aktivitäten an die HWS über Web-Services und die damit verbundenen Client-Anwendungen. Microsoft Outlook, Infopath, Word, ASP.NET-Anwendungen sowie weitere Web-Service fähige Anwendungen warten als Beispiele für Client-Anwendungen auf, über die Personen in Geschäftsprozesse eingebunden werden können. Aktivitäten von Workflowabläufen werden in einer angebundenen Tracking-Datenbank hinterlegt, die ebenfalls von den Business Activity Services (vgl. Abs. 4.2) verwendet wird. Das Management der HWS erfolgt über ein Microsoft Management Console snap-in die HWS Administration Console, und greift dabei auf eine Konfigurations-Datenbank zurück. Quelle: Vgl. [UsBT04 S.29] Abb. 4.1 Human Workflow Services Um in automatisierte Geschäftsprozesse menschliche Aktivitäten zu Integrieren und somit den Ansatz des Workflows zu realisieren, greifen die HWS auf die BizTalk Server Engine und somit auf Orchestrations und Messaging zurück. Folglich wird auch die Anwendung der Web-Services als Kommunikationsmedium zwischen HWS und Client-Anwendungen zweckmäßig. Die BizTalk Server Engine verarbeitet intern nur XML-Dokumente und was währe eine bessere Technik als Web-Services, um den Austausch dieser Dokumente, bspw. über SOAP zu ermöglichen. Ein Workflow wird durch die HWS als Aktivitätsfluss, bestehend aus einer Reihe von Aktionen zwischen Personen und Prozessen bezeichnet. Der Aktivitätsfluss gibt eine vordefinierte Reihenfolge der Aktionen an und unterliegt einem Aktivitätsmodell, welches die Aktionen und deren Beziehungen zueinander sowie die zugehörigen Akteure definiert. Eine Aktion besteht aus einer oder mehreren Aufgaben und wird über den Orchestration Designer in Form einer Orchestration definiert. Aufgaben stellen wiederum Arbeitschritte zur Erfüllung einer Aktion dar, welche von involvierten 15

16 Kapitel 4: Technologien für Informationsverarbeiter Personen sog. Akteuren, erfüllt werden. Die Interaktion zwischen Personen und Aktionen erfolgt somit über Aufgaben, welche letztlich XML-Nachrichten darstellen. Bspw. kann ein Workflow automatisch über eine andere Anwendung, wie ein Lagerhaltungssystem angestoßen werden. Dieses System veranlasst durch erreichen eines Bestandslimit einen Workflow der Bestellung. Da das Aktivitätsmodell eine Prüfung vorsieht, wird diese Aufgabe über die HWS-Infrastuktur an den vordefinierten Akteur delegiert. Dies geschieht, indem die HWS über eine XML-Nachricht einen Web- Service aufruft, welcher dem Akteur eine Nachricht im Outlook ablegt. Daraufhin wird dem Akteur über ein benutzerdefiniertes InfoPath Formular ermöglicht die Bestellung zu prüfen, wobei die HWS-Infrastruktur über Web-Services alle notwendigen Daten zur Verfügung stellt. Mit Ausführung einer Handlung durch einen Akteur, welche einen Einfluss auf den Workflow aufweist, wie z.b. drücken des Button geprüft in dem obigen Formular, wird eine spezielle Aufgabennachricht an die zugehörige Aktion in der HWS und somit an eine Orchestration gesendet, um weitere Aufgaben oder Aktionen je nach Aktivitätsmodell durch die HWS einzuleiten. Ein Akteur kann ihm zugetragene Aufgaben auch selbst an andere Akteure weiterleiten, indem bspw. über SmartDocs im Word ein anderer Akteur ausgewählt wird und somit, durch eine XML- Nachricht über einen Web-Service, die Delegation mittels HWS ermöglicht wird. Somit ist eine dynamische Änderung des Workflows zur Laufzeit möglich. HWS Sercurity stellt ein Konzept der Autorisierung von Personen zur Verfügung. Abhängig von ihrer Rolle im Unternehmen soll es Personen ermöglicht werden Aufgaben oder Delegationen in Workflows zu veranlassen bzw. auszuführen. Dazu werden je nach Rolle bzw. Person Reglen sog. Constrains, aufgestellt und somit ein Berechtigungskonzept definiert. Abhängig von diesen Berechtigungen erfolgt nun die Delegation respektive der Ablauf des Workflows. Die vom BizTalk Server bereitgestellten Human Workflow Services ermöglichen somit einen menschlich-orientiert automatisierten Geschäftprozess. 4.2 Business Activity Services Die Analyse von Absatzzahlen, die Definition, Aufnahme und das Management von neuen bzw. bestehenden Geschäftsbeziehungen sowie die damit verbundene Integration von neuen Partnern in Geschäftsprozesse sind alles operative Geschäftstätigkeiten, die auf Grundlage von Geschäftsprozessen erfolgen. Um dies im Rahmen des BizTalk 16

17 Kapitel 4: Technologien für Informationsverarbeiter Servers zu ermöglichen, stellt dieser Business Activity Services (BAS) zur Verfügung. BAS ermöglichen Geschäftsleuten das Management von Geschäftsbeziehungen und zugehörigen Geschäftsprozessen sowie Analysen der Geschäftstätigkeit auf Basis von Geschäftsprozessen. Dies erfolgt unter Verwendung von vier Komponenten, welche über SOAP und Windows SharePoint Services mit den Schnittstellen zu Geschäftsanwendern, wie Browser, Mircosoft Excel und InfoPath, kommunizieren. Die BAS- Architektur mit deren Komponenten und Beziehungen ist in Abb. 4.2 veranschaulicht, wobei die Komponenten den Gegenstand der weiteren Ausführungen bilden. Quelle: Vgl. [UsBT04 S.25] Abb. 4.2 Business Activity Services Das Trading Partner Management (TPM) stellt eine dieser Komponenten dar, worüber Geschäftsbeziehungen angelegt, verwaltet und gepflegt werden. Informationen über Geschäftsbeziehungen werden in sog. Abkommen zusammengefasst und in einer zentralen TPM-Datenbank abgelegt. Abkommen beinhalten Aspekte wie, Profilinformationen von Unternehmen mit Adressen, Kontaktpersonen aber auch technische Informationen bspw. zu Protokollen und Datenformaten, im Hinblick auf die Portkonfigurationen, sowie die Rolle des Partners im Geschäftsprozess und parametrisierte Zusatzinformationen die das Verhalten von Orchestration kontrollieren. All diese Informationen werden genutzt, um die BizTalk Server Laufzeitumgebung zu konfigurieren und mit Partnern gemeinsame Geschäftsprozesse auszuführen zu können. Eine weitere Komponente der BAS ist mit Business Process Configuration gegeben. Die Definition von Geschäftsprozessen scheint für einen Geschäftsanwender etwas komplex. Um dennoch Einfluss auf Geschäftprozesse zu gewähren, werden diesem mittels Business Process Configuration Möglichkeiten der Prozesskonfiguration an die Hand gegeben. Diese Konfiguration erfolgt über Parameter von Orchestrations und wird sinnvoll, wenn für mehrere Geschäftspartner dieselbe Orchestration, jedoch mit anderen 17

18 Kapitel 4: Technologien für Informationsverarbeiter Parametern angewendet wird. Die Orchestrationsparameter müssen mit der Definition von Orchestrations angelegt werden und können später, über die im TPM spezifizierten Zusatzinformationen von Geschäftsbeziehungen, gesetzt werden. Somit wird es dem Geschäftsanwender ermöglicht, Geschäftsprozesse nach dessen Belangen zu konfigurieren. Die Komponente des Business Process Provisioning erleichtert die Konfiguration anzubindender Systeme durch ein sog. SEED-Pakete. Ein solches Packet enthält notwendige Informationen bzgl. des BizTalk Server (Hub) zur Konfiguration von Partneranwendung (Spoke), um mit dem Hub interagieren zu können und wird vom Hub zentral bereitgestellt. Mittels SEED-Paketen werden lokale Spoke-Konfigurationen geprüft und ggf. angepasst. Vice versa wird spoke-seitig ebenfalls ein SEED-Paket mit dessen Konfigurationsparametern für den Hub bereitgestellt. Die Erstellung und Anwendung von SEED-Packeten erfolgt über einen SEED-Assistenten bzw. einen SEED-Client, welcher auf dem Spoke zur Ausführung installiert sein muss. Somit wird die Konfiguration der BizTalk Server Umgebung erheblich vereinfacht. Die letzte Komponente der BAS, das Business Activity Monitoring (BAM) Framework erlaubt es, Daten über Geschäftsabläufe aus Geschäftsprozessen zu extrahieren und diese weiterhin zu aggregieren, analysieren und visualisieren. Über BAM-Sichten werden verschiedene Perspektiven definiert, unter denen Prozesse zu betrachten sind, wie z.b. Absatzzahlen, Bestände, Kosten, etc. Diese Sichten werden von BAM- Aktivitäten untermauert und zur graphischen Visualisierung in Excel implementiert. BAM-Aktivitäten definieren die Prozesse, die unter einer Perspektive betrachtet werden sollen, sowie die dazu benötigten Prozessdaten. Bspw. kann über Bestellprozesse die Perspektive Absatzzahlen gelegt werden, wobei Daten wie Bestellmengen und Datum benötigt werden, um die Entwicklung des Absatzes zu analysieren. Die benötigten Prozessdaten, werden durch Orchestrations bereitgestellt und in der Tracking- Datenbank (vgl. Abb. 4.2) abgelegt. Orchestrations müssen hinsichtlich der bereitzustellenden Daten per Tracking Profile Editor konfiguriert werden. Auf Basis der Tracking-Datenbank können nun bezüglich der BAM-Sichten und Aktivitäten, Analysen mittels BAM-Framework und integrierter OLAP-Funktionalitäten gefahren werden. Da die BAM-Komponente über SOAP bzw. SharePoint Services an Excel angebunden ist, werden Ergebnisse der Analysen durch Tabellen oder Diagrammen ständig aktualisiert in Excel dargestellt. 18

19 Kapitel 5: BizTalk Server 2004 Performance Durch diese vier Komponenten wird einem Geschäftsanwender die Möglichkeit gegeben Geschäftsaktivitäten nach dessen Belangen zu analysieren bzw. zu konfigurieren. Für detaillierter Ausführungen, speziell zu BAM sei auf [Wood04 Kap.19,20] verwiesen. 5 BizTalk Server 2004 Performance Der BizTalk Server, als Intermediär zwischen einer Vielzahl von Anwendungen und Systemen, bedingt durch den zentralisierten Standpunkt die Performance des Gesamtsystems. Somit bedarf es, zur Vermeidung des Bottleneck, einer performanceorientierten Konfiguration der BizTalk Server Infrastruktur. Es lassen sich einige Faktoren nennen, die einen Einfluss auf die BizTalk Server Performance aufweisen. Einer dieser Faktoren stellt die Host-Konfiguration und damit die Einrichtung einer leistungsfähigen Servertopologie dar. Wie in [BTPf04] ermittelt, realisierte eine 1- Server-Topologie die Verarbeitung von 64 Dokumenten/Sek. beim Messaging. 6 Server verarbeiten hingegen 315 Dokumente/Sek. beim Messaging. Die Größe von Nachrichten determiniert deren Verarbeitungsgeschwindigkeit und den Umfang dazu allokierter Ressourcen. Mit ansteigender Nachrichtengröße wird der Durchsatz an Nachrichten verringert und der Bedarf an Ressourcen steigt an. Die Komplexität von Orchestrations hat einen entscheidenden Einfluss auf die Leistungsfähigkeit, da häufig Orchestrations parallel ausgeführt werden, fällt die Performance bei komplexen Orchestrations stark ab. Bei einfachen Orchestrations können 141 Stck. pro Sekunde ausgeführt werden. Bei verschachtelten Aufrufen nur 90 und bei Orchestrations mit atomaren Bereichen sogar nur 66 Stck/Sek. Dies bezieht sich auf eine Topologie in [BTPf04 S.31ff.]. Der Durchsatz von Nachrichten beim Parsen, wird durch die Komplexität der zugrunde liegenden Schemata bestimmt. Die Komplexität bezieht sich einmal auf die Anzahl der Felder eines Schemas und weiterhin auf deren Tiefe. Bei Schemata mit 10 Feldern können 74 Dokumente/Sek., hingegen bei 1000 Feldern nur noch 58 Dokumente/Sek. erzeugt werden. Weist jedes Feld noch 2 Unterfelder auf so können 73 Dokumente/Sek. erstellt werden. Bei mehr als 2000 Unterfeldern eines Feldes sind es noch 58. Die Häufigkeit der Nachrichtenspeicherung und somit die Zugriffe auf die Message Box ist ebenfalls maßgebend für die Performance, sodass durch Verringerung der Zugriffshäufigkeit mittels zusammenfassen von Speicheroperationen, die Leistungsfähigkeit gesteigert werden kann. Ähnliches gilt für Operationen auf der Tracking-Datenbank. Mit steigender Anzahl an analysierten 19

20 Kapitel 6: Fazit & Ausblick Objekten, steigen der Ressourcenbedarf der Datenbank sowie die Austauschfrequenz zwischen MessageBox und Tracking-Datenbank. Somit kann bei voller Anwendung von BAM und HAT-Services die Performance gegenüber minimaler Trackinganwendung um bis zu 25% sinken. Weitere Faktoren, performanceoptimierende Lösungsversuche und Analysen befinden sich in [BTPf04], worauf sich die Zahlenwerte beziehen und [Perf04]. Zwischen den oben genannten Faktoren besten u.u. gewisse trade-off s bzgl. performanceorientierter Umsetzung, sodass die Konfiguration der BizTalk Server Infrastruktur meist Anwendungsfall getrieben erfolgt. 6 Fazit & Ausblick Mit dem BizTalk Server 2004 bietet Microsoft eine umfangreiche Lösung einer Integrationsumgebung, die der Intention des EAI in allen Beziehungen gerecht wird. Theoretisch wie auch praktisch sind mit dieser Umgebung nahezu alle Integrationsszenarien realisierbar. Konzepte wie das Messaging, was einen zentralisierten Datenaustausch realisiert, die darauf aufsetzenden Orchestrations zur Realisierung von einheitlichen Geschäftsprozessen und vor allem die einheitliche interne Verarbeitung von Nachrichten auf Basis des XML-Standards, trägt maßgeblich dazu bei, systemspezifische Funktionen als allgemein zugängliche Services zur Verfügung zu stellen und somit die Punkt-zu-Punkt-Architektur zwischen den Systemen aufzuheben und anwendungsübergreifend einheitliche Geschäftsprozesse zu realisieren. Der BizTalk Server ermöglicht es durch eine Reihe von einfachen und graphischen Tools, die Konfiguration der Serverumgebung sowohl von technisch orientierten Entwicklern als auch von Geschäftsanwendern durchzuführen, ohne sich in die Domäne des Anderen einarbeiten zu müssen. Somit wird die Einrichtung der BizTalk Server Umgebung simplifiziert und gestattet domänenspezifische Einstellungsmöglichkeiten. Vergleicht man den BizTalk Server mit gleichartigen Integrationsumgebungen wie IBM WebSphere und BEA Weblogic lassen sich Ähnlichkeiten in den Grundlegenden Technologien und Standards festmachen. Gegenüber BEA haben Microsoft und IBM eine höhere Akzeptanz und nehmen somit, wie in [Gart04] dargestellt, die Marktführerschaft, jedoch im Hinblick auf zukunftsweisende Visionen nur teilweise die Führerschaft ein. 20