none
Poison message is retrieved from queue by WCF-MSMQ without showing errors RRS feed

  • Question

  • Hi,

    in BizTalk I have a custom WCF adapter (net.msmq). I configure this adapter by importing a config file from a WCF service (console application). The messages are secured using certificates.

    When I send a message from the client to the server and the messages is secured using certificates everything works fine. When the client doen't contain a certificate I would expect that the message stays on the queue or BizTalk shows an error.

    When I disable the WCF adapater and start the WCF service, the messages stays on the server queue and WCF logging shows the following error:
    Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties.   This can occur if the service is configured for security and the client is not using security. 
    This is fine and what I expect.

    When I close the service and enable the BizTalk adapater the messages is retrieved from the queue, WCF logging shows the same error but BizTalk doesn't. Because the messages is gone from the queue and BizTalk doesn't show an error, it looks like the messages has been dissapeared. Only WCF logging shows an error. Why does BizTalk pick the message from the queue and doesn't leave the message on the queue, just like the WCF service?

    Any ideas?
    Thanks,
    René
    rt
    Tuesday, July 14, 2009 12:46 PM

All replies

  • It sounds like the message is not getting into BizTalk from the poison queue and is causing an error on the WCF level.

    I was a little confused by your title. Are you saying that you are having this behavior when trying to have BizTalk retrieve from the poison queue? If so, it sounds like the WCF service is reading from the poison queue but BizTalk is not. BizTalk is probably only reading from the target queue rather than the poison one. I am not sure if it is possible to have BizTalk pull from the poison queue.

    Thanks,
    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Tuesday, July 14, 2009 4:30 PM
    Moderator
  • Thanks for you response,

    Yes, it's causing an error on the WCF error level. That's what the WCF error log says also. The strange thing is that when I run a WCF service on the same server (console application, I disable the BizTalk receive location) I see the same error in WCF logging but the message stays on the queue.

    When I stop the console app and enable BizTalk I see the WCF error (when I enable WCF logging of course) but the message is gone.

    I don't have a poison queue. I did only set up one queue to which a client sends messages. So to answer your question: no, BizTalk doesn't try to retrieve a message from the poison queue, it use the 'normal' queue.

    I think it's better when the message stays on the queue when it can't be processed. It's also fine when it is placed in the dead letter queue. It's also ok when BizTalk would log an error. But I don't like it that the message is gone and that I have to check the WCF logging.

    Any ideas why WCF behaves differently when hosted by BizTalk?

    Thanks,
    René
    rt
    Monday, July 20, 2009 8:59 AM
  • I understand your problem better now. You would like for BizTalk to not pull the message. With BizTalk probably the default behavior is an assumption it can be processed. This is a case where the default behavior in WCF is the opposite of BizTalk.

    With WCF, you have to explicitly specify a catch-all Action such as Action="*" in the OperationContract attribute in order to receive any message (known as POX).

    Sorry, I am not aware of a good workaround other than coding WCF to resubmit the message to a queue for correcting the message so that the message is able to outlive the BizTalk receive.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Monday, July 20, 2009 4:03 PM
    Moderator
  • Thanks for your response again.

    I think it's strange that the WCF adapter behaves different from a nomal WCF service.

    You say:
    With BizTalk probably the default behavior is an assumption it can be processed.

    But I think it isn't BizTalk who gets the message from the queue, it's WCF. The WCF error log shows that WCF adapter fails in doing this so you would expect that the BizTalk WCF adapter leaves the message on the queue (just as it does when using the WCF framework). Why does it pick it from the queue? Is the code of the WCF adapter different from the WCF framework?

    Also, what you say about the contract, that's what I first thought also but the error is not about the message it self. It's about security. WCF first checks security and this results in an error.

    I don't know how to do the following: 
    coding WCF to resubmit the message to a queue for correcting the message so that the message is able to outlive the BizTalk receive.

    What do you mean with WCF in this context, the WCF adapter?

    Thanks.


    rt
    Tuesday, July 21, 2009 8:39 AM