Freigeben über

Verwenden des Routings fehlgeschlagener Nachrichten

Die Fehlerbehandlungseinrichtung ermöglicht es dem Designer, die automatisierte Behandlung von Messagingfehlern als Alternative zum herkömmlichen (jetzt Standard) Verhalten des Platzierens fehlgeschlagener Nachrichten in der angehaltenen Warteschlange festzulegen. Diese automatisierte Verarbeitung leitet eine Fehlermeldung an jedes abonnierte Routingziel weiter, z. B. an einen Sendeport oder eine Orchestrierung. Die Fehlermeldung ist ein Klon der ursprünglichen Nachricht mit allen zuvor höhergestuften Eigenschaften, die jetzt herabgestuft wurden, und mit ausgewählten Eigenschaften im Zusammenhang mit dem spezifischen Messagingfehler, der in den Nachrichtenkontext heraufgestuft wurde.

Warnung

Fehlgeschlagene Nachrichten enthalten eine Kopie der ursprünglichen Nachricht. Wenn die ursprüngliche Nachricht vertrauliche Informationen enthält, entwerfen Sie Ihre manuellen und automatischen fehlgeschlagenen Nachrichtenprozesse so, dass diese eine versehentliche Offenlegung vermeiden.

Woraus besteht fehlgeschlagene Nachrichtenweiterleitung?

Wenn das Routing fehlgeschlagener Nachrichten aktiviert ist, hält BizTalk Server die Nachricht nicht an. Stattdessen wird die Nachricht weitergeleitet. Fehlgeschlagenes Nachrichtenrouting kann sowohl für Empfangs- als auch für Sendeports aktiviert werden, mit folgenden Ergebnissen:

  • Wenn die Nachrichtenweiterleitung für einen Empfangsport aktiviert ist und eine Nachricht in der Empfangspipeline oder im Routing fehlschlägt, wird eine fehlgeschlagene Nachricht generiert. In dem Fall, in dem ein Fehler in oder vor der Demontagephase auftritt, ist die Fehlermeldung ein Klon des ursprünglichen Austauschs.

  • Wenn das Routing fehlgeschlagener Nachrichten in einem Sendeport aktiviert ist und die Nachricht in der Sendepipeline fehlschlägt, wird eine fehlgeschlagene Nachricht generiert.

    Wenn eine fehlgeschlagene Nachricht generiert wird, fördert BizTalk Server fehlerberichtbezogene Nachrichtenkontexteigenschaften und herabgestuft reguläre Nachrichtenkontexteigenschaften vor dem Veröffentlichen der fehlgeschlagenen Nachricht. Vergleichen Sie dieses Verhalten mit dem Standardverhalten, wenn das Routing fehlgeschlagener Nachrichten nicht aktiviert ist: Nachrichten, die fehlschlagen, werden angehalten.

Welche Arten von Messagingfehlern lösen eine Fehlermeldung aus?

Alle Fehler, die bei der Adapterverarbeitung, Pipelineverarbeitung, Zuordnung oder Nachrichtenrouting auftreten, führen zu einer Fehlermeldung, wenn das Routing für fehlgeschlagene Nachrichten aktiviert ist. Wenn ein Messagingfehler auftritt, während eine Orchestrierung von einem Empfangsport empfängt oder an einen Sendeport sendet, wird die resultierende Fehlermeldung den Nachrichtenports zugeordnet, die durch die Orchestrierung angebunden sind.

Abonnieren einer Fehlermeldung

Fehlermeldungen werden an Orchestrierungen oder an Sendeports übermittelt, die sie abonniert haben. Ein Abonnement wählt in der Regel eine Fehlermeldung basierend auf dem Namen des Ports aus, in dem der Messagingfehler aufgetreten ist (entweder ein Sende- oder ein Empfangsport). Ein Abonnement kann auch nach anderen Eigenschaften filtern, die in den Nachrichtenkontext des Fehlers aufgenommen werden (z. B. InboundTransportLocation oder FailureCode).

Fehlermeldungsspezifikation

Eine Fehlermeldung ist ein Klon der ursprünglichen misslungenen Nachricht, wobei alle zuvor beförderten Attribute zurückgestuft und eine Reihe von fehlerspezifischen Attributen in den Nachrichtenkontext befördert werden. Zuvor höhergestufte Eigenschaften werden herabgestuft, um die unbeabsichtigte Übermittlung an Abonnenten zu vermeiden, die nicht für den Empfang der Fehlermeldung vorgesehen sind. Die Fehlermeldung wird für die Verteilung an Abonnenten (Orchestrierungen, Sendeports und Sendeportgruppen) veröffentlicht.

Die Eigenschaften, die in den Kontext einer Fehlermeldung eingebunden werden, fallen alle unter den ErrorReport-Namespace in BizTalk Server. Sie sind wie folgt:

Eigenschaftsname Datentyp Gefördert BESCHREIBUNG
Fehlercode xs:string Ja Fehlercode. Ein hexadezimaler Wert, der in der BizTalk Server-Verwaltungskonsole gemeldet wird.
Fehlerkategorie xs:int Ja Diese Eigenschaft wird nicht verwendet. Der Wert ist nicht definiert.
BESCHREIBUNG xs:string Nein Fehlerbeschreibung. Der im Anwendungsereignisprotokoll verzeichnete Diagnosetext bezüglich dieses Messagingfehlers ist derselbe.
Nachrichtentyp xs:string Ja Der Nachrichtentyp der fehlgeschlagenen Nachricht oder leer, wenn der Nachrichtentyp unbestimmt ist.

BizTalk Server verwendet den Nachrichtentyp, um Nachrichten ihren XML-Schemas zuzuordnen. Der Nachrichtentyp wird durch Kombinieren des Schemanamespaces mit dem Schemastammknoten gebildet: http://mynamespace#rootnode. Anmerkung: Nachrichten, die fehlschlagen, bevor der Nachrichtentyp bestimmt wird, verfügen nicht über diesen Eigenschaftensatz.
Empfangsportname xs:string Höhergestuft , wenn der Fehler während der eingehenden Verarbeitung (in einem Empfangsport) aufgetreten ist

Nicht höhergestuft , wenn der Fehler in einem Sendeport aufgetreten ist.		 Name des Empfangsports, an dem der Fehler aufgetreten ist.
InboundTransportLocation xs:string Höhergestuft , wenn der Fehler während der eingehenden Verarbeitung (in einem Empfangsport) aufgetreten ist

Nicht höhergestuft , wenn der Fehler in einem Sendeport aufgetreten ist.		 URI des Empfangsorts, an dem der Fehler aufgetreten ist.
SendPortName xs:string Höhergestuft , wenn der Fehler während der ausgehenden Verarbeitung (in einem Sendeport) aufgetreten ist

Nicht befördert, wenn der Fehler in einem Empfangsport aufgetreten ist.		 Name des Sendeports, an dem der Fehler aufgetreten ist.
Standort für ausgehenden Transport xs:string Höhergestuft , wenn der Fehler während der ausgehenden Verarbeitung (in einem Sendeport) aufgetreten ist

Nicht weitergeleitet wenn der Fehler in einem Empfangsport aufgetreten ist.		 URI des Sendestandorts, an dem der Fehler aufgetreten ist.
Fehlertyp xs:string Ja Gibt den Typ der Nachricht an, die der Fehler enthält. Diese Eigenschaft enthält immer den Wert FailedMessage, d. h., der Fehler enthält die ursprüngliche fehlgeschlagene Nachricht.
RoutingFehlerBerichtID xs:string Ja Diese Eigenschaft stellt die ID des Routingfehlerberichts bereit, den BizTalk Server generiert, wenn ein Routingfehler auftritt. Ein Routingfehlerbericht ist eine spezielle Meldung, die BizTalk Server generiert und in den Ruhezustand versetzt. Diese Nachricht verfügt nicht über einen Textkörper, hat aber den Kontext der fehlgeschlagenen Nachricht. Mithilfe dieser ID kann eine Fehlerbehandlungs-Orchestrierung oder ein Sendeport die MessageBox-Datenbank abfragen und den Routingfehlerbericht verarbeiten. Beispielsweise kann eine Orchestrierung den Bericht über Routingfehler beenden, nachdem sie die fehlgeschlagene Nachricht erhalten hat.
Ausfallzeit xs:dateTime Datumszeit des Auftretens des Fehlers
Fehlermeldungs-ID xs:string
Fehlerinstanzkennung xs:string
Fehleradapter xs:string

Behandeln von Fehlermeldungen

Die Fehlerbehandlung wird durch ein Orchestrierungs- oder Sendeportabonnement angegeben, dessen Filter den Eigenschaften entsprechen, die in den Nachrichtenkontext der Fehlermeldung promotiert wurden.

Sicherheitsauswirkungen

Die mit der ursprünglichen Nachricht verknüpfte Identität – entweder die ursprüngliche Identität oder die endgültige Identität, die durch die Resolve Party-Phase der Empfangspipeline bestimmt wird – wird der Fehlermeldung zugewiesen.

Die Sicherheitsmechanismen, die die Übermittlung von Nachrichten an autorisierte abonnierte Ports und Orchestrierungen einschränken, gelten auch für Fehlermeldungen.

Ein Sendeport, der eine Fehlermeldung abonniert, aber nicht mit einem entsprechenden Entschlüsselungszertifikat konfiguriert ist, empfängt keine Fehlermeldungen, die aus Messagingfehlern bei oder vor der Entschlüsselungsphase der Empfangspipeline resultieren, über die die ursprüngliche Nachricht BizTalk Server eingegeben hat. Stattdessen werden die fehlgeschlagenen Nachrichten in der Angehaltenen Warteschlange platziert.

Adapternachrichtenfehler

Wenn ein Adapter eine Nachricht aussetzt, wird eine Fehlermeldung veröffentlicht. Es wird keine Fehlermeldung generiert, wenn die Nachricht nicht angehalten wird.

Transaktionale Empfangspipelines

Wenn eine Transaktions-Empfangspipeline eine Ausnahme auslöst (gibt an, dass die Transaktion abgebrochen werden soll), wird die Transaktion abgebrochen und eine Fehlermeldung veröffentlicht.

Wenn eine Transaktions-Empfangspipeline eine Nachricht explizit aussetzt (angibt, dass MessageDestination = SuspendQueue), kann die aktuelle Transaktion weitergeführt werden (und abgeschlossen werden, es sei denn, nachfolgende Phasen geben an, dass sie abgebrochen werden soll), und die resultierende Fehlermeldung wird veröffentlicht.

Solicit-Response Sende-Ports

Wenn eine Anforderungsnachricht von einer Orchestrierung gesendet wird und die Übertragung fehlschlägt oder die Antwort bei der eingehenden Verarbeitung fehlschlägt, erhält die Orchestrierung eine Ausnahmebedingung, unabhängig davon, ob die fehlgeschlagene Nachricht weitergeleitet wurde.

In dem Fall, in dem ein Send-Port für die Anforderungsantwort mit einem Anforderungsantwort-Empfangsport verbunden ist, erhält der Empfangsport entweder eine Antwortnachricht (wenn die Übertragung erfolgreich ist) oder ein NACK (wenn die Übertragung fehlschlägt), unabhängig davon, ob die fehlgeschlagene Nachricht weitergeleitet wurde.

One-Way Sende-Ports

Wenn eine Nachricht von einer Orchestrierung über einen sendeport gesendet wird, der für die Übermittlungsbenachrichtigung konfiguriert ist, empfängt die Orchestrierung eine Zustellungsbenachrichtigung, unabhängig davon, ob die Fehlermeldung weitergeleitet wurde. Mit anderen Worten, der Sendeport generiert eine Übermittlungsbenachrichtigung für die Orchestrierung, selbst wenn während der Verarbeitung ein Fehler im Messaging auftritt. Die Benachrichtigung bestätigt die Übermittlung an den Hafen, aber nicht die erfolgreiche Verarbeitung durch den Hafen.

Wiederaufnahme angehaltener Nachrichten

Die meisten Nachrichten, die bei der eingehenden Verarbeitung fehlschlagen (d. h. verarbeitung von und einschließlich des Empfangsadapters und bis hin zur Veröffentlichung im Meldungsfeld), und deren Fehler nicht behandelt werden, werden als fortsetzungsfähig angehalten. Die Ausnahme besteht darin, dass Anforderungsnachrichten von bidirektionalen Empfangsports als nicht wiederaufnehmbar angehalten werden.

Nachrichten werden in der Regel in ihrer ursprünglichen Form (wie vor der Pipelineverarbeitung) zurückgehalten, mit zwei Ausnahmen:

  • Nachrichten, die von Pipelinekomponenten angehalten werden. BizTalk Server setzt diesen Nachrichtentyp in derselben Form aus, wie er der fehlgeschlagenen Pipeline-Komponente bereitgestellt wurde. Wenn die Nachricht fortgesetzt wird, wird sie von Beginn derselben Pipeline an verarbeitet. Dies bedeutet, dass eine Pipelinekomponente in einer Pipelinephase, die der Phase vorausgeht, in der der ursprüngliche Fehler aufgetreten ist, bereit sein muss, die "gleiche" Nachricht in einem Formular zu verarbeiten, das sich von der ursprünglichen Form unterscheidet, in der sie diese Nachricht verarbeitet hat.

  • Nachrichten aus wiederherstellbarem Austauschausbau, die anschließend beim Routing fehlschlagen. BizTalk Server hält diesen Nachrichtentyp in der gleichen Form an, in der sie veröffentlicht wurde. Dies ist die Form, die die Nachricht nach der Pipelineausführung hatte. Wenn die Nachricht fortgesetzt wird, überspringt sie die Pipelineverarbeitung und wird direkt in der MessageBox-Datenbank veröffentlicht.

Szenarien, die zu angehaltenen (nicht reaktivierbaren) Nachrichten führen

Es ist zwar häufiger, dass Nachrichten als wiederaufnehmbar angehalten werden, es gibt jedoch einige Szenarien, die zu nicht wiederaufnehmbaren Nachrichten führen.

  • In einem Sendeport mit geordneter Zustellung, bei dem "Fortfahren bei Fehler" aktiviert ist, tritt bei einem Fehler in der Pipeline, Zuordnung oder Übertragung der Betrieb weiterhin fort.

  • In einem Empfangsport für die geordnete Zustellung, wenn der Adapter so konfiguriert ist, dass Nachrichten bei einem nicht fortsetzbaren Fehler angehalten werden. Wenn z. B. die MSMQ-Adaptereinstellung "Bei Fehler" auf "Anhalten (nicht reaktivierbar)" festgelegt ist oder der MQSeries-Adapter "Suspend as Non Resumable" aktiviert ist, werden fehlerhafte Nachrichten als nicht resumierbar angehalten.

  • Bei einem bidirektionalem Empfangsport scheitert die Antwortnachricht, wenn sie in der Pipeline, Zuordnung oder Übertragung fehlschlägt.

  • Bei einem bidirektionalen Empfangsport schlägt die Empfangsnachricht in der Pipeline, Zuordnung oder Übertragung fehl. Das Verhalten einzelner Adapter kann unterschiedlich sein. Der HTTP-Adapter hält z. B. nachrichten standardmäßig nicht an, kann jedoch so konfiguriert werden.

Siehe auch

Fehlerbehandlung
Verwenden von Danksagungen
Geordnete Zustellung von Nachrichten

  • Last updated on