WSImport generates conflicting XMLTypes for multiple Dynamics CRM 4.0 WSDL's
Asked Answered
T

1

9

I'm currently working with the Dynamics CRM 4.0 webservice. First thing I did, was generating the right classes with wsimport for Java/JAX-WS based on the WSDL of the webservice. While generating the classes I got some errors:

[ERROR] A class/interface with the same name
"com.microsoft.schemas.crm._2007.webservices.RetrieveResponse" is already in use. Use a class customization to resolve this conflict.
  line 979 of file://src/main/webapp/WEB-INF/classes/META-INF/wsdl/CrmServiceWsdl.wsdl

[ERROR] (Relevant to above error) another "RetrieveResponse" is generated from here.
  line 12274 of file://src/main/webapp/WEB-INF/classes/META-INF/wsdl/CrmServiceWsdl.wsdl

Line 979 tells us:

<s:element name="RetrieveResponse">
    <s:complexType>
      <s:sequence>
        <s:element name="RetrieveResult" type="s3:BusinessEntity" />
      </s:sequence>
    </s:complexType>
  </s:element>

And line 12274 gives us:

<s:complexType name="RetrieveResponse">
    <s:complexContent mixed="false">
      <s:extension base="tns:Response">
        <s:sequence>
          <s:element ref="s3:BusinessEntity" />
        </s:sequence>
      </s:extension>
    </s:complexContent>
  </s:complexType>

Both parts are in the same namespace. Both will be generated as RetrieveResponse.class and so they are colliding. I've found a solution for this problem which is the JAX-B binding xml file:

<bindings node="//xsd:complexType[@name='RetrieveResponse']">
  <jaxb:class name="RetrieveResponseType"/>
</bindings>

This works (not sure if this is the correct approach..?)..

So after this, I've managed to create some successful calls to the webservice, which is great!

Now comes the problem: some business entities in dynamics crm uses the class Picklist. This type of entity can be queried with the Metadata service: http://msdn.microsoft.com/en-us/library/bb890248.aspx

So the next thing I did was, again, generating the classes for the metadata service, based on it's WSDL. The result of the generated classes are not as we except. For example, it generates a class 'com.microsoft.schemas.crm._2007.webservices.ExecuteResponse'. But this class also exists in the exact same package of the CrmService generated classes. Differences between the 2 are:

Metadataservice ExecuteReponse:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "response"
})
@XmlRootElement(name = "ExecuteResponse")
public class ExecuteResponse {

   @XmlElement(name = "Response")
   protected MetadataServiceResponse response;
etc...

CrmService ExecuteReponse:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "response"
})
@XmlRootElement(name = "ExecuteResponse")
public class ExecuteResponse {

   @XmlElement(name = "Response", required = true)
   protected ResponseType response;
etc...

Now this class is just one example (another example is CrmAuthenticationToken), which is a almost exact duplicate of another class. To be able to use the same classes, I've added a package-suffix to the CrmService classes (displayed as prefix.). So now when I try to call the CrmService, I get the following exception:

Two classes have the same XML type name "{http://schemas.microsoft.com/crm/2007/CoreTypes}CrmAuthenticationToken". Use @XmlType.name and @XmlType.namespace to assign different names to them.
this problem is related to the following location:
    at com.microsoft.schemas.crm._2007.coretypes.CrmAuthenticationToken
    at public com.microsoft.schemas.crm._2007.coretypes.CrmAuthenticationToken *prefix*.com.microsoft.schemas.crm._2007.coretypes.ObjectFactory.createCrmAuthenticationToken()
    at *prefix*.com.microsoft.schemas.crm._2007.coretypes.ObjectFactory
this problem is related to the following location:
    at *prefix*.com.microsoft.schemas.crm._2007.coretypes.CrmAuthenticationToken
    at public javax.xml.bind.JAXBElement *prefix*.com.microsoft.schemas.crm._2007.webservices.ObjectFactory.createCrmAuthenticationToken(*prefix*.com.microsoft.schemas.crm._2007.coretypes.CrmAuthenticationToken)
    at *prefix*.com.microsoft.schemas.crm._2007.webservices.ObjectFactory

I personally think it's weird they put different classes with the same name in the same package structure. This means you can never use the 2 webservices at the same time..

Is this a Microsoft, a WSimport bug or just a stupid mistake at my end? Hope somebody can help me with this problem!

Thanks for your time!

Toadeater answered 9/5, 2012 at 12:1 Comment(0)
P
1

This is Microsoft inconsistency combined with wsimport being somewhat hard to use.

The PickList and the CRMAuthenticationToken sound like custom datatypes, you'd expect for these to get reused from service to service. You'd also expect certain CRM-specific entities (say, Customer or Business or Address) to get reused from service to service.

It is bad manners on the Microsoft side of things that they define these differently for different services. This makes it hard to take the answer of one service and send it on to another service.

Had the services shared one or more common schemas, you could've compiled those first, using xjc. Then you could've provided a so-called episode file to wsimport to tell it to use those classes instead of generating new ones. See the metro guide. This is quite a puzzle, I can tell you from experience, I ran into bug JAXB-829, xjc forgets to generate if-exists attributes in the episode file.

What I'd do, I'd compile each wsdl to its own package and treat the generated classes as simple unintelligent Data Transfer Objects. If I wanted to send an object I'd just retrieved from one service on to a second service, I'd convert between the both. If this results in terribly unwieldy code, or if you wish to add logic to certain entities, I'd suggest you write your own proper model classes for the Entities you wish to share and write converters to and from the DTO objects in the web services packages you wish to use them with.

Postilion answered 20/1, 2013 at 18:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.