Root element is missing.

Question

Tried following the walk through on MSDN for Publishing WCF Services with the WCF-NetMsmq Adapter (http://msdn.microsoft.com/en-us/library/bb259950(BTS.10).aspx) . Tried using the sample application on the website and tried integratinga that with my existing BizTalk solution as well. It let me do the bindings properly but when I try to browse teh WCF application through IIS7 as mentioned in the steps, I am getting following error :

Root element is missing.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Xml.XmlException: Root element is missing.

Any help willl be appreciated. Thanks

Answer 1

I have gotten this error before in the same situation as you. Ironically, it usually occurs when the app pool identity for the published web service does not have access to the BizTalk databases. You usually need to modfy the app pool identity to be the one for the BizTalk isolated host account or the BizTalk host account or one that matches one of these in regards to group membership and permissions.

I think the error could be better named - it is misleading what the actual problem is.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 2

Thanks Ben, that certainly did the trick as I don't see the same error message now, I am getting a new error and still can't  browse the WCF

An error occurred while opening the queue:The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The  message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.

The queue does exist and I am running it as a Administrator so have all the required permissions as well. Any ideas, why I am getting this message

Thanks again.....

Answer 3

So I guess you are using the netMSMQ binding. The path in the BizTalk port uses different conventions than the traditional queue path. Please check the path to make sure it conforms to what BizTalk is expecting.

Are using a private queue or a public queue? Also, is your queue on a different box than BizTalk?

Did you grant permissions on the queue to the host user?

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 4

I am using WCF-netmsmq as a transport type in BizTalk

I am using a private Transactional queue. Queue is on the same box with all the permission.
Publishing a WCF using BizTalk WCF Service Publishing Wizard

 Bindings in web.config after completing the publishing wizard looks like this :

 <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehaviorConfiguration">
          <serviceDebug httpHelpPageEnabled="true" httpsHelpPageEnabled="false" includeExceptionDetailInFaults="false" />
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <!-- Note: the service name must match the configuration name for the service implementation. -->
      <service name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance" behaviorConfiguration="ServiceBehaviorConfiguration">
        <endpoint name="HttpMexEndpoint" address="mex" binding="mexHttpBinding" bindingConfiguration="" contract="IMetadataExchange" />
        <!--<endpoint name="HttpsMexEndpoint" address="mex" binding="mexHttpsBinding" bindingConfiguration="" contract="IMetadataExchange" />-->
      </service>
    </services>
  </system.serviceModel>

Still getting the same error as described in previous post.
Thanks

Answer 5

Did you specify the path to the queue during the wizard? I would check in the port settings to see if it is there. It would have a path like net.msmq://localhost/private/queueName. I did not see the queue endpoint listed in the config file.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 6

Yes I did... below is th sanpshot of BizTalk Settings in the web.config....

  <bizTalkSettings>
    <!--
      mexServiceHostFactory debug:
      Set to "true" to launch debugger when MexServiceHostFactory.CreateServiceHost(...) is called by IIS.
      Used to debug from initial point of activation by IIS.
      Default value is "false" for normal operation.
    -->
    <mexServiceHostFactory debug="true">
      <receiveLocationMappings>
        <!--add markupFileName="*.svc" receiveLocationName="?" publicBaseAddress="protocol://host[:port]" /-->
        <add markupFileName="Microsoft_Samples_BizTalk_WCF_NetMsmqPublishing_BizTalkApp_OrderProcess_PurchaseOrderRequestPort.svc" receiveLocationName="WCFNetMsmqAdapterPublishing.ReceivePurchaseOrder.NetMsmq" publicBaseAddress="http://localhost/" />
      </receiveLocationMappings>
    </mexServiceHostFactory>
    <!--
      webServiceHostFactory debug:
      Set to "true" to launch debugger when WebServiceHostFactory.CreateServiceHost(...) is called by IIS.
      Used to debug from initial point of activation by IIS.
      Default value is "false" for normal operation.
    -->
    <webServiceHostFactory debug="false" />
    <!--
      isolatedReceiver disable:
      Set to "true" to skip IBTTransportProxy.RegisterIsolatedReceiver(...) and IBTTransportProxy.TerminateIsolatedReceiver(...) calls.
      Used for testing metadata exchange without having to setup receive location.
      Default value is "false" for normal operation.
    -->
    <isolatedReceiver disable="false" />
    <!--
      btsWsdlExporter disable:
      Set to "true" to skip adding BtsWsdlExporter behavior extension to service endpoint.
      Used for testing or comparing strongly-typed WSDL customization versus weakly-typed WSDL of generic WCF service.
      Default value is "false" for normal operation.
    -->
    <btsWsdlExporter disable="false" />
  </bizTalkSettings>

Thanks..

Answer 7

I am able to run the walk through sample on MSDN,  I am trying to implement the same on my BizTalk solution. I have an ongoing issue with my custom pipeline but I will open a new thread for that as the issue is not related.
Thanks Ben for all your help !!

Answer 8

Ben, I was reading your thread for converting through ActiveXMessageformatter http://msinnovations.spaces.live.com/blog/cns!62E68922E47BC425!198.entry, but that didn't;t help much in my scenario. Can you shed some light on that.
I have a X12 format file I am able to send through client application.
 
MessageQueue mq = new MessageQueue(@".\private$\testqueue");
              mq.Send(File.ReadAllText(@"D:\hcfa20090723-0.x12"));
                mq.Formatter = new  ActiveXMessageFormatter();

If I check journal message in MSMQ after using the ActiveXMessageformatter I do have everything in string format with no extra headers in it, but due to some reason my pipeline component have EDI disassembler at the disassembler stage doesn't like it
 biz talk error log states that no disassemble stage component can recognize the data?

Thanks

Answer 9

You should try to validate instance for the X12 file in VS to see if it can parse the EDI content. You will need to choose the validate type as Native.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 10

I think what you meant is to add EDI batch schema. I have added EDIfact batch schema and X12 Batch schema and I am changing the properties as you suggested. Still not sure how this is going to help in the given scenario ? Thanks

Answer 11

If I add X12_batch schema change the instance input to "Native" and added the X12 document I got "Instance input FileName" and when I run validate instance schema. It throws an error"Failed to create instance for schema X12_BatchSchema.xsd. How come that text file works just fine if it is not coming from MSMQ ?

Answer 12

No, I was not thinking about a batch schema. In VS you can right-click on a BizTalk schema and then go to validate instance and it can validate a file for you. You were getting parse errors so this is a way to ensure that the X12 instance matches the schema.

You can also open the MSMQ message up and see the first part of the payload to see if there are extra characters.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 13

Same X12 can be easily disassemble if I am picking it from FILE location not MSMQ location. I am using ActiveX Formatter to decode the data in MSMQ to remove extra character. I tried using pass through pipeline and the result I am getting is exactly the same as original X12 file looks alike with no special characters. But if I introduce EDI disassemble piece it just start giving me error that No Disassemble Stage Component Can Recognize the Data. ? I am stuck at this point as I have tried all the possible ways I can think of to defeat this error.

I am still not sure how just picking the message from MSMQ location not FILE could cause this as if I check the body of my MSMQ it looks exactly similar to what the original X12 should look alike before it goes to EDI dissembler..:(

 

Answer 14

There are a couple of other options that could occur. For example, the encoding can change like from UTF-8 to UTF-16 and you have extra characters that make unreadable. If the MSMQ message (first characters) look good then maybe something at the end of the file is causing a problem. Could you share the X12 message from MSMQ here - I may be able to identify the problem by looking at it.

Did you do a file comparison of the two different messages (one from file and the other from MSMQ)?

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 15

I have tried both UTF-8 and UTF-16 as well and I am changing the encoding type before I convert the message through ActiveXFormat and send It to the queue and I have compared both files in a TextPad they are exactly similar including the first character..Do you want me to paste the X12 in the thread? I would prefer if I can send you the X12 in your email if that is okay with you..

Answer 16

Any ideas in regards to my last post ?

Answer 17

The line breaks are not in the original right? Just in what you copied. Right?

Also, the ISA and GS fields were modified prior to pasting, is this correct? If not, I am guessing that the EDI disassembler cannot determine which party to use for the schema and then uses the default schemas rather than the custom ones.

It is possible to lose the original ISA and GS values along the way so this could be the problem.

As for the encoding stuff, I meant that the encoding could change along the way and you did not know. You should not change anything about the pipeline encoding if you do not have to. If you open a file in WordPad and it does not look like it does in NotePad, then you probably have an encoding problem. In WordPad you can check for squares after every character which means it is in double-bytes and you would need to build a custom pipeline component to remove these. You could check on this.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 18

Yes, there are no line breaks in the orignal X12. But I am not sure what is missing here or I am not understanding the process straight.
I tried copying the body of MSMQ message and pasted that in a notepad and tried sending that notepad through the FILE transport and that gave me XML's in send location with no error at all, unless it is not just the body of a message which is going forward I don't think it should break like this. MSMQ is only suppose to send the message what it see in the body of it, will this be a correct statement to say ?
I am kind of getting out of options here as it is not making much sense to me how the exact same file can break just with two different transport type ? even tried writin the file from MSQ in the flat file and having file transport pick it up that work just fine... is that a MS bug or something ?

Answer 19

Thanks Ben for all your help, I am moving on to another issues from here on as this is just going in loop. Just as a workaround what I did is using MSMQ to receive file from the client and then trigger my console app to write the message in the text file and have biztalk pick it up using "FILE" transport and that work just fine. So if you get any lead on this or any poossible solution I will aprreicte it..

Thanks again

Answer 20

I get the same error message.
I use Windows 2003 R2 with BizTalk 2009.

My Receivelocation is also MSMQ.
The first time (after removing dll's and redeployed the solution) when I create a WCF endpoint (mexonly) I can look into the WSDL.

When I want update the underlying schema, redeploy the solution and recreate the WCF endpoint.
Then I get the message Root element is missing.

I'm quite sure it's not security. The App-pool is running under the same serviceaccount as BizTalk itself.