Verwenden des Routings für fehlerhafte Nachrichten
Mit den Funktionen für die Fehlerbehandlung können Entwickler die automatische Behandlung von Messagingfehlern als Alternative zum herkömmlichen (jetzt standardmäßigen) Verhalten festlegen, bei dem fehlerhafte Nachrichten in die Warteschlange Angehalten eingefügt werden. Bei dieser automatischen Fehlerbehandlung wird eine Fehlermeldung an das abonnierende Routingziel (z. B. Sendeport oder Orchestrierung) weitergeleitet. Die Fehlermeldung ist ein Klon der ursprünglichen Nachricht, wobei alle zuvor höher gestuften Eigenschaften herabgestuft und ausgewählte Eigenschaften der jeweiligen Messagingfehler auf den Nachrichtenkontext höher gestuft werden.
Warnung
Fehlerhafte Nachrichten enthalten eine Kopie der ursprünglichen Nachricht. Wenn die ursprüngliche Nachricht vertrauliche Informationen enthält, entwerfen Sie die manuelle und automatische Verarbeitung von fehlerhaften Nachrichten so, dass die vertraulichen Informationen nicht versehentlich offen gelegt werden können.
Woraus besteht das Routing für fehlerhafte Nachrichten?
Wenn das Routing für fehlerhafte Nachrichten aktiviert ist, wird die Nachricht in BizTalk Server nicht angehalten, sondern stattdessen weitergeleitet. Das Routing für fehlerhafte Nachrichten kann sowohl auf Empfangs- als auch auf Sendeports mit dem folgenden Ergebnis aktiviert werden:
Wenn das Routing für fehlerhafte Nachrichten auf einem Empfangsport aktiviert ist und bei einer Nachricht in der Empfangspipeline oder beim Routing ein Fehler auftritt, wird eine Nachricht mit Fehlermeldungen generiert. Wenn ein Fehler in oder vor der Disassemblierungsphase auftritt, ist die Fehlernachricht ein Klon des ursprünglichen Austauschvorgangs.
Wenn das Routing für fehlerhafte Nachrichten auf einem Sendeport aktiviert ist und bei der Nachricht in der Sendepipeline ein Fehler auftritt, wird eine Nachricht mit Fehlermeldungen generiert.
Wenn eine Nachricht mit Fehlermeldungen generiert wird, stuft BizTalk Server vor dem Veröffentlichen dieser Nachricht die Nachrichtenkontexteigenschaften höher, die sich auf den Fehlerbericht beziehen, und normale Nachrichtenkontexteigenschaften herab. Vergleichen Sie dieses Verhalten mit dem Standardverhalten, wenn das Routing für fehlerhafte Nachrichten nicht aktiviert ist: Nachrichten, bei denen ein Fehler auftritt, werden angehalten.
Welche Arten von Messagingfehler lösen eine Fehlermeldung aus?
Jeder Fehler, der bei der Adapterverarbeitung, Pipelineverarbeitung, Zuordnung oder beim Routing von Nachrichten auftritt, führt dazu, dass eine Fehlermeldung generiert wird, wenn das Routing für fehlerhafte Nachrichten aktiviert ist. Wenn ein Messagingfehler auftritt, während eine Orchestrierung von einem Empfangsport empfängt oder an einen Sendeport sendet, wird die sich daraus ergebende Fehlermeldung den Messagingports zugewiesen, an die die Orchestrierung gebunden ist.
Abonnieren einer Fehlermeldung
Fehlermeldungen werden an Orchestrierungen oder Sendeports übermittelt, die diese Nachrichten abonniert haben. Ein Abonnement wählt in der Regel Fehlermeldungen anhand des Namens des Ports aus, bei dem der Messagingfehler aufgetreten ist (entweder beim Sende- oder beim Empfangsport). Abonnements können auch nach Eigenschaften filtern, die auf den Nachrichtenkontext des Fehlers höher gestuft wurden (z. B. InboundTransportLocation oder FailureCode).
Angaben zur Fehlermeldung
Eine Fehlermeldung ist ein Klon der ursprünglichen fehlerhaften Nachricht, wobei alle zuvor höher gestuften Eigenschaften herabgestuft und einige fehlerspezifische Eigenschaften auf den Nachrichtenkontext höher gestuft werden. Zuvor höher gestufte Eigenschaften werden herabgestuft, um eine unbeabsichtigte Übermittlung an Abonnenten zu vermeiden, die für den Empfang der Fehlermeldung nicht 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 heraufgestuft werden, fallen alle unter den ErrorReport-Namespace in BizTalk Server. Dies sind:
| Eigenschaftenname | Datentyp | Höher gestuft | BESCHREIBUNG |
|---|---|---|---|
| FailureCode | xs:string | Yes | Fehlercode Ein Hexadezimalwert, der in der BizTalk Server-Verwaltungskonsole angezeigt wird. |
| FailureCategory | xs:int | Yes | Diese Eigenschaft wird nicht verwendet. Ihr Wert ist nicht definiert. |
| BESCHREIBUNG | xs:string | No | Fehlerbeschreibung. Derselbe Diagnosetext, wie er zu diesem Messagingfehler in das Ereingisprotokoll der Anwendung geschrieben wird. |
| MessageType | xs:string | Yes | Nachrichtentyp der fehlerhaften Nachricht, oder leer, wenn der Nachrichtentyp unbestimmt ist. BizTalk Server ordnet mithilfe des Nachrichtentyps Nachrichten den jeweiligen XML-Schemas zu. Der Nachrichtentyp wird gebildet, indem der Schemanamespace mit dem Schemastammknoten verkettet wird: http://mynamespace#rootnode. Hinweis: Für Nachrichten, die fehlschlagen, bevor der Nachrichtentyp bestimmt wird, ist diese Eigenschaft nicht festgelegt. |
| ReceivePortName | xs:string | Höher gestuft , wenn der Fehler bei der Eingangsverarbeitung (in einem Empfangsport) aufgetreten ist. Nicht höher gestuft , wenn der Fehler in einem Sendeport aufgetreten ist. |
Der Name des Empfangsports, bei dem der Fehler aufgetreten ist. |
| InboundTransportLocation | xs:string | Höher gestuft , wenn der Fehler bei der Eingangsverarbeitung (in einem Empfangsport) aufgetreten ist. Nicht höher gestuft , wenn der Fehler in einem Sendeport aufgetreten ist. |
URI des Empfangsspeicherorts, bei dem der Fehler aufgetreten ist. |
| SendPortName | xs:string | Höher gestuft , wenn der Fehler bei der Ausgangsverarbeitung (in einem Sendeport) aufgetreten ist. Nicht höher gestuft , wenn der Fehler in einem Empfangsport aufgetreten ist. |
Der Name des Sendeports, bei dem der Fehler aufgetreten ist. |
| OutboundTransportLocation | xs:string | Höher gestuft , wenn der Fehler bei der Ausgangsverarbeitung (in einem Sendeport) aufgetreten ist. Nicht höher gestuft , wenn der Fehler in einem Empfangsport aufgetreten ist. |
URI des Sendespeicherorts, bei dem der Fehler aufgetreten ist. |
| ErrorType | xs:string | Yes | Gibt den Typ der im Fehler enthaltenen Nachricht an. Diese Eigenschaft enthält immer den Wert FailedMessage. Dies bedeutet, dass der Fehler die ursprüngliche Fehlermeldung enthält. |
| RoutingFailureReportID | xs:string | Yes | Diese Eigenschaft enthält die ID des Routingfehlerberichts, der von BizTalk Server generiert wird, wenn ein Routingfehler auftritt. Ein Routingfehlerbericht ist eine spezielle Nachricht, die von BizTalk Server generiert und angehalten wird. Diese Nachricht enthält zwar keinen Nachrichtentext, dafür jedoch den Kontext der fehlerhaften Nachricht. Mithilfe dieser ID kann eine Fehlerbehandlungsorchestrierung oder ein Sendeport die MessageBox-Datenbank abfragen und den Routingfehlerbericht verarbeiten. So kann beispielsweise eine Orchestrierung den Routingfehlerbericht nach dem Empfang der fehlerhaften Nachricht beenden. |
| FailureTime | xs:dateTime | Datumszeit des Fehlerereignisses | |
| FailureMessageID | xs:string | ||
| FailureInstanceID | xs:string | ||
| FailureAdapter | xs:string |
Verarbeitung von Fehlermeldungen
Die Fehlerverarbeitung wird durch ein Orchestrierungs- oder Sendeportabonnement angegeben, dessen Filter mit den Eigenschaften übereinstimmt, die in den Nachrichtenkontext der Fehlermeldung höher gestuft wurden.
Sicherheitsrisiken
Die der ursprünglichen Nachricht zugeordnete Identität (die durch die Parteiauflösungsstufe der Empfangspipeline entweder zu Beginn oder am Ende festgelegte Identität) wird der Fehlermeldung zugeordnet.
Die Sicherheitsmechanismen, mit denen die Übermittlung von Nachrichten auf berechtigte abonnierende Ports und Orchestrierungen eingeschränkt wird, gelten auch für Fehlermeldungen.
Ein Sendeport, der eine Fehlermeldung abonniert, jedoch nicht mit einem geeigneten Entschlüsselungszertifikat konfiguriert ist, empfängt keine Fehlermeldungen, die sich aus Messagingfehlern während oder vor der Entschlüsselungsstufe der Empfangspipeline ergeben, über die die ursprüngliche Nachricht BizTalk Server erreicht hat. Die Fehlermeldungen werden stattdessen in die Warteschlange "Angehalten" eingefügt.
Messagingfehler beim Adapter
Wenn ein Adapter eine Nachricht anhält, wird eine Fehlermeldung veröffentlicht. Wenn die Nachricht nicht angehalten wird, wird keine Fehlermeldung generiert.
Transaktionale Empfangspipelines
Wenn eine transaktionale Empfangspipeline eine Ausnahme auslöst (d. h. angibt, dass die Transaktion abgebrochen werden soll), wird die Transaktion abgebrochen und eine Fehlermeldung veröffentlicht.
Wenn eine transaktionale Empfangspipeline eine Nachricht explizit anhält (d. h. mit "MessageDestination = SuspendQueue" angibt, dass das Ziel der Nachricht die Warteschlange "Angehalten" ist), wird die aktuelle Transaktion fortgesetzt (und darf festgeschrieben werden, sofern nachfolgende Stufen nicht festlegen, dass sie abgebrochen wird), und die sich daraus ergebende Fehlermeldung wird veröffentlicht.
Sendeports 'Antwort anfragen'
Wenn eine Anforderungsnachricht von einer Orchestrierung gesendet wird und bei der Übertragung oder bei der Eingangsverarbeitung der Antwort ein Fehler auftritt, empfängt die Orchestrierung eine Ausnahme. Dabei spielt es keine Rolle, ob die fehlerhafte Nachricht weitergeleitet wurde.
Wenn ein Sendeport vom Typ "Antwort anfragen" mit einem Empfangsport vom Typ "Anforderungsantwort" verbunden ist, empfängt der Empfangsport entweder eine Antwortnachricht (wenn die Übertragung erfolgreich ist) oder eine negative Bestätigung (wenn bei der Übertragung ein Fehler auftritt). Dabei spielt es keine Rolle, ob die fehlerhafte Nachricht weitergeleitet wurde.
Unidirektionale Sendeports
Wenn eine Nachricht von einer Orchestrierung über einen Sendeport gesendet wird, der für die Übermittlungsbenachrichtigung konfiguriert ist, empfängt die Orchestrierung eine Übermittlungsbenachrichtigung. Dabei spielt es keine Rolle, ob die Fehlermeldung weitergeleitet wurde. Der Sendeport generiert also eine Übermittlungsbenachrichtigung für die Orchestrierung, auch wenn der Port bei der Verarbeitung einen Messagingfehler feststellt. Die Benachrichtigung bestätigt die Übermittlung an den Port, die erfolgreiche Verarbeitung über den Port jedoch nicht.
Fortsetzen von angehaltenen Nachrichten
Bei den meisten Nachrichten, bei denen bei der Eingangverarbeitung ein Fehler auftritt (d. h. Verarbeitung ab dem Empfangsadapter (einschließlich) bis zur Veröffentlichung in der MessageBox-Datenbank (ausschließlich)), und deren Fehler nicht behandelt werden, werden als fortsetzbar angehalten. Die Ausnahme besteht darin, dass Anforderungsnachrichten von bidirektionalen Empfangsports als nicht fortsetzbar angehalten werden.
Nachrichten werden, von zwei Ausnahmen abgesehen, in der ursprünglichen Form (in der sie vor der Pipelineverarbeitung waren) angehalten:
Nachrichten, die von Pipelinekomponenten angehalten werden. BizTalk Server hält diese Art von Nachrichten in derselben Form an, in der diese der Pipelinekomponente bereitgestellt wurden, in der der Fehler aufgetreten ist. Wenn die Nachricht wieder aufgenommen wird, wird sie in derselben Pipeline von Anfang an verarbeitet. Das bedeutet, dass eine Pipelinekomponente in einer Pipelinestufe vor der Stufe, in der der ursprüngliche Fehler aufgetreten ist, "dieselbe" Nachricht in einer Form verarbeiten können muss, die sich von der ursprünglichen Form unterscheidet, in der sie diese Nachricht verarbeitet hat.
Nachrichten aus der Disassemblierung für den wiederherstellbaren Austausch, bei deren nachfolgendem Routing ein Fehler auftritt. BizTalk Server hält diese Art von Nachrichten in derselben Form an, in der sie veröffentlicht wurden. Dies ist die Form, die die Nachricht nach der Ausführung der Pipeline hatte. Wenn die Nachricht fortgesetzt wird, überspringt sie die Pipelineverarbeitung und wird direkt in der MessageBox-Datenbank veröffentlicht.
Szenarien, die zu angehaltenen (nicht fortsetzbaren) Nachrichten führen
Die meisten Nachrichten, die angehalten wurden, können wieder aufgenommen werden. Es gibt jedoch Szenarien, die zu nicht fortsetzbaren Nachrichten führen:
In einem Sendeport, für den die Eigenschaft "Geordnete Übermittlung" und die Funktion zum Fortfahren beim Auftreten eines Fehlers aktiviert wurde, wenn ein Fehler in der Pipeline, Zuordnung oder bei der Übertragung auftritt.
In einem Empfangsport mit aktivierter Eigenschaft "Geordnete Übermittlung", wenn der Adapter so konfiguriert ist, dass Nachrichten bei Auftreten eines Fehlers als nicht fortsetzbar angehalten werden. Wenn z. B. für die MSMQ-Adaptereinstellung "Bei Fehler" die Option "Anhalten (nicht fortsetzbar)" festgelegt oder für den MQSeries-Adapter die Einstellung "Als nicht fortsetzbar anhalten" aktiviert wurde, werden fehlgeschlagene Nachrichten als nicht fortsetzbar angehalten.
In einem bidirektionalen Empfangsport, wenn bei der Antwortnachricht in der Pipeline, Zuordnung oder bei der Übertragung ein Fehler auftritt.
In einem bidirektionalen Empfangsport, wenn bei der empfangenen Nachricht in der Pipeline, Zuordnung oder bei der Übertragung ein Fehler auftritt. Einzelne Adapter können sich unterschiedlich verhalten. Der HTTP-Adapter hält zum Beispiel standardmäßig keine Nachrichten an, kann jedoch entsprechend konfiguriert werden.
Weitere Informationen
Fehlerbehandlung
Verwenden von Bestätigungen
Geordnete Übermittlung von Nachrichten