In einem typischen verteilten Geschäftsprozess gibt es eine Reihe von Schritten, die Daten normalerweise durchlaufen müssen. Sie werden von einer externen Quelle in einem Fremdformat geliefert, sie werden bestätigt und interpretiert, sie werden in ein bearbeitbares Format konvertiert, sie werden validiert und geparst, sie werden analysiert, sie werden in eine Geschäftsanwendung eingespeist oder zur späteren Verwendung gespeichert, sie werden für Zwischenberichte zusammengestellt, sie werden (in modifizierter Form) an nachfolgende Anwendungen oder externe Partner weitergereicht. Auf diesem ganzen Weg werden Anwender oder andere Systeme häufig über den Fortschritt der Daten an jedem dieser Punkte informiert. Dieses Szenario hat viele Variationen, aber unabhängig von der konkreten Reihenfolge dürften die oben genannten Schritte recht typisch sein.
Falls man das oben vorgestellte Prinzip beherzigt, finden die meisten dieser Schritt im Biztalk Explorer anstatt in Orchestrierungen statt. Die einzigen Ausnahmen wären konkret das Einfügen von Daten in einen Geschäftsprozess und das, was mit diesen Daten innerhalb dieses Prozesses geschieht. Die Schöpfer von Biztalk werden nicht gerade begeistert sein über diesen minimalistischen Einsatz der Orchestrierungsfunktion (denn wenn man will, kann man schließlich fast alle diese Schritte auch in einer Orchestrierung durchführen), aber ein Designansatz mit einer solch sauberen Trennung bringt eine Reihe von Vorteilen mit sich:
Hier ein alltägliches Szenario: Ein Auftrag von einem externen Partner wird über TCP empfangen. Eine Biztalk-Pipeline nimmt ihn am entsprechenden Port entgegen, validiert ihn, identifiziert den Absender und schickt dann eine Auftragsbestätigung zurück. Der Auftrag wird als XML-Dokument abgebildet. Dieses XML-Dokument wird geparst und zu Auftragselementen transformiert, die .NET-Typen entsprechen, und der Datensatz wird schließlich in einer SQL-Auftragstabelle gespeichert.
Bei diesem Beispiel werden die Empfangs- und Sende-Adapter-Funktionen des Biztalk Explorers verwendet, um die eingehenden Daten zu filtern und, basierend auf dieser Filterung, Entscheidungen über deren Speicherung (auf unterschiedlichen Stufen) zu treffen. Bei diesem speziellen Szenario wird sowohl der eingehende Auftrag als auch die zurückgeschickte Bestätigung archiviert. Ein Ordner dient zur Weiterleitung der XML-Version des Auftrags an die Orchestrierung, und die Archive dienen gleichzeitig als Log, das nicht nur festhält, was empfangen, sondern auch, was dem Absender geschickt wurde.
Warum? Falls etwas schief geht und der Orchestrierungsteil des Prozesses ausfällt, bleibt der Auftrag so lange in dem Ordner gespeichert, bis der Prozess wieder aufgenommen wird. Für den Neustart muss man im Prozess nicht weiter zurückgehen, denn es gibt einen Zeitstempel auf der Zwischenversion des Auftrags, dem man entnehmen kann, wann es zu Problemen kam. Den Biztalk Explorer-Teil des Prozesses kann man weiterlaufen lassen, während man den Fehler behebt, in der Gewissheit, dass Aufträge sich unterdessen auf sichere Weise im Ordner der noch zu bearbeitenden Messages sammeln.
Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…
Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…
Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…
Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.
Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…
Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.