Samples not using ACORD format on the wire?

Sep 4, 2008 at 10:28 PM
Hi,$0$0$0$0I am working on a project using the ACORD factory.  I stood up a WCF service using that accepts a TXLife object as a parameter and returns a TXLife, and I set up a BizTalk orchestration that sends a TXLife file to the service and receives the response.  When I examined the response, I noticed that it contained a bunch of fields that begin with underscores.  It looks like the fields in the response are the same as the private fields in the TXLife object.  I suspect the problem is that the TXLife object is designed for the XML serializer ([Serializable]), while WCF uses the DataContract serializer ([DataContract]) by default.  OK, I thought it was probably just an oversight on my part, so I checked the sample app that comes with the software factory.  I enabled WCF tracing for the sample services, and started up the sample "Can Agent Sell?" app.  I clicked the "Can Agent Sell?" button and received a successful response.  In the WCF trace file, I get this:$0$0$0$0$0<TXLifeRequest xmlns:a="http://schemas.datacontract.org/2004/07/CompanyX.Insurance.La.DataContracts" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">$0$0<a:__BenefitsInquiryType i:nil="true"></a:__BenefitsInquiryType>$0$0<a:__CaseStatusOnResponseInd i:nil="true"></a:__CaseStatusOnResponseInd>$0$0<a:__ChangeSubType i:nil="true"></a:__ChangeSubType>$0$0<a:__CorrelationGUID i:nil="true"></a:__CorrelationGUID>$0$0<a:__CorrelationGUIDState i:nil="true"></a:__CorrelationGUIDState>$0$0<a:__CriteriaExpression i:nil="true"></a:__CriteriaExpression>$0$0<a:__DataTransmittalSubType i:nil="true"></a:__DataTransmittalSubType>$0$0$0...$0$0</TXLifeRequest>$0$0$0$0$0It looks to me like the ACORD software factory is not actually using the ACORD standard (the ACORD standard doesn't have any underscores!).  Someone please tell me what I am missing!$0$0$0$0$0Regards,$0$0$0$0$0Russell Waltz$0$0$0$0
Sep 4, 2008 at 10:32 PM
Sorry, my browser foobarred the post.  Here is what it should look like:

Hi,

I am working on a project using the ACORD factory.  I stood up a WCF service using that accepts a TXLife object as a parameter and returns a TXLife, and I set up a BizTalk orchestration that sends a TXLife file to the service and receives the response.  When I examined the response, I noticed that it contained a bunch of fields that begin with underscores.  It looks like the fields in the response are the same as the private fields in the TXLife object.  I suspect the problem is that the TXLife object is designed for the XML serializer ([Serializable]), while WCF uses the DataContract serializer ([DataContract]) by default.  OK, I thought it was probably just an oversight on my part, so I checked the sample app that comes with the software factory.  I enabled WCF tracing for the sample services, and started up the sample "Can Agent Sell?" app.  I clicked the "Can Agent Sell?" button and received a successful response.  In the WCF trace file, I get this:

<TXLifeRequest xmlns:a="http://schemas.datacontract.org/2004/07/CompanyX.Insurance.La.DataContracts" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:__BenefitsInquiryType i:nil="true"></a:__BenefitsInquiryType>
<a:__CaseStatusOnResponseInd i:nil="true"></a:__CaseStatusOnResponseInd>
<a:__ChangeSubType i:nil="true"></a:__ChangeSubType>
<a:__CorrelationGUID i:nil="true"></a:__CorrelationGUID>
<a:__CorrelationGUIDState i:nil="true"></a:__CorrelationGUIDState>
<a:__CriteriaExpression i:nil="true"></a:__CriteriaExpression>
<a:__DataTransmittalSubType i:nil="true"></a:__DataTransmittalSubType>
...
</TXLifeRequest>

It looks to me like the ACORD software factory is not actually using the ACORD standard (the ACORD standard doesn't have any underscores!).  Someone please tell me what I am missing!

Regards,

Russell Waltz
Sep 5, 2008 at 4:27 PM

I fixed it (almost).  Since the TXLife object is [Serializable], we have to tell WCF to use the Xml Serializer, instead of the default DataContract Serializer.  I updated my service contract as follows:

[ServiceContract(Name = "ServiceX", Namespace = "http://ACORD.org/Standards/Life/2")]
[XmlSerializerFormat]
public interface IServiceX
{       
   [OperationContract(Action="DoSomething", ReplyAction="DoSomethingResponse")]
   [return: MessageParameter(Name = "TXLife")]
   TXLife DoSomething([MessageParameter(Name="TXLife")]TXLife requests);

   ...
}

Now what I am seeing on the wire much more closely resembles the ACORD specs.  I am still having namespace problems, but this is much closer to valid ACORD XML than it was before.  The TXLife object insists that all direct children of TXLife (UserAuthRequest, TXLifeRequest, etc.) are applied with xmlns="", while the actual ACORD schemas have everything qualified with the ACORD namespace.  Maybe this fix should go into V2 of the factory?

Regards,

RW

Coordinator
Oct 23, 2008 at 8:09 PM
Edited Oct 23, 2008 at 8:10 PM

Great comments and catch, thanks.  We need to do things to the SF (or you can do it yourself) to make the wire XML ACORD compatable -- and I've been putting these changes off (although it should only take a few minutes).

1. XmlSerializerFormat to the service interfaces -- as you point out.

2. Change the ACORD schema itself to <schema> tag properties to qualified.  ElementFormDefault and AttributeFormDefault must be marked as qualified -- then we rerun the .bat file against the code generator to regen the datacontracts, and all the namespace should come through properly. 

I'll make these changes to the SF.  Thanks.

Oct 23, 2008 at 8:36 PM
I did find a workaround to fix the qualified/unqualified issue.  The root cause of the issue seems to be that the Acord schema has element forms set to unqualified.  However, all of the elements in the schema are imported.  Apparently this overrides the global element form.  The code generator does not pick up on this subtlety.  So, as a quick fix, I modified the code generator and hardcoded the element form to unqualified and the attribute form to qualified.  I regenerated the acord entities code, and now everything is peachy.  Yes, hardcoding the values in the code generator was a cheesy hack, but I was in over my head digging through that code for the first time.  Maybe you know a better way to fix it.  After getting through these small issues, the SF is working great!