Auftragsfluss durch den Prozess-Manager
In diesem Abschnitt wird beschrieben, wie der Southridge Video-Bestellprozess-Manager, die OrderManager-Orchestrierung , Bestellungen verarbeitet. In diesem Abschnitt wird der Weg eines neuen Auftrags durch die Orchestrierung verfolgt. In diesem Abschnitt wird ferner vorgestellt, wie die Orchestrierung Auftragsänderungen verarbeitet.
Hinweis
Die Lösung für die Geschäftsprozessverwaltung enthält nur einen Prozess-Manager, obgleich sie so entwickelt wurde, dass mehrere Typen von Managern verwendet werden können.
Die OrderManager-Orchestrierung koordiniert untergeordnete Orchestrierungen, die den Geschäftsprozess implementieren, um den Auftrag zu verarbeiten. Der OrderManager sendet die Bestellung über zwei Phasen, die kombiniert die Bestellung überprüfen, die Informationen an die Anlagengruppe senden, die Bestellung über Remotingkomponenten an das Bestellsystem senden und den Bestellverlauf aktualisieren. Sie können diese Phasen hinzufügen, löschen oder ändern, ohne den OrderManager ändern zu müssen.
Hinweis
Aufgrund der Größe und des Umfangs der OrderManager-Orchestrierung können Sie diesen Abschnitt mit der in Microsoft Visual Studio geöffneten Orchestrierung lesen.
Struktur der Orchestrierung „OrderManager“
Die OrderManager-Orchestrierung beginnt mit einer Empfangsform, die die Orchestrierung aktiviert. Das folgende Diagramm zeigt die allgemeine Struktur der OrderManager-Orchestrierung .
Die erste Form Empfangen hat zwei Hauptverzweigungen. Die erste Verzweigung rechts dient zum Verarbeiten neuer Aufträge. Aufgabe der linken Verzweigung ist die Auftragsstornierung. Da es Benutzereingaben akzeptiert, ist es möglich, dass der OrderManager eine Auftragsstornierung erhält, nachdem eine Bestellung bereits abgeschlossen wurde. Diese Aufgabe übernimmt die linke Verzweigung. Die Verzweigung verarbeitet die isolierte Stornierung durch Festlegen von Kennzeichen für das Beenden der Verarbeitung und durch Hinzufügen einer Warnung zum Ereignisprotokoll. Die Orchestrierung verarbeitet Auftragsstornierungen, die eingehen, während ein Auftrag in der rechten Verzweigung verarbeitet wird.
Die Verzweigung zur Auftragsverarbeitung führt eine Initialisierung durch und gelangt anschließend in zwei geschachtelte Schleifen. Die äußere Schleife wird für jede Stufe der Auftragsverarbeitung einmal ausgeführt. Die innere Schleife wird ausgeführt, während die Stufe die Verarbeitung vornimmt. Der Auftrags-Manager führt auch eine Überprüfung auf mögliche Änderungen am Auftrag innerhalb der inneren Schleife durch. Nach Abschluss der Schleifen sendet der Auftrags-Manager eine Abschlussnachricht.
Die Auftragsverarbeitungsphasen verwenden dynamische, sich selbst korrelierende Ports, um an die OrderManager-Orchestrierung zurück zu kommunizieren. Dadurch wird die Korrelation des OrderManagers mit den Phaseninstanzen vereinfacht, da die Verwendung eines Korrelationssatzes entfällt. Weitere Informationen zu sich selbst korrelierenden Ports finden Sie unter Portbindungen.
Empfangen von Aufträgen
Der OrderManager empfängt Auftragsmeldungen von der OrderBroker-Orchestrierung über den FromBrokerPort-Port . Dieser Port ist direkt an die MessageBox-Datenbank gebunden. Die Orchestrierung verfügt über zwei Empfangsformen , die mit dem Port verbunden sind: eine für neue Bestellungen und eine für aktualisierte Bestellungen.
Der OrderManger bestimmt anhand eines Filterausdrucks, welche Nachrichten verarbeitet werden sollen. Der Filterausdruck testet den Wert im Nachrichtenfeld status und im Feld Order Manager-Typ, OrderMgrType. Wenn das Feld status gleich ACCEPTED und OrderMgrType CABLEORDER ist, ist die Bestellung neu und für diesen Prozess-Manager vorgesehen.
Der neue Auftrag aktiviert eine neue Instanz der Orchestrierung. Der OrderManager überprüft als Nächstes den Typ der Anforderung in einem Decision-Shape . Wenn der Typ Beenden ist, führt die Orchestrierung die linke Verzweigung aus und beendet den Auftrag. Andernfalls setzt die Orchestrierung die Verarbeitung des Auftrags fort. Dies umfasst auch die Überwachung auf nachfolgende Nachrichten mit Bezug auf diesen bestimmten Auftrag.
Initialisierung für neue Aufträge
Nachdem die OrderManager-Orchestrierung eine erste Nachricht empfangen und den Standard rechten Branch beginnt, ruft sie ihre Konfigurationsinformationen aus dem SSOConfigStore ab. Dies geschieht über ein Singleton-Objekt, das in der Utilities-Assembly definiert ist. Die Konfigurationswerte sind Eigenschaften des Objekts. Das Objekt verwaltet wie bei der Lösung für die dienstorientierte Architektur einen lokalen Cache der Konfigurationswerte. Weitere Informationen zum Singleton-Objekt finden Sie unter Verwenden von SSO Efficiently in der Business Process Management Solution.
Wie die dienstorientierte Lösung verwendet die Lösung für die Geschäftsprozessverwaltung den geheimen Speicher, weil er bei jeder Installation von BizTalk vorhanden ist, weil SSO darin die Konfigurationsinformationen zwischenspeichert, damit die Werte jederzeit verfügbar sind, und weil in diesem Speicher Informationen wie Datenbankverbindungszeichenfolgen und -kennwörter geschützt sind. Aus all diesen Gründen wäre der Geheimspeicher ein guter Ort für die Konfigurationsinformationen, auch wenn single Sign-On nicht zum Verwalten von Verbindungen mit den Back-End-Anwendungen verwendet würden.
Hinweis
Die Orchestrierung ruft Konfigurationsinformationen ab, ehe die Verarbeitung gestartet wird. Dies gewährleistet, dass die Orchestrierung dieselbe Konfiguration verwendet, wenn sie zuerst pausiert und anschließend wieder aktiviert wird. Weitere Informationen zur Dehydrierung finden Sie unter Orchestrierungshydrierung und Rehydrierung.
Der Auftrags-Manager verwendet einen Wert aus den Konfigurationsdaten: TotalStages, die Gesamtzahl der Phasen im Auftragsverarbeitungsprozess. Der Manager weist diesen Wert einer lokalen Variablen numStages zu. Außerdem werden zwei weitere Variablen festgelegt, die mit der äußeren Schleife verbunden sind: Stage und Stop. Die Stufe gibt die aktuelle Phase an und ist der Zähler für die äußere Schleife. beenden Sie den Stoppwert.
Schließlich legt der Manager die OrderStatus-Variable auf STARTED fest und wechselt in die äußere Verarbeitungsschleife.
Neue Auftragsverarbeitungsschleifen
Die äußere Schleife wird so lange ausgeführt, wie der Wert der Stufenvariable kleiner als der Wert der numStages-Variablen ist. Die äußere Schleife steuert die Verarbeitung der einzelnen Stufen. Die innere Schleife wird so lange ausgeführt, wie die Verarbeitung einer Stufe läuft. Dabei führt sie auch eine Überwachung auf mögliche Auftragsänderungen durch.
Äußere Schleife
Die Orchestrierung beginnt die äußere Schleife, indem die empfangene Nachricht (NewOrderMgrMsg) einer Variablen, OrderMgrMsg, zugewiesen wird. Anschließend werden Stufe und Status in den Routingteil der Nachricht kopiert. Die Orchestrierung legt auch die Rückgabeadresse in der Nachricht auf die Adresse des StageCompletionPort fest:
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
Die Orchestrierung sendet dann die Bestellung an den StagePort, einen Solicit-Response-Port. Die Orchestrierung wartet anschließend auf eine Bestätigung der Stufe, die von der Auftragsverarbeitung gestartet wurde. Die Phase sendet eine OrderAck-Nachricht , wenn sie mit der Verarbeitung der Bestellung beginnt.
Hinweis
Die OrderAck-Nachricht ist eine von mehreren in der Lösung, die durch .NET-Klassen und nicht durch ein Schema definiert wird. Weitere Informationen zur Verwendung von .NET-Klassen zum Definieren von Nachrichten finden Sie unter Erstellen von Nachrichten im Benutzercode.
Wenn die Orchestrierung die Bestätigung empfängt, weist sie die Phase der variablen currentStage zu und wechselt in die innere Schleife.
Innere Schleife
Die innere Schleife wird so lange ausgeführt, wie die currentStage-Variable gleich der Stufenvariable ist. das heißt, solange die aktuelle Phase verarbeitet wird. Der Textkörper der Schleife ist ein Listen-Shape mit drei Empfangsformen . Die linksste Form in der Orchestrierung, Order Request, ist Teil des Auftragsaktualisierungsmechanismus, der im nächsten Abschnitt beschrieben wird.
Wenn eine Auftragsverarbeitungsphase abgeschlossen ist, sendet sie eine Nachricht an den StageCompletion-Port der OrderManager-Orchestrierung . Wenn die Phase aufgrund eines Fehlers abrupt beendet wird, sendet sie eine TerminatedMessage. In diesem Fall löst der OrderManager eine Ausnahme aus. Der äußerste Ausnahmehandler fängt die Ausnahme ab und sendet eine Fehlermeldung an den OperatorPort.
Wenn die Phase einen OrderMgrMsg sendet, erhöht der OrderManager die Stufenvariable . Wenn mehr Phasen vorhanden sind (Stufe kleiner oder gleich numStages), legen die Orchestrierungen die Reihenfolge status in OrderMgrMsg auf STAGE_n_COMPLETED fest, wobei n die Nummer der aktuellen Stufe ist. Wenn keine weiteren Stufen vorhanden sind, legt die Orchestrierung den Auftragsstatus auf COMPLETED fest und beendet beide Schleifen.
Updates bestellen
Die OrderManager-Orchestrierung lauscht innerhalb der inneren Verarbeitungsschleife auf Auftragsaktualisierungen. Beachten Sie, dass die dafür verwendete EmpfangsformOrderRequest auch den FromBrokerPort verwendet. Eine zweite Empfangen-Form für denselben Port innerhalb einer Schleife bildet in Kombination mit Korrelationssätzen ein gängiges BizTalk Server-Muster, das Konvoimuster. Mithilfe des Konvoimusters können Sie sicherstellen, dass dieselbe Instanz einer Orchestrierung die erste und nachfolgende Nachrichten verarbeitet, die mit einem bestimmten Vorgang verbunden sind.
Wenn der Auftrags-Manager die erste Nachricht in Verbindung mit einem Auftrag empfängt, werden zwei Korrelationssätze initialisiert. Die erste, OrderCorrelation, verwendet die Kunden-ID (CustID) und die Bestell-ID (OrderID). Der Auftrags-Manager nutzt diese Korrelation gemeinsam mit den Auftragsverarbeitungsstufen. Die zweite Korrelation ist die Konvoikorrelation, OrderConvoyCorrelation, die neben der Kunden-ID und der Bestell-ID die Order status (Status) verwendet. Das OrderRequestReceive-Shape verwendet OrderConvoyCorrelation als Folgenden Korrelationssatz. Durch ein derartiges Festlegen des Korrelationssatzes wird sichergestellt, dass die Instanz des Auftrags-Managers, die einen bestimmten Auftrag verarbeitet, etwaige Änderungen empfängt.
Hinweis
Ein Korrelationssatz ist eine Gruppe von Nachrichteneigenschaften, anhand der bestimmt wird, ob eine Nachricht zu einer gegebenen Instanz einer Orchestrierung gehört oder nicht. Weitere Informationen finden Sie unter Verwenden von Korrelationen in Orchestrierungen.
Wenn der OrderManager eine nachfolgende Nachricht für einen Auftrag empfängt, wird zunächst der Anforderungstyp getestet. Ist der Anforderungstyp TERMINATE, führt die Form Entscheidung die Beendigungsverzweigung aus. Andernfalls prüft die Orchestrierung, ob die neue Nachricht eine Änderung ist. Eine Updatenachricht hat eine höhere Sequenznummer (SeqNum) als die ursprüngliche Anforderung. Wenn die Sequenznummer der neuen Nachricht höher ist, startet die Orchestrierung die Auftragsverarbeitung mit der neuen Nachricht erneut. Wenn die ursprüngliche und die Änderungsnachricht dieselbe oder eine niedrigere Sequenznummer haben, tritt ein Sequenzfehler auf. Sind die Sequenznummern identisch, liegt ein duplizierter Auftrag vor, der mit einem Duplikatfehler gekennzeichnet wird.
Weitere Informationen zu SeqNum finden Sie unter Schlüsselmeldungen und Felder.
Abschließende Schritte
Nach dem Beenden der Schleifen weist der Auftragsmanager die Antwortadresse dem dynamischen Port CSRCompletionPort zu. Der Manager erstellt anschließend die Abschlussstatusnachricht, sendet diese und prüft anschließend, ob ein Fehler vorliegt. Wenn ein Fehler vorliegt, führt die Orchestrierung eine Form vom Typ „Beenden“ aus. Andernfalls wird der Manager lediglich beendet.
Koordination mit den Stufen
Sowohl die OrderBroker-Orchestrierung als auch die orchestrierung der zweiten Verarbeitungsphase (CableOrder2) erstellen Einträge in der Verlaufsdatenbank. Die CableOrder2-Orchestrierung aktualisiert die von der OrderBroker-Orchestrierung eingegebenen Verlaufsinformationen. Um sicherzustellen, dass in der zu aktualisierenden Datenbank ein Eintrag vorhanden ist, verwendet OrderBroker die Übermittlungsbenachrichtigung für den Port, den er für die Datenbank verwendet.
Die Konfiguration ordnet den OrderBroker-Sendeport für die Verlaufsdatenbank einer Sendeportgruppe zu, die zwei Ports enthält– einen Port für die Testkonfiguration (HistoryInsert-Test-SP), einen für die reguläre Konfiguration (HistoryInsert-SP). Wenn Sie weiter beide Ports in der Gruppe aktiv lassen, sendet die Lösung Nachrichten an beiden Ports. Somit werden zwei Zustellungsbenachrichtigungen angefordert, von denen aber nur eine verarbeitet wird.
Um diese Situation zu vermeiden, heben Sie die Registrierung des Testports (HistoryInsert-Test-SP) auf, oder beenden Sie die Testversion der Anwendung. Weitere Informationen zu Übermittlungsbenachrichtigungen finden Sie unter Verwenden von Bestätigungen.
Fehler und Routing korrigierter Nachrichten – Entwurfsoptionen
Die Von den Auftragsverarbeitungsphasen verwendete Orchestrierung und Orchestrierungen des Ausnahmehandlers verwenden eine Fehlerbehandlungsorchestrierung (ErrorHandlerOrch), um fehlerhafte Aufträge für die Reparatur weiterzuleiten. Der Entwurf setzt voraus, dass es eine Abteilung oder Gruppe gibt, die den Auftrag in die benötigte Form ändert. Der reparierte Auftrag wird nicht über die OrderBroker-Orchestrierung (OrderBroker) erneut übermittelt. Stattdessen wird der normalisierte Auftrag in seine normalisierte Form geändert. Der aktuelle Entwurf der Lösung sieht vor, dass die Handlerorchestrierung die Fehlermeldung zurück zur Quelle des ursprünglichen Auftrags leitet. Korrigierte Aufträge müssen jedoch zu einem MSMQ-Port für die Fehlerhandlerorchestrierung geleitet werden. (Die Testversion der Projektmappe verwendet einen Dateiordner.) Der Fehlerhandler gibt dann die reparierte Nachricht an die aufrufende Orchestrierung zurück.
Diese Lösung arbeitet nach diesem Prinzip, da die Orchestrierung OrderBroker die Auftragsnachricht umfassend überprüft und normalisiert. Die zu korrigierende Auftragsnachricht liegt wiederum auch in der normalisierten Form vor. Das Verwalten der normalisierten Form der Nachricht verhindert, mit einer Umgehungslösung für den Unterschied zwischen der gesendeten und der normalisierten Form der Nachrichten arbeiten zu müssen.