BizTalk Server 2009



    Hallo lieber habropolzovateli. In diesem Beitrag möchte ich Dir über ein Produkt sagen , für die Automatisierung und Verwaltung von Geschäftsprozessen BizTalk Server 2009.

    Die Geschichte voll von Beispielen, weil es einfacher ist , die Fähigkeiten des Produkts mit der Lösung der wirklichen Probleme zu verstehen.

    Einleitung


    Es hat lange mittlere und große Unternehmen steuern System mit einer Vielzahl von Software - Systemen umfasst, die für das Wachstum und die Entwicklung des Unternehmens eingeführt. Diese Systeme erfordern auch die Kommunikation mit Programmen und Diensten außerhalb des Unternehmens. Es sieht ungefähr so ​​aus:



    Um den Problembereich zu verstehen, werde ich ein Beispiel für einen einfachen Geschäftsprozess geben:
    1. Der Benutzer erstellt das Dokument "Bestellung von Waren" über das Webportal
    2. Der Auftrag muss an alle anderen Systeme des Unternehmens weitergeleitet werden (an die Buchhalter zur Begleichung der Rechnung, an das Logistiksystem zur Abrechnung und Lieferung von Waren, an das Datawarehouse zur Erfassung historischer Daten und zur Berechnung von kpi usw.).

    Wir haben ein Problem: Wie können alle Komponenten miteinander arbeiten?

    Wenn die Datenübertragung Logik direkt auf der Systemebene zu implementieren, wo die Daten erstellt werden, müssen wir die Umsetzung der Kommunikation gehen ist eine Eins-zu-viele für jedes der Systeme. Dies wird zu einer großen Anzahl von Verknüpfungen zwischen vorhandenen Systemen führen und die Notwendigkeit, neue Verknüpfungen hinzuzufügen, wenn wir ein anderes System einführen möchten.



    Um solche Probleme zu lösen, wurde BizTalk Server (BTS) erstellt. Es stellt eine neue Ebene, die mit dem System interagieren, und übernimmt die Verantwortung für die Übermittlung von Nachrichten an Abonnenten. In unserem Beispiel müssen wir das Dokument jetzt nicht mehr vom Webportal an alle anderen Systeme senden. Es reicht aus, es an BizTalk zu übertragen und dann die Nachricht an jedes der Systeme zu übermitteln, die dies erfordern. Offensichtlich wird die Anzahl der Anleihen mit diesem Ansatz erheblich reduziert. Dadurch werden die Kosten für die Verwaltung der Systeme insgesamt gesenkt (da wir nicht mehr mit anderen Systemen kommunizieren müssen), und wir können auf einfache Weise neue Systeme hinzufügen.



    BTS-Architektur


    Hier ist der einfachste Dienst, der ausreicht, um die Architektur von BTS zu beschreiben:
    1. Auf dem eingehenden Port erhalten wir eine Nachricht, die einen Geschäftsprozess initiiert.
    2. Wir verarbeiten die Nachricht;
    3. Schicke eine Nachricht an einen oder mehrere Outbound-Ports;


    Und so läuft dieser Prozess auf Serverebene ab:


    Zunächst einige Definitionen von dem, was auf dem Bild zu sehen ist:

    Empfangsadapter - Eingabeport. Es ist notwendig, um Nachrichten von der Außenwelt zu empfangen. Es unterstützt verschiedene Protokolle und Möglichkeiten, auf Anwendungen zuzugreifen.
    Orchestrierung - Teil des Geschäftsprozesses. Hier können Sie C # -Code schreiben, Nachrichten transformieren, Ausführungen werfen und abfangen, die Kompensation für erfolgreiche Segmente aufrufen usw. Aber die wichtigsten Merkmale, die das Orchester gibt - ein Muster der Nachrichtenverarbeitung. Ich werde einen von ihnen im Abschnitt mit einem Beispiel geben.
    Sendeadapter - der gleiche wie der Empfangsadapter ist nur zum Senden von Nachrichten vorgesehen.

    Nun, jetzt ist der Prozess des Dienstes detaillierter:

    1. Receive Adapter empfängt eine Nachricht über eines der vielen verfügbaren Protokolle von der Außenwelt.
    2. Die Nachricht wird über die Empfangspipeline weitergeleitet (mit Transformations- und Validierungsfunktionen).
    3. Die Nachricht fällt in die Message Box (MB) - Nachrichtenspeicher in der Datenbank basierend auf MS SQL Server;
    4. Ein ständig arbeitender Agent zeichnet das Vorhandensein einer nicht bearbeiteten Nachricht und den Empfänger in Form eines Orchesters auf.
    5. Der Agent ruft das Orchester mit einer Nachricht an;
    6. Orkestereyshen alle notwendigen Arbeiten durchzuführen und erzeugt eine neue Nachricht, die an die Message Box zurückkommt (eine Struktur oft neue Nachricht unterscheidet sich von dem Original);
    7. Der Agent erfasst die Nachricht erneut in MB und sucht nach dem Empfänger. Diesmal ist es der Sendeadapter.
    8. Die Nachricht wird an den Sendeadapter übertragen, der in Verbindung mit der Sendepipeline die Nachricht validiert, transformiert und bei Bedarf unter Verwendung eines der verfügbaren Protokolle an die Außenwelt sendet.

    Nachdem das grundlegende Beispiel klar ist, werde ich versuchen, einige nützliche und sogar einzigartige Funktionen von BTS zu beschreiben:
    1. Eine große Anzahl von Protokollen, die eingehende (Ausgang) Port betrieben werden kann (Datei, SMTP, HTTP, WCF, MSMQ, SOAP, etc.). Neben Protokollen werden auch verschiedene Anwendungen unterstützt: Oracle, SQL Server, WebSphere MQ, SharePoint, Tibco, SAP, JMS, JD Edwards, Dynamics und andere. Wenn Ihr System nicht in der Liste enthalten ist, ist dies das SDK, mit dem Sie den Adapter selbst entwickeln können.
    2. Am Eingang empfangene Nachrichten können in Pipeline in das bequemste Format konvertiert werden, bevor sie ins Orchester gelangen. Out of the box gibt es Unterstützung für mit Flat - Dateien und Rich EDIFACT Verarbeitungsfähigkeiten arbeiten. BizTalk selbst konvertiert alle diese Formate in XML mit einem vordefinierten XSD-Schema.
      Noch einmal, wenn Sie Eingabe empfangen möchten, wie Excel - Dateien oder Binär - Dateien , die sich verwandeln kann , ein Verfahren zu XML zu schreiben, und Sie können chatten und so in der Message - Box werfen und dann die Besetzung von Stellen innerhalb des Orchesters abzubauen.
      Besonders hervorheben möchte ich die Bequemlichkeit der Bearbeitung von EDIFACT-Nachrichten. Alle verfügbaren Formate werden unterstützt. Wenn jedoch einer Ihrer Partner vom Standard abweicht, können Sie das Format problemlos anpassen. Neben der Verarbeitung Framework bietet BizTalk-Messaging einen anderen Rahmen für den Austausch von Dokumenten. Dort können Sie die Eindeutigkeit von Nachrichten verfolgen, für jeden Partner spezielle Einstellungen vornehmen und automatisch eine Bestätigung über die Annahme eines EDI-Dokuments senden. All dies kann auch über das AS2-Protokoll erfolgen.
    3. In dem beschriebenen Beispiel asynchrone Nachrichtenverarbeitung erfolgt, aber im allgemeinen kann sie synchron oder gemischt sein. Zum Beispiel eine Antwort erfordert, wenn der Eingang wir eine HTTP-Anforderung hatten, können wir es nur antworten, nachdem wir in der Nachricht überprüfen, ob erfolgreich an dem abgehend Port gesendet;
    4. Entwicklungsmuster beinhalten die Wiederverwendung einzelner Komponenten, ohne dass eine Duplizierung erforderlich ist. Wenn Sie beispielsweise eine Nachricht nicht über FileSystem, sondern über FTP empfangen müssen, hat dies keine Auswirkungen auf die Implementierung. Ändern Sie einfach den Typ des eingehenden Ports und konfigurieren Sie ihn auf die richtige Adresse.
    5. Contextual Message Routing. Sehr praktische Funktionalität! Wenn mehrere Komponenten einen Nachrichtentyp verarbeiten, können Sie diese gemäß der Beschreibung des XSD-Schemas für den Empfang signieren. Sobald XML, das die angegebene XSD-Struktur erfüllt, in die Nachrichtenbox fällt, erhalten alle interessierten Abonnenten sofort eine Kopie davon. Das Hinzufügen eines neuen Abonnenten wirkt sich natürlich nicht auf Empfänger oder Absender aus. eine Analogie mit dem JMS zu zeichnen ist es, als ob Sie ein Thema mit einer Vielzahl von Verlagen und sabskrayberov hatten. Aber der Unterschied ist, dass man im Fall der kontextuellen Routing braucht kein Thema, aber nur einen Vertrag Nachrichten in Form eines XSD-Schemas zu empfangen;
    6. Ein bisschen über Skalierung. Wie Sie bemerkt haben, erhält Oextrashchen eine Nachricht direkt aus der Datenbank. Er weiß nicht, woher es kam oder an wen es gerichtet ist, seine Aufgabe ist es, die Nachricht zu nehmen, zu verarbeiten und zurückzustellen. Daher können Sie so viele Server installieren, wie Sie möchten, von denen jeder zum Empfangen von Nachrichten abonniert ist. In dem Moment, in dem plötzlich 1000 von ihnen in der Datenbank sind, werden sie von Load Balancer je nach aktueller Auslastung für jeden Server gleichmäßig verteilt.
    7. Das Speichern von Nachrichten in der Datenbank ist ein weiterer positiver Punkt. Wenn Sie Nachrichten an Port-Fehler (zum Beispiel - geschlossener Firewall-Kanal) tritt Discard Nachricht und hält in einer Datenbank, die den Fehler beschreibt. Wenn der Administrator das Problem erkennt, kann er das Netzwerkproblem bei Bedarf beheben und die Nachricht erneut an den Port senden. Sie können auch die automatische Wiederaufarbeitungsstrategien umzusetzen. All dies wird ohne Beteiligung des Entwicklers durch eine bequeme und informative Administrationskonsole BTS getan;
    8. Ein paar Worte zur Konsole selbst sind ein leistungsstarkes Tool zum Verwalten und Überwachen des Status eines oder mehrerer BizTalk-Server. Hier können Sie beobachten, welche Dienste aktiv sind, deren Start verwalten, die Terminplanung konfigurieren, überprüfen, wie Nachrichten zwischen Komponenten weitergeleitet werden, ob in letzter Zeit Fehler aufgetreten sind und vieles mehr.
    9. BRE (Business Rule Engine) - ein Mechanismus zur Einführung von Funktionen in einen Service im laufenden Betrieb (Dependency Injection). Um BRE zu verwenden, fügt der Entwickler ein Bussines-Regelelement in das Orchester ein und implementiert die Verarbeitung im Kontext dieser Regel. Dann wird der Dienst auf dem Server bereitgestellt und funktioniert. Im Laufe der Zeit kann sich das Geschäftsmodell ändern. Anschließend muss der Analyst eine neue Regel in einem speziellen benutzerfreundlichen Editor erstellen und im BRE-Repository installieren, indem er sie mit dem erforderlichen Service verknüpft. Gleichzeitig wird der zuvor erstellte Prozess auf der Grundlage der geänderten Regel ausgeführt, ohne dass der Entwickler einbezogen und der Dienst neu gestartet werden muss.
    10. BAM (Business Activity Monitoring) - Alle Elemente im Orchester, die während des Betriebs des Dienstes verwendet werden, enthalten eine Reihe von Parametern, die für den BAM-Server verfügbar sind. Zum Beispiel stellt das Objekt remappinga xml Nachricht Zugriff auf alle Felder XSD-Schema angegeben. Mit diesen Daten können Geschäftsbenutzer ohne Beteiligung des Entwicklers Datenmuster, Diagramme und Diagramme erstellen, die auf den Daten basieren, die in der XML-Nachricht durch den Dienst übertragen werden. All diese Arbeit ist unabhängig von dem Prozessbetrieb des Dienstes und kann geändert werden, ohne auf den Dienst zu beenden. Die Ergebnisse können in Office-Dokumenten oder auf einem speziellen BAM-Portal angezeigt werden.


    Service-Beispiel


    Hier ist ein Beispiel für einen anspruchsvollere Service, die Möglichkeit des Orchestermanagements zeigt (Zahlen entsprechen die Liste der Elemente im Designer des Orchesters im Bild) über den Geschäftsprozess:



    1. Ein Benutzer auf dem System erstellt eine benutzerdefinierte Produkt. Eine positive oder negative Antwort sollte auf seine Anfrage kommen, abhängig von verschiedenen Faktoren, die von externen Systemen in Bezug auf den Benutzer bestimmt werden. Check verfehlt das Eingangsadapter BizTalk, im folgenden MessageBox, und dann wird die Ausführung auf das Orchester übertragen;
    2. Service sendet die Bestellung an den Manager die Gültigkeit zu prüfen (weil der Benutzer das Produkt bestellen kann nicht in Bezug auf das Unternehmen tätig ist);
    3. Die gleiche Reihenfolge wird unmittelbar an das Lager geschickt, um die Möglichkeit ihrer Umsetzung zu überprüfen (Waren können einfach nicht zur Verfügung);
    4. Als nächstes kommt ParallelActions Shape ins Spiel, das das Parallel Convoy Pattern implementiert. Dieses Element wird erst dann ausgeführt, wenn alle seine Bestandteile vollständig sind. Und 2 Fakten sollten funktionieren: Der Service sollte Antworten vom Manager und vom Lager erhalten.
      Im Allgemeinen kann das Warten lange genug dauern (z. B. wenn der Manager im Urlaub ist). In diesem Fall ist es möglich , in der BizTalk - Orchestrierung angeben: Dauernde Lauf. Während auf eine Antwort von beiden Systemen gewartet wird, wird der Orchestrierungsausführungsstatus serialisiert und in der Datenbank gespeichert (in BTS wird dieser Prozess als Anwendungsentwässerung bezeichnet). Und sobald sie beide Antworten erhalten - Service wieder in den Speicher geladen und wird ParallelActions Form abzuschließen.
      Es gibt einen subtilen Punkt. In einem realen System Benutzer sind immer viele und der Anwendungsmanager und das Lager können mehrere Nachrichten gleichzeitig kommen, bzw., und sie können in der Reihenfolge, in der die Anfragen kamen nicht antworten. Daher die Frage: Woher weiß BizTalk, für welche der Arbeitsdienstinstanzen die Antwort vom externen System bestimmt ist?
      Die Antwort ist einfach, logisch und im Orchestrierungsdesigner mit nur wenigen Klicks implementiert. Jede auf dem Sendeport ausgehende Nachricht muss auf Correlation_ID gesetzt sein. In diesem Fall ist das Feld OrderNo für seine Rolle ideal geeignet. Sie muss direkt aus dem Kontext der XML-Nachricht angegeben werden. Dieselbe Correlation_ID wird auch festgelegt, um auf die Anforderung zu antworten. Somit warten viele Dienste auf eine Antwort und viele Antworten. Um miteinander zu kommunizieren, verwendet der Call Control Agent das Feld Bestellnr. Das heißt, wenn die Instanz "A" die Bestellnummer "35" und die Instanz "B" die Bestellung "47" gesendet hat, wird die Antwort auf die Bestellung "47" an die Instanz "B" und auf die Bestellung "35" - "A" zurückgegeben.
    5. Sobald eingegangene Antworten werden die Ergebnisse vom Manager überprüfen und aus dem Lager. Wenn alles in Ordnung ist, erhält der Benutzer eine Benachrichtigung über den erfolgreichen Abschluss seiner Bestellung, und die Bestellung selbst wird an das System des Produktanbieters weitergeleitet. Andernfalls wird der Benutzer eine Nachricht erhalten, den Grund beschreibt, warum seine Bestellung nicht befriedigt werden kann. Daraufhin wird der Dienst die Arbeit abschließen;


    In diesem Beispiel arbeitete der Dienst mit 4 Ports. Jeder von ihnen verfügt über ein eigenes System (es kann sich beispielsweise um Oracle Retail-, Dynamics-, JMS- und Web Sphere-Ports oder etwas anderes handeln), der Dienst selbst sollte sich jedoch keine Gedanken darüber machen, welches. Details zur Nachrichtenübermittlung, Autorisierung und Nachrichtenkonvertierung in das gewünschte Format für jedes der Systeme finden auf der Ebene des Adapters und der zugeordneten Pipeline statt. Auch Transportprobleme und mögliche Lieferfehler werden auch mit herkömmlichen Mitteln gelöst, und keine Umsetzung auf der Ebene des Service erfordern (obwohl , wenn es erforderlich ist, kann dies innerhalb des Orchesters erfolgen).

    Wie Sie sehen, impliziert dieser Ansatz zur Erstellung von Geschäftsprozessen ausschließlich die Implementierung von Geschäftslogik und ermöglicht es Ihnen, die Systeme, mit denen Sie Nachrichten austauschen müssen, vollständig zu abstrahieren.

    Vielen Dank für Ihre Aufmerksamkeit, ich hoffe, Sie waren interessiert.

    Referenzen:


    • WROX: Professioneller BizTalk Server 2006
    • APRESS: Pro BizTalk 2009
    • PACKT: SOA-Muster mit BizTalk Server 2009



    Jetzt auch beliebt: