Freigeben über


Verarbeitung in der OrderBroker-Orchestrierung

In diesem Abschnitt wird beschrieben, wie die OrderBroker-Orchestrierung Bestellungen entgegennimmt und für einen Prozess-Manager vorbereitet. An Anfang dieses Abschnitts wird die allgemeine Funktionsweise der Orchestrierung beschrieben. Im nächsten Teil wird erläutert, wie die Orchestrierung eine Nachricht verarbeitet. Anschließend wird erklärt, wie die Orchestrierung eine atomarische Transaktion zum Verbessern der Systemleistung nutzt.

Hinweis

Aufgrund der Länge des OrderBroker-Codes sollten Sie diesen Abschnitt mit der in Microsoft® Visual Studio geöffneten Orchestrierung lesen.

Gründe für einen Auftragsbroker

Der Zweck der OrderBroker-Orchestrierung besteht darin, eine Bestellung vorzuverarbeiten und an den richtigen Prozess-Manager weiterzuleiten. Die Vorverarbeitung besteht hier aus dem Generieren von Informationsnachrichten für die Verlaufsdatenbank und für das Kundendienstsystem sowie dem Bestätigen des Auftragseingangs. OrderBroker erstellt auch eine generische Bestellnachricht aus der Kundendienstanfrage. Diese Normalisierung des Auftrags ermöglicht die allgemeine Nutzung des Auftrags durch Elemente im Geschäftsprozess.

Die Auftragsnachricht umfasst mehrere Teile, wobei die Routinginformationen von den Auftragsinformationen getrennt sind. Die Routinginformationen sind ebenfalls allgemein und können von beliebigen Auftrags-Managern genutzt werden. Dies wiederum führt dazu, dass die Lösung einfacher erweitert werden kann. Informationen zu mehrteiligen Nachrichten finden Sie unter Verwenden von mehrteiligen Nachrichtentypen.

Das Isolieren der Brokerfunktion ermöglicht auch deren Verschiebung in eine andere BizTalk-Gruppe. Da orderBroker die Veröffentlichung in der MessageBox-Datenbank ermöglicht , d. h. sie ist direkt gebunden, und es auch einfacher macht, den Broker in einer anderen Gruppe zu platzieren, können Sie den Broker verschieben, ohne die Orchestrierung zu ändern. Weitere Informationen zum Platzieren von OrderBroker in einer anderen Gruppe finden Sie unter Kommunikation zwischen OrderBroker und OrderManager.

Hinweis

Die OrderBroker-Orchestrierung weist dem Feld OrderMgrType in der Order Manager-Nachricht einfach eine konstante Zeichenfolge zu, da sie nur über einen OrderManager verfügt. Normalerweise würde bei einer Anwendung, bei der es mehrere Auftrags-Manager gibt, die Anwendung mithilfe der Geschäftsregel-Engine den ordnungsgemäßen Wert für dieses Feld bestimmen und das Auftragsrouting verwenden. Weitere Informationen zur Geschäftsregel-Engine finden Sie unter Erstellen und Verwenden von Geschäftsregeln.

Auftragsverwaltung

Die OrderBroker-Orchestrierung beginnt mit zwei Empfangs-Shapes in einem Listen-Shape . Eine Empfangsform nimmt Nachrichten vom Kundensupportsystem an. die andere, Nachrichten aus dem Anbietersystem. Nachrichten aus beiden Quellen haben das gleiche Schema.

Die Orchestrierung extrahiert die Rückgabeadresse aus der Nachricht und verwendet sie, um die Adresse für den dynamischen Port CSRPort festzulegen. Über diesen Port sendet die Orchestrierung Bestätigungen und Fehlermeldungen.

Die nächsten Schritte in der OrderBroker-Orchestrierung erstellen die Verlaufsmeldung, die Dienstnachricht, die Bestätigungsnachricht und die Bestellnachricht, die an die OrderManager-Orchestrierung gesendet werden soll. Die Orchestrierung verwendet die InsertOrderBody-Hilfsprogrammfunktion , um die Bestellnachricht der Verlaufsmeldung hinzuzufügen.

Hinweis

In bestimmten Situationen kann die Lösung Nachrichten generieren, die übermittelt, aber nicht genutzt werden. Die OrderBroker-Orchestrierung fügt über einen Sendeport Informationen in die Verlaufsdatenbank ein. Dieser Sendeport arbeitet mit einer Zustellungsbenachrichtigung. Die Konfiguration ordnet den Sendeport 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 ausführen, 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 BTSScn.BPM.OrderBrokerApp.Test. Weitere Informationen zu Übermittlungsbenachrichtigungen finden Sie unter Verwenden von Bestätigungen.

Beim Erstellen der Nachricht, die an die OrderManager-Orchestrierung gesendet werden soll, erstellt die OrderBroker-Orchestrierung eine mehrteilige Nachricht mit zwei Teilen. In einem Teil sind die Routinginformationen, im anderen Teil ist der Auftrag selbst enthalten. Der Routingteil der Nachricht , OrderMgrMsg.Routing, verwendet ein Schema, das von einer C#-Klasse in der SchemaClasses-Assembly definiert wird. Der Broker behandelt den Bestellteil der Nachricht als generisches oder typunabhängiges XML-Dokument (System.Xml. XmlDocument) und weist es OrderMgrMsg.Order zu.

Es gibt zwei Felder in den Routinginformationen, die für den Auftragsmanager besonders wichtig sind: OrderMgrMsg.Routing.OrderMgrType und OrderMgrMsg.Routing.Status. Der Broker legt orderMgrType auf den Typ des Auftragsmanagers fest, der die Bestellung verarbeiten soll. In der Lösung gibt es nur einen Auftrags-Manager, und das Feld ist auf CABLEORDER festgelegt. Der Broker legt auch das Feld Status auf ACCEPTED fest. Dies ist der Wert, der den Auftrags-Manager informiert, dass die Nachricht ein neuer Auftrag ist. Der Auftrags-Manager in der Lösung, OrderManager-Orchestrierung, verwendet eine Empfangsform, die nach dem Auftragstyp "CABLEORDER" und status gleich ACCEPTED filtert.

Die verbleibenden Schritte in der OrderBroker-Orchestrierung senden die verschiedenen Nachrichten an die entsprechenden Ports.

Verbessern der Leistung mit geschachtelten Bereichen

Einer der auffälligen Dinge bei der OrderBroker-Orchestrierung ist die Verwendung geschachtelter Bereiche. Die geschachtelten Bereiche dienen (teilweise) zum Verbessern der Systemleistung durch Einschränken der Dauerhaftigkeitspunkte.

Die Orchestrierungs-Engine speichert regelmäßig den Status der gesamten Orchestrierung an Ausführungspunkten, die Dauerhaftigkeitspunkte genannt werden. Die Orchestrierungs-Engine behandelt automatisch mehrere Orchestrierungs-Shapes, einschließlich Send-Shapes , als Persistenzpunkte. Eine Liste der Persistenzpunkte und weitere Informationen zu ihnen finden Sie unter Persistenz und Orchestrierungs-Engine.

Bei fünf Send-Shapes sollte die OrderBroker-Orchestrierung fünf Persistenzpunkte aufweisen. Wenn Sie jedoch Send shapes in einem atomischen Transaktionsbereich gruppieren, erkennt die Engine, dass nur ein Persistenzpunkt für den Bereich benötigt wird. Da vier der Send-Shapes in orderBroker-Orchestrierung nicht Teil von Ausnahmehandlern sind und nach dem Senden nichts getan werden muss, können sie in einen atomaren Transaktionsbereich wechseln. Dadurch verringert sich die Anzahl der Dauerhaftigkeitspunkte. Weitere Informationen zu atomaren Transaktionen finden Sie unter Atomic Transactions.

Darüber hinaus verwendet die Orchestrierungs-Engine einen einzelnen Dauerhaftigkeitspunkt für geschachtelte Transaktionen, wenn die Transaktionen alle zeitgleich enden. Die Art und Weise, wie die OrderBroker-Orchestrierung Transaktionen verschachtelt, reduziert daher die Persistenzpunkte weiter: Die Orchestrierung weist aufgrund der Verwendung von Bereichs-Shapes einen einzelnen Persistenzpunkt auf.

Tipp

Sie können die Leistung verbessern, indem Sie die Anzahl der Dauerhaftigkeitspunkte in einer Orchestrierung minimieren. Sie können Send-Shapes in einer atomaren Transaktion gruppieren, um einen einzelnen Persistenzpunkt für alle Send-Shapes zu erzeugen. Durch zeitgleiches Beenden geschachtelter Transaktionsbereiche wird ein einzelner Dauerhaftigkeitspunkt für die Transaktion generiert.

Ein atomarischer Transaktionsbereich darf keinen Ausnahmehandler haben. Aus diesem Grund schachtelt die Orchestrierung den atomarischen Bereich innerhalb einer lang andauernden Transaktion. Diese äußere Transaktion kann über einen Ausnahmehandler verfügen, und es ist dieser Handler, der eine Ausnahme aus den Send-Shapes verarbeitet.

Tipp

Das Schachteln einer atomarischen Transaktion in einer lang andauernden Transaktion ist ein gängiges Muster für das Ermöglichen einer Ausnahmebehandlung.

Weitere Informationen

Verarbeitung in der Geschäftsprozessverwaltungslösung
Prozess-Manager-Logik
Interruptbehandlung in der Lösung für die Geschäftsprozessverwaltung
Die Orchestrierung „ExceptionHandler“