none
Difference in Response messages while using legacy Sql Adapter and WCF Sql Adapter (BTS 2010 Adapter Pack) RRS feed

  • Question

  •  

    Hi

    I have a scenario in which when I am using a Legacy SQL Adapter for Pollling I am getting the following message as response which is perfect :

    <ComplaintReq xmlns="http://SqlPolledComplaints">

    <dbo.ComplainRecords Complainee="331156" ComplainID="222222" Problem="Same" />

    </ComplaintReq>

     

    Now when I migrate to WCF Sql Adapter (BTS 2010 Adapter Pack)from Legacy one, the response gets slightly modified to (namespace decl added):

    <ComplaintReq xmlns="http://SqlPolledComplaints">

    <dbo.ComplainRecords Complainee="331156    " ComplainID="222222    " Problem="Same" xmlns="" />

    </ComplaintReq>

    I have applied just the normal seetings on my WCF Rcv Port (WCF-Custom Adapter with SqlBinding ) which is responsible for the Polling Operation:

    Now because of this slight modification my map is  ot able to handle that and it breaks

     

    WCF Receive Port Binding(WCF-Custom Adapter with SqlBinding)

    <ReceiveLocation Name="E2E_MigrationTest_WcfReceiveLocation_SqlAdapterBinding_PollingOperation_Custom">
              <Description xsi:nil="true" />
              <Address>mssql://mgsi-8440p2//CustomerCareDB?&amp;InboundID=0</Address>
              <PublicAddress xsi:nil="true" />
              <Primary>true</Primary>
              <ReceiveLocationServiceWindowEnabled>false</ReceiveLocationServiceWindowEnabled>
              <ReceiveLocationFromTime>2000-01-01T00:00:00</ReceiveLocationFromTime>
              <ReceiveLocationToTime>2000-01-01T23:59:59</ReceiveLocationToTime>
              <ReceiveLocationStartDateEnabled>false</ReceiveLocationStartDateEnabled>
              <ReceiveLocationStartDate>2000-01-01T00:00:00</ReceiveLocationStartDate>
              <ReceiveLocationEndDateEnabled>false</ReceiveLocationEndDateEnabled>
              <ReceiveLocationEndDate>2000-01-01T23:59:59</ReceiveLocationEndDate>
              <ReceiveLocationTransportType Name="WCF-Custom" Capabilities="907" ConfigurationClsid="af081f69-38ca-4d5b-87df-f0344b12557a" />
              <ReceiveLocationTransportTypeData>&lt;CustomProps&gt;
      &lt;BindingType vt="8"&gt;sqlBinding&lt;/BindingType&gt;
      &lt;BindingConfiguration vt="8"&gt;&amp;lt;binding name="SqlAdapterBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:20:00" sendTimeout="00:20:00" maxConnectionPoolSize="100" encrypt="false" workstationId="" useAmbientTransaction="true" batchSize="20" polledDataAvailableStatement="" pollingStatement="exec [GetComplain]" pollingIntervalInSeconds="30" pollWhileDataFound="false" notificationStatement="" notifyOnListenerStart="true" enableBizTalkCompatibilityMode="true" chunkSize="4194304" inboundOperationType="XmlPolling" useDatabaseNameInXsdNamespace="false" allowIdentityInsert="false" acceptCredentialsInUri="false" enablePerformanceCounters="false" xmlStoredProcedureRootNodeName="ComplaintReq" xmlStoredProcedureRootNodeNamespace="http://SqlPolledComplaints" /&amp;gt;&lt;/BindingConfiguration&gt;
      &lt;InboundBodyLocation vt="8"&gt;UseBodyElement&lt;/InboundBodyLocation&gt;
      &lt;InboundNodeEncoding vt="8"&gt;Xml&lt;/InboundNodeEncoding&gt;
      &lt;OutboundBodyLocation vt="8"&gt;UseBodyElement&lt;/OutboundBodyLocation&gt;
      &lt;OutboundXmlTemplate vt="8"&gt;&amp;lt;bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="xml"/&amp;gt;&lt;/OutboundXmlTemplate&gt;
      &lt;DisableLocationOnFailure vt="11"&gt;0&lt;/DisableLocationOnFailure&gt;
      &lt;SuspendMessageOnFailure vt="11"&gt;0&lt;/SuspendMessageOnFailure&gt;
      &lt;IncludeExceptionDetailInFaults vt="11"&gt;0&lt;/IncludeExceptionDetailInFaults&gt;
      &lt;CredentialType vt="8"&gt;None&lt;/CredentialType&gt;
      &lt;OrderedProcessing vt="11"&gt;0&lt;/OrderedProcessing&gt;
      &lt;Identity vt="8" /&gt;
    &lt;/CustomProps&gt;</ReceiveLocationTransportTypeData>
              <ReceivePipeline Name="Microsoft.BizTalk.DefaultPipelines.XMLReceive" FullyQualifiedName="Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Type="1" TrackingOption="None" Description="" />
              <ReceivePipelineData xsi:nil="true" />
              <SendPipeline xsi:nil="true" />
              <SendPipelineData xsi:nil="true" />
              <Enable>false</Enable>
              <ReceiveHandler Name="BizTalkServerApplication" HostTrusted="false">
                <TransportType Name="WCF-Custom" Capabilities="907" ConfigurationClsid="af081f69-38ca-4d5b-87df-f0344b12557a" />
              </ReceiveHandler>
            </ReceiveLocation>

     

     

    Any suggestions or advise on this ?


    Amit Shukla
    Wednesday, February 23, 2011 7:01 PM

Answers

  • Thanks Ben for your response. Just throwing some light on the Issue , this issue has nothing to do with the Migration tool, and it's just the way the legacy SQL and the WCF Sql Adapter behave.

    To go about this issue I simply set the 'ElementFormDefault' to Default (Unqualified) as well as the AttributeFormDefault to the Default (Unqualified)  and thus even though thr Xmlns thing still comes along , it never gets invalidated and transformation works fine.


    Amit Shukla
    Friday, February 25, 2011 11:36 AM

All replies

  • The least invasive change would be to create a pipeline component to remove the extra xml declaration and add this to a custom receive pipeline that receives the message. Thanks,
    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, February 24, 2011 4:39 PM
    Moderator
  • Thanks Ben for your response. Just throwing some light on the Issue , this issue has nothing to do with the Migration tool, and it's just the way the legacy SQL and the WCF Sql Adapter behave.

    To go about this issue I simply set the 'ElementFormDefault' to Default (Unqualified) as well as the AttributeFormDefault to the Default (Unqualified)  and thus even though thr Xmlns thing still comes along , it never gets invalidated and transformation works fine.


    Amit Shukla
    Friday, February 25, 2011 11:36 AM