Biztalk Web服务端口以及端口/应用程序停止时会发生什么

Question

I have a question around biztalk and what happens when certain conditions around web service ports are met.

basically we have two applications - a main application (lets call it 'MainApplication') (containing the orchestration) and a web service application (lets call it 'MainApplicationWS'), where we expose a web service (created from biztalks web service tool) to take messages from wherever.

we have a testing tool which replays messages to the MainApplicationWS to simulate messages coming through from various external systems.

I have noticed that if we partial stop the MainApplicationWS application, and send messages through to the web service listed as a recieve location, nothing happens (obviously!) (also, the web service is still running, even though its been delisted as a recieve location). however, if i start up the MainApplicationWS again and bounce the host instances the messages are picked up from somewhere and played through to the orchestration and through to our application.

Im just a bit puzzled as to where its storing these messages while the MainApplicationWS is partially stopped. is the web service somehow hanging on to these? or does it still post through to the biztalk message box?

any clarification would be greatly appreciated :)

cheers, adam

Answer 1

In short, I can't repeat your behaviour in Biztalk 2009. The closest to 'queueing' messages is if the orchestration is stopped but remains enlisted, such that messages are suspended resumable.

In long - I'm not quite sure what you mean by 'delisted as a receive location'. In Biztalk 2009:

• Receive Locations can be enabled or disabled
• Orchestrations can be stopped, and unenlisted
• A Partial Stop on your BTS application disables receive ports and stops orchestrations (but doesn't unenlist them)
• A full stop stops and unenlists orchestrations

The below is observed behaviour on BizTalk 2009 for a simple orchestration with a WCF Request/Response port, which receives a message, Maps the Send back to the same Port The port is Direct Bound (MessageBox).

If the Isolated Host App Pool is disabled in IIS

A synchronous error is returned to the client - Standard IIS Error (503 Service Unavailable etc) BizTalk receives no messages at all

If the BizTalk receive Location is disabled

• WSDL: Syncrhonous error returned to the client - The Messaging Engine failed to register the adapter for "WCF-BasicHttp" for the receive location "xyz.svc". Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases
• Service Call : The requested service, xyz.svc could not be activated. See the server's diagnostic trace logs for more information.

If the Orchestration is stopped, but not unenlisted

The received message is Suspended, resumable. The client times out (no response is issued). If the orch is started and the message resumed, the message is then processed. The client will only get a successful reply if the orch start and the suspended message resume are done before the client's configured WS / WCF timeout.

If the Orchestration is unenlisted

The received message is Suspended, not resumable. The client receives an error - The server was unable to process the request due to an internal error.

With the WCF CustomBinding it is also possible to listen directly on the relevant BizTalk ReceiveHost (ie no need for IIS at all to listen to BasicHTTP or WSHTTP, although we generally still use the Wizard generated svc in IIS solely for the hosting and publication of the WSDL. We then create a new WCF Custom receive location directly in BizTalk and point the client to this)

Hope this helps?