WCF receive adapters can be divided into 2 groups, isolated and in-process WCF receive adapters. The difference is that in-process WCF receive adapters are hosted by BizTalk, while isolated WCF receive adapters are hosted by IIS.
The following WCF receive adapters are hosted in IIS:
- WCF-BasicHTTP
- WCF-CustomIsolated
- WCF-WSHttp
When using separate host instances for sending, receiving, processing, and tracking (a best practice as described by Microsoft in this article: http://msdn.microsoft.com/en-us/library/ee377083.aspx) it would be an easy mistake to assume that stopping the receiving host instance will prevent new messages from entering the MessageBox. However, even though the host instance for receiving messages has been stopped, the IIS service might still be running and isolated WCF receive locations will still accept new messages and place these in the MessageBox.
When the host instance of an in-process WCF receive location is stopped, any corresponding WCF receive locations are no longer available and will not accept any new messages. However, since the isolated WCF receive locations are hosted in IIS we need to make sure that the IIS service is not running to guarantee that no new messages will enter the MessageBox.
To show this behavior I have created a very simple BizTalk application where an orchestration receives a message through a web service and writes a line to the trace output. There are two receive ports: one uses a WCF-CustomIsolated receive location while the other uses a WCF-Custom receive location. Outside of the adapter type and the URL, the configuration of the receive locations is identical.
When the BizTalk application, the host instances and the IIS service are running, it is possible to browse both URL’s and send messages to both endpoints. This will result in 2 messages in the trace output.
As shown, both the message from the isolated WCF receive location and the in-process WCF receive location are received and processed.
When we stop all the BizTalk host instances the in-process WCF receive location is no longer available and cannot accept new messages.
While the isolated WCF receive location is still available and can accept new messages which are published to the MessageBox. These messages are not processed because all the in-process host instances have been stopped.
As shown, the message has the status ‘Ready to run’, when the in-process host instances are started the message will be processed.
The BizTalk application in my example uses an asynchronous web service, which means that while the messages might ‘unexpectedly’ be published to the MessageBox, the application calling the web service does not receive an error. As soon as the in-process host instances are started, the messages that are queued in the MessageBox will be processed. If the BizTalk in-process host instances aren’t down for too long and the interface is asynchronous, this sequence of events does not necessarily have to be an issue.
When using a synchronous web service, this however does become an issue. The calling application is able to send a message to BizTalk (remember, the host instances are all stopped, IIS is running and we are using an isolated WCF receive pipeline). However, because the host instances are not running the calling application will not receive an answer and a time-out error will occur. While the message might even be processed correctly when the in-process host instances are started, the calling application will be unaware of this and might even retry sending the message. This is a situation you really want to prevent.
To summarize: in the event that you want to prevent any new messages entering the MessageBox and if any of the BizTalk applications use isolated WCF receive locations, always remember to stop both the in-process hosts and the IIS service.
Subscribe to our RSS feed