Use BizTalk to handle exceptions in the Exchange Process

Use BizTalk to handle exceptions in the Exchange Process

Abstract:

With the new error handling feature in BizTalk Server 2006, the designer can specify automatic processing for message transmission failures as the traditional method of placing failure messages in the suspended Queue (which is the default currently) behavior replacement selection. This automatic processing method routes error messages to any subscription route destination (such as the sending port or business flow ). An error message is a clone of the original message. All previously upgraded attributes are downgraded, and selected attributes related to failed message transmission are upgraded to the Message context.

Problem description:
Data exchange between the source and target ends. After a batch of data enters BizTalk, the data is split and mapped one by one, and then switched to the target database. Exception Handling is not used in the process.
Fields corresponding to the source end are longer than those corresponding to the target end, but there are not many records that are actually larger than the target end. These records cause the process to be suspended, all data after this data is not exchanged.

 

Previous solutions:
After the length of the field corresponding to the target database is updated, all unexchanged data is exchanged again. This method is rigid and inefficient.

 

Handle errors:
When an exception is thrown to the target database and returned, this operation is added with Exception Processing to capture exceptions. The messages that trigger the exception are not exchanged, and the data after the message continues to be exchanged.
Find the cause of the error, change the field length of the target database, and re-exchange messages that are not switched to the target.

 

Exception Handling adds this error message to the system log:

 

Handle messages that trigger exceptions:

The message is not processed or routed to the specified location.
Message not processed:
The message is suspended (recoverable). If the process is not completed, the target database can be restored and exchanged to the target database. If the process has been completed, only one message is left, the Recovery fails even if the target database is changed.
Route to the specified location:
After an error occurs, the message is directly sent to the specified location by the route sending port, which is usually an XML file in the folder. when you reexchange the message, you can obtain the information of the unexchanged records from these files.

 

Select "enable routing for failed messages" for the port sent to the target during routing ":

 

 

 

Filter the sending port that routes the error message to ensure that only the exception messages generated by this port are routed:

 

 

 

 

 

 

 

Reference:

 

<Sending port exception and handling in BizTalk (below)> chnking

 

Bts06_cn.chm biztalk2006 help document Chinese version:

With the new error handling feature in BizTalk Server 2006, the designer can specify automatic processing for message transmission failures as the traditional method of placing failure messages in the suspended Queue (which is the default currently) behavior replacement selection. This automatic processing method routes error messages to any subscription route destination (such as the sending port or business flow ). An error message is a clone of the original message. All previously upgraded attributes are downgraded, and selected attributes related to failed message transmission are upgraded to the Message context.

Warning
The failed message contains a copy of the original message. If the original message contains sensitive information, manual and automatic message processing should be designed to avoid accidental leakage of this information.

 

What are the components of the failed message routing?

After the failed message routing is enabled, the BizTalk Server will not suspend the message, but route the message. You can enable the failed message routing on both the receiving and sending ports. The result is as follows:

• If you enable the failed message routing on the receiving port and the message fails in the receiving pipeline or route, a failed message is generated. If an error occurs during or before the disassembly stage, the error message is a clone of the original switch.

• If you enable the failed message routing on the sending port and the message fails in the sending pipeline, a failed message is generated.

When a failed message is generated, BizTalk Server upgrades the message context attribute related to the error report before publishing the failed message and degrades the general message context attribute. Compare this behavior with the default behavior when no failed message routing is Enabled: The failed message will be suspended.

What types of messages will trigger error messages if they fail?

If you have enabled a route for a failed message, any failure that occurs during adapter processing, pipeline processing, ing, or message routing will cause an error message. If a message transmission error occurs when a business process is received from the receiving port or sent to the sending port, the generated error message is associated with the Message Port bound to the business process.

Subscribe to error messages

The error message is sent to the business process or sending port that has subscribed to receive them. Generally, the subscription selects an error message based on the name of the port (sending port or receiving port) with an error message. Subscription may also filter other attributes (such as inboundtransportlocation or failurecode) of the upgraded message context.

Error Message Specification

An error message is a clone of the original failure message. All attributes previously upgraded will be downgraded, and a group of attributes specific to the error will be upgraded to the Message context. Previously, attribute downgrade was performed to prevent unintentional transmission to subscribers who did not specify to receive error messages. Publish error messages to the subscribers (business processes, sending ports, and sending port groups ).

All attributes updated to the error message context are in the errorreport namespace. These attributes include:

Attribute name	Data Type	Upgraded	Description
Failurecode	System. String	Yes	ErrorCode. Hexadecimal value, which is reported on the BizTalk Server console.
Failurecategory	System. int32	Yes	This attribute is not used in BizTalk Server 2006. The value is undefined.
Description	System. String	No	Error description. And write applicationsProgramThe same diagnostic text in the event log provides information about the message transfer failure.
Messagetype	System. String	Yes	The type of the failed message. It is null if the message type is not clear. Biztalk Server uses the message type to associate a message with its XML architecture. The message type is formed by connecting the schema namespace and the schema root node: http: // mynamespace # rootnode. Note: This attribute is not set for messages that fail before determining the message type.
Receiveportname	System. String	If the failure occurs during the inbound processing (in the receiving end), it is "upgraded ". If the failure occurs on the sending port, it is "not upgraded ".	The name of the receiving port that fails.
Inboundtransportlocation	System. String	If the failure occurs during the inbound processing (in the receiving end), it is "upgraded ". If the failure occurs on the sending port, it is "not upgraded ".	The URI of the failed receiving location.
Sendportname	System. String	If the failure occurs during the outbound processing (in the sending port), it is "upgraded ". If the failure occurs in the receiving end, it is "not upgraded ".	The name of the sending port that fails.
Outboundtransportlocation	System. String	If the failure occurs during the outbound processing (in the sending port), it is "upgraded ". If the failure occurs in the receiving end, it is "not upgraded ".	The URI of the failed sending location.
Errortype	System. String	Yes	Indicates the type of the message contained in the error. In BizTalk Server 2006, this attribute always contains the value failedmessage, indicating that the error contains the original failure message.
Routingfailurereportid	System. String	Yes	If a route fault exists, this attribute provides the ID of the routing fault report generated by BizTalk Server. A routing fault report is a special message generated and suspended by the BizTalk Server. The message has no body, but has the context of the failed message. With this ID, you can query the MessageBox database and handle routing fault reports by error handling business processes or sending ports. For example, a business process may terminate a route fault report after obtaining the failure message.

Handle error messages

Error handling is specified by the business flow or sending port subscription whose filter matches the attributes of the message context that has been upgraded to the error message.

Security description

The identifier associated with the original message (its initial identifier or its final identifier, determined by the resolution participant stage of the receiving pipeline) is assigned to the error message.

The security mechanism that limits messages to be transmitted only to authorized subscription ports and business processes is also applied to error messages.

For the sending port that subscribes to the error message but does not use the appropriate decryption certificate for configuration, it will not receive the message in the receiving pipeline (the original message enters the BizTalk Server through it) error messages generated during the decryption phase or before based on message transmission failure. Failure messages are placed in the suspended queue.

An error occurred while transmitting the adapter message.

If the adapter suspends a message, an error message is published. If the message is not suspended, no error message is generated.

Transaction receiving Pipeline

If an exception occurs in the transaction receiving pipeline (the specified transaction should be aborted), the transaction is aborted and an error message is published.

If the transaction receiving pipeline explicitly suspends a message (specify messagedestination = suspendqueue), the current transaction is allowed to continue (and may be committed unless it is terminated by a later stage ), and publish the generated error message.

Request Response sending Port

If a request message is sent from a business process, but the request message fails to be transmitted or its response fails to be processed on the inbound site, the business process will get an exception regardless of whether the message fails to be routed or not.

When you connect the request sending port to the request receiving port, the receiving port will receive a response message (if the transmission is successful) no matter whether the message fails to be routed or not) or Nack (if the transmission fails ).

One-way transmission Port

If a message is sent from the service flow by configuring the sending port of the delivery notification, the service flow will receive the delivery notification no matter whether or not the error message has been routed. In other words, even if the port fails to send messages during processing, the sending port generates a delivery notification for the business process. The notification confirms the delivery to the port, but does not ensure that the process is successful through the port.

Resume pending messages

Most of the messages that fail to be processed by the inbound (that is, from the receiving adapter (including) to the MessageBox (not included) and fail to be processed will be suspended as recoverable messages. The exception is that the request message from the two-way receiving port is suspended as an unrecoverable message.

Messages are usually suspended in their original form (in the form before pipeline processing), except for the following two messages:

• Messages suspended by MPs queue components. Biztalk Server suspends such messages in the same format when providing them to the failed MPs Queue component. When a message is restored, pipeline processing is performed from the beginning of the same pipeline. This means that for pipeline components in the pipeline phase prior to the phase in which the original failure occurred, they must be prepared in a different form (in the form of processing the message) to process "same" messages.

• Messages from recoverable exchange, disassembly, and subsequent route failures. The BizTalk Server suspends such messages in the same form as when a message is published. This is the form of a message after the pipeline is executed. After the message is restored, the MPs queue is skipped and directly published to the MessageBox database.

Message suspension (unrecoverable)

Generally, a suspended message is recoverable, but in some cases, it may also lead to unrecoverable messages:

• In the "delivery in order" sending port that is allowed to continue after a fault occurs, if the pipeline, ing, or transmission fails.

• In the "delivery in order" receiving end, if the adapter is configured to suspend messages in an unrecoverable manner when a fault occurs. For example, if the "when the MSMQ adapter fails" is set to "suspended (unrecoverable)" or the MQSeries adapter enables "suspended and unrecoverable ", A failed message is suspended as an unrecoverable message.
• In the two-way receiving end, if the response message in the pipeline, ing, or transmission fails.
• In the two-way receiving end, if a message fails to be received in the pipeline, ing, or transmission. Different adapters may have different behaviors. For example, the HTTP adapter does not suspend messages by default, but can be configured to suspend messages.