Question

I have a BizTalk 2006 app which has a sendport using MSMQ.

I have also a WCF winforms hosting app with several WCF services (in the development environment, in production I use a windows service as hosting).

One of the WCF services that I created has a MSMQIntegrationBinding (due to the fact that BizTalk is not a WCF service, so NetMSMQBinding is not possible).

I see that the message is correctly placed on the remote queue because I activated the journal option and I see the message in the journal queue, but the queue is empty and the WCF service is not picking up the message.

Can anybody give me a clue where to look at to solve this problem ?

(edit 1): I have done some more research on this topic:

  • When communicating with BizTalk 2006 R2 with MSMQ you have to use MSMQIntegrationBinding because NetMSMQBinding is only for WCF-to-WCF
  • So I am stucked to MSMQIntegrationBinding
  • the MSMQIntegration binding doesn't use DataContract serializer. Instead, it serializes the data based on the MsmqMessageSerializationFormat property. The default value for it is MsmqMessageSerializationFormat.Xml which means that XmlSerializer will be used. The rationale behind this is that the msmq integration transport is designed specifically to interop with native MSMQ / System.Messaging applications
  • Because the MSMQIntegration binding uses the plain old XmlSerializer, I do not have the easy ability to use the svcutil.exe to generate my data classes. So I have to create my datacontract classes by hand....pfffffffffff

(reference: http://social.msdn.microsoft.com/Forums/en/wcf/thread/2d48fe90-5c2a-4156-8a3f-2e21d5638fa1 and http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vs-datacontractserializer-serialization-in-wcf/)

(edit 2):

I checked the diagnostic trace data from the WCF service and the message was dropped due to a deserializing exception. The only solution now is to create the datacontract class by hand...

(edit 3): by using the xsd.exe tool instead of the svcutil.exe I created the datacontract class, so no handcrafted work here ;-) So the conclusion is to use xsd.exe for data contract classes that are used as parameter in the WCF service method. This is because MSMQIntegrationBinding forces you to make all datacontract types as being serializable with the XMLSerializer instead of the default DataContractSerializer.

Was it helpful?

Solution

You may want to try enabling WCF Tracing.

It may help you understanding what is happening, and what is not happening.

The following is an .config example to enable tracing. Make sure the .config file is located in the same folder of your WCF service host.

<configuration>
  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Warning" 
              propagateActivity="true" >
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>

      <source name="myUserTraceSource" switchValue="Warning, ActivityTracing">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
    </sources>

    <sharedListeners>
      <add name="xml" 
           type="System.Diagnostics.XmlWriterTraceListener" 
           initializeData="C:\trace_logs\TraceLog.svclog" />
    </sharedListeners>

  </system.diagnostics>
</configuration>

Microsoft provides a Service Trace Viewer Tool to read .svclog files.

Make sure the path in initializeData is writable by your service.

OTHER TIPS

The first thing to check here is the rights of the WCF service. Is the connection to the message queue being done by an account that is allowed to connect to the message queue.

It may also be due to a configuration error, is your connection configuration correct?

Check the event log, there may be an error there, that will point you in the right directions.

Have you verified if the message is indeed left in the queue by the WCF service, or is it being picked up and deleted and just not processed by WCF?

Something I'd try is attaching a handler to the UnknownMessageReceived event in the ServiceHost instance and see if it's being triggered when the message is being picked up... that would be a sure sign your service contract is incorrectly defined (it might be you need to use a catch all:

[OperationContract(Action="*")]

To ensure it gets correctly routed to your method.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top