Receiving "There is an error in the XML document" exception processing a WCF service response but response does validate against the schema RRS feed

  • Question

  • I used the Add Generated Item -> Consume WCF Service feature in a BizTalk Visual Studio project to generate the schemas and type to consume a WCF web service.  I then created an orchestration and set up a port to call one of these services send a request and receiving a response. The send works and I see the service is called successfully but when BizTalk tries to process the response I am receiving the exception below stating there is an error in the XML document.  I went and looked at the suspended instance, looked at the Messages tab of the ServiceDetails and the response message looked fine.  I copied the text from the body Message Part and placed it in a new xml file and used Visual Studio to do a Validate Instance on that xml with the schema generated by the Add Generated Item wizard and it validates successfully.  I have the Outbound and Inbound Messages configured to use the Body property on the WCF port configuration.  Any ideas why it would through this error when the message body validates against the schema?

    Exception type: InvalidOperationException
    Source: Microsoft.XLANGs.Engine
    Target Site: Void ExceptionRaised()
    The following is a stack trace that identifies the location where the exception occured

       at Microsoft.XLANGs.Core.Context.ExceptionRaised()
       at RSA.BizTalk.Imaging.ProcessFileUploadRequest.segment4(StopConditions stopOn)
       at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
    Additional error information:
            <DocumentID xmlns=''> was not expected.
    Exception type: InvalidOperationException
    Source: System.Xml
    Target Site: System.Object Read_string()
    The following is a stack trace that identifies the location where the exception occured
       at System.Xml.Serialization.XmlSerializationPrimitiveReader.Read_string()
       at System.Xml.Serialization.XmlSerializer.DeserializePrimitive(XmlReader xmlReader, XmlDeserializationEvents events)
       at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)

    Thursday, February 4, 2016 12:19 AM

All replies

  • I have just seen your exception stack trace and it states that

    "  <DocumentID xmlns=''> was not expected "

    So verify what is the message type of your web service response . I don't think you are  populating shapes to correct message type .



    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply

    Thursday, February 4, 2016 12:35 AM
  • The message types and port types were auto generated by the Add Generated Items wizard.  I am using the port type pre-defined by that process so it auto assigns the message type to the port and I had to make my receive shape match that type in order to connect the response to the shape. The expected response for that service operation does contain a DocumentID element.  I can see from the tracked messages, etc. that the XML Receive Pipeline is correctly resolving the schema type from the message.

    Thursday, February 4, 2016 12:41 AM
  • Hi ,

    If you see your exception message it clearly states the reason for the message transmission failure . May be this will be the message type of the exception which your port is able to capture  .

    I would suggest to run fiddler to see the response message on the wire and  validate it with your response schema .



    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply

    Thursday, February 4, 2016 12:46 AM
  • As I stated I can see the message body in the tracked message data and/or service details of the suspended service and when I copy that message data into an xml file I can successfully validate it with the XML schema that was auto generated. Here is additional info about the schemas/messagetypes/port definition and a sample of the response message.

    UploadNewDocument operation on port type
    BizTalk.Imaging.ServiceAgent.IHubService_UploadNewDocument_InputMessage is a Multi-part message with a single part called parameters of type BizTalk.Imaging.ServiceAgent.HubService_tempuri_org.UploadNewDocument
    BizTalk.Imaging.ServiceAgent.IHubService_UploadNewDocument_OutputMessage is a Multi-part message with a single part called parameters of type BizTalk.Imaging.ServiceAgent.HubService_tempuri_org.UploadNewDocumentResponse
    BizTalk.Imaging.ServiceAgent.IHubService_UploadNewDocument_HubExceptionFaultContractFault_FaultMessage is a Multi-part message with a single part called detail of type BizTalk.Imaging.ServiceAgent.HubService_schemas_datacontract_org_2004_07_IntegrationHub_Hub

    Extracts of the schemas generated by "Add Generated Items" wizard pointing at service mex address:
    <xs:schema xmlns:tns="" elementFormDefault="qualified" targetNamespace="" xmlns:xs="">
      <xs:import schemaLocation=".\HubService_schemas_microsoft_com_2003_10_Serialization.xsd" namespace="" />
      <xs:import schemaLocation=".\HubService_schemas_datacontract_org_2004_07_IntegrationHub.xsd" namespace="" />
      <xs:import schemaLocation=".\HubService_schemas_microsoft_com_2003_10_Serialization_Arrays.xsd" namespace="" />
      <xs:element name="UploadNewDocumentResponse">
            <xs:element xmlns:q13="" minOccurs="0" name="UploadNewDocumentResult" nillable="true" type="q13:UploadNewDocumentResponse" />

    <xs:schema xmlns:ser="" xmlns:tns="" elementFormDefault="qualified" targetNamespace="" xmlns:xs="">
      <xs:import schemaLocation=".\HubService_common_services_datacontracts_businessruleresponse.xsd" namespace="http://common/services/datacontracts/businessruleresponse" />
      <xs:import schemaLocation=".\HubService_schemas_microsoft_com_2003_10_Serialization.xsd" namespace="" />
      <xs:import schemaLocation=".\HubService_schemas_microsoft_com_2003_10_Serialization_Arrays.xsd" namespace="" />
      <xs:complexType name="BaseResponse">
          <xs:element xmlns:q1="http://common/services/datacontracts/businessruleresponse" minOccurs="0" name="BusinessResponseMessage" nillable="true" type="q1:BusinessResponses" />
      <xs:complexType name="UploadNewDocumentResponse">
        <xs:complexContent mixed="false">
          <xs:extension base="tns:BaseResponse">
              <xs:element minOccurs="0" name="DocumentID" nillable="true" type="xs:string" />
    Schema Name =
    <UploadNewDocumentResponse xmlns="">
     <UploadNewDocumentResult xmlns:a="" xmlns:i="">
      <a:BusinessResponseMessage xmlns:b="http://common/services/datacontracts/businessruleresponse" />
    If I save off this message to an xml file and set the Input Instance Filename on the schema that defines the original UploadNewDocumentResponse element above and select ValidateInstance from the context menu it validates successfully

    Thursday, February 4, 2016 12:50 AM
  • Hello,

    I don't think this is a validating error.

    1) Have you tried to debug your orchestration flow?

    2) Are you performing any processing based on the response message received from the WCF webservice?

    I have faced this issue while I had a requirement to choose the flow based on a field's value coming in the response and I used xpath to fetch that value.

    Refer the article from Mahesh: There is an error in the XML document : InvalidOperationException

    Basically, In order to fetch values , you need to explicitly specify the Xpath about the type conversion and for that we need to use xpath functions depending upon requirement.

    For Number it is number(xpathquery), for String value it is string(xpathquery) , for Boolean value it is boolen(xpathquery) etc.

    Rachit Sikroria (Microsoft Azure MVP)

    Saturday, February 6, 2016 6:13 PM
  • I have looked at the orchestration debugger. I see the Green and Blue on my send and a Green on my Receive but that step never completes. I do have some expressions and message assignments further down in the orchestration that have some XPath expressions that examine the response message but it never makes it down that far. I turned on all of the message tracking and I see the Receive of the unparsed interchange and then the Send with the schema name resolved but it never makes it back into the orchestration.

    The service I am calling was developed by another group we are working with and I had done some testing the other day with them to add a 2nd and 3rd version of the same method to do some testing.  For the second version it was an exact copy but the property name in the result class was changed from DocumentID to FileNetObjectID and the response name had a 2 added to the name to match the new operation.  I was able to get that one to work and return a response to the orchestration so we thought renaming it had helped so we deleted the new operations and renamed the property in the original and it still failed.  Then we tried changing the name of the operation but still got the same error (just with an updated message name).  In all cases I can take the response message from the tracking info and validate it against the schema successfully.

    Saturday, February 6, 2016 11:23 PM