WCF mit msmqintegrationBinding nimmt keine Nachricht von der Warteschlange auf

Question

Ich habe eine BizTalk 2006 -App mit einem Sendport mit MSMQ.

Ich habe auch eine WCF -WinForms -Hosting -App mit mehreren WCF -Diensten (in der Entwicklungsumgebung, in der Produktion, in der ich einen Windows -Dienst als Hosting verwende).

Einer der von mir erstellten WCF -Dienste hat eine MSMQIntegrationBinding (da BizTalk kein WCF -Dienst ist, daher ist NetMSMQBinding nicht möglich).

Ich sehe, dass die Nachricht in der Remote -Warteschlange korrekt platziert ist, da ich die Journaloption aktiviert habe und die Nachricht in der Zeitschrift -Warteschlange sehe, aber die Warteschlange ist leer und der WCF -Dienst nimmt die Nachricht nicht auf.

Kann mir jemand eine Ahnung geben, wo ich mich ansehen soll, um dieses Problem zu lösen?

(Bearbeiten 1): Ich habe weitere Nachforschungen zu diesem Thema durchgeführt:

• Wenn Sie mit BizTalk 2006 R2 mit MSMQ kommunizieren
• Also bin ich bei MSMQintegrationbinding festgehalten
• Die MSMQintegrationsbindung verwendet nicht DataContract Serializer. Stattdessen serialisiert es die Daten basierend auf der Eigenschaft von MSMQMessageSerializationFormat. Der Standardwert dafür ist msmqMessageSerializationFormat.xml, was bedeutet, dass XMLSerializer verwendet wird. Die Begründung dahinter ist, dass der MSMQ -Integrationstransport speziell mit nativem MSMQ / System interop entwickelt wurde. Messaging -Anwendungen
• Da die MSMQintegration -Bindung den einfachen alten XMLSerializer verwendet, kann ich nicht die einfache Möglichkeit haben, die svcutil.exe zu verwenden, um meine Datenklassen zu generieren. Also muss ich meine DataContract -Klassen von Hand erstellen .... Pffffffffffffff

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

(Bearbeiten 2):

Ich habe die diagnostischen Trace -Daten aus dem WCF -Dienst überprüft und die Nachricht wurde aufgrund einer Deserialisierungsausnahme fallen gelassen. Die einzige Lösung besteht nun darin, die DataContract -Klasse von Hand zu erstellen ...

(Bearbeiten 3): Durch die Verwendung des XSD.exe-Tools anstelle des svcutil.exe habe ich die DataContract-Klasse erstellt. Daher keine handgefertigten Arbeiten hier; in der WCF -Servicemethode. Dies liegt daran, dass MSMQIntegrationBinding Sie dazu zwingt, alle DataContract -Typen als serialisierbar mit dem XMLSerializer anstelle des Standard -DataContractSerializers zu gestalten.

Answer 1

Möglicherweise möchten Sie versuchen, die WCF -Verfolgung zu aktivieren.

Es kann Ihnen helfen, zu verstehen, was passiert und was nicht.

Das Folgende ist ein .config Beispiel, um die Verfolgung zu ermöglichen. Stellen Sie sicher, dass .config Die Datei befindet sich im selben Ordner Ihres WCF -Service -Hosts.

<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 bietet a Service Trace Viewer Tool zum Lesen von .svclog -Dateien.

Stellen Sie sicher, dass der Weg in initializeData ist nach Ihrem Service beschreibbar.

Answer 2

Das erste, was Sie hier überprüfen sollten, sind die Rechte des WCF -Dienstes. Ist die Verbindung zur Nachrichtenwarteschlange durch ein Konto, das eine Verbindung zur Nachrichtenwarteschlange herstellen darf?

Möglicherweise ist dies auch auf einen Konfigurationsfehler zurückzuführen. Ist Ihre Verbindungskonfiguration korrekt?

Überprüfen Sie das Ereignisprotokoll, es kann dort einen Fehler geben, der Sie in die richtigen Richtungen zeigt.

Answer 3

Haben Sie überprüft, ob die Nachricht tatsächlich vom WCF -Dienst in der Warteschlange gelassen wird oder wird sie abgeholt und gelöscht und einfach nicht von WCF verarbeitet?

Etwas, den ich versuchen würde, findet einen Handler an der UnbekannteMessagerecebed Ereignis in der ServiceHost -Instanz und prüfen Sie, ob es ausgelöst wird, wenn die Nachricht abgeholt wird ... das wäre ein sicherer Zeichen, dass Ihr Servicevertrag falsch definiert ist (es könnte sein, dass Sie einen Haken verwenden müssen:

[OperationContract(Action="*")]

Um sicherzustellen, dass es korrekt zu Ihrer Methode weitergeleitet wird.