Resumable and Non-resumable message

When any message is suspended in processing then it’s log into the suspended instance in BizTalk admin console. Sometimes we can directly resume message from admin console and it’s processed successfully and some time it doesn’t.

In BizTalk, when message is suspended, then it’s fall into one of these two categories.

  1. Resumable
  2. Non-Resumable

Suspended_Message.jpg

Resumable:

The service instance is suspended. Admin may be able to resume the service instance from admin console just right click on suspended instance and resume. Messages which can be manually resumed.

Reason:

  • If the external resource (example webservice, folder location in case of file adapter) is not available then the message will go for suspend resumable mode.
  • Resumable means the service may be able to be recovered.

Resuming a messaging instance will do the following:

  • Resume the messaging instance.
  • Send the message to the send port.
  • The send port delivers the message to the destination; even if the send port is not in a Started state.

    Note that when you suspend a scheduled instance and then resume it, the instance goes into a dehydrated state.

Non-resumable:

In Non-resumable, service instance associated with the message is suspended, and cannot be resumed.

Messages, which typically hold metadata and cannot be resumed. They will either disappear when the corresponding resumable instance is resumed, or in other cases they might need manual termination. You can save the Messages referenced by the instance, and then you can terminate the instance.
Non resumable instances are not necessarily zombies. They might be, but they could also be:

  • Instances for debugging purposes (typically after a “no subscribers found” error)
  • Instances failed at receive time when using an Isolated Host.
  • It will go after number of retry that you have set in the sendport.  The message will go for Suspend non-resumable mode if the message is not proper format (or) if it is rejected by the target system.
  • The response waits timed out.
  • In an Ordered Delivery send port with continue on failure enabled, if there is a failure in the pipeline, mapping or transmission.
  • In an Ordered Delivery receive port, if the adapter is configured to suspend messages on non-resumable on failure.
  • In a two-way receive port, if the response message fails in the pipeline, mapping, or transmission.
  • In a two-way receive port, if the receive message fails in the pipeline, mapping or transmission. Individual adapter behavior may be different. For example, the HTTP adapter does not suspend messages by default but can be configured to do so.
  • And yes…Zombies.
Advertisements