#CDT #EXPORT We are experiencing an export issue for several CDTs. T

...e selected configuration but should not prevent execution of the web service.
The provided XSD file contains a definition for the type {www.407etr.com/.../transponder}identifyDuplicates, which already exists, but an error prevented retrieving the XSD of the current definition for comparison. The requested type was not created and the existing type was not altered. Verify that the definition of the existing type is compatible. Details: null (APNX-2-4045-003)
The provided XSD file contains a definition for the type {www.407etr.com/.../transponder}identifyDuplicatesResponse, which already exists, but an error prevented retrieving the XSD of the current definition for comparison. The requested type was not created and the existing type was not altered. Verify that the definition of the existing type is compatible. Details: null (APNX-2-4045-003)
XSD Parsing Message: XSD: There is no xmlns declaration for namespace 'http:...

...//www.407etr.com/ea/soa/asset/ds/tm/tl/transponder' (APNX-2-4047-000)

Is Appian trying to find a specific declaration in our web service xml?

You don't need to export those CDTs. Simply create a dummy process model in the target environment that calls this WSDL and publish the model. This will create the CDTs before hand and let you import your application. At this point you can remove the problematic CDTs from the package that is giving you trouble during export. As a general practice do not include anonymous CDTs inside your application.

The reference number to enhance this behavior is AN-46213.

Hi Eduardo. Thanks for the recommendation. Can you explain what causes a CDT to be an anonymous CDT?

1. www.ibm.com/.../
2. Now, in terms of how this looks in Appian in the Primary Data Source, well, the problematic CDTs in your DT_MODEL table will have in their XMODEL (transformed model) column the following inside its definition:

<details key="namespace" value="Response"/>

instead

<details key="namespace" value="##targetNamespace"/>

Here's an example (excerpt) from the XMODEL table of a CDT that won't be able to be imported (and is not needed for export since you can use the approach I suggested above)

<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="element"/>
<details key="name" value="Prospect"/>
<details key="namespace" value="Response"/>
</eAnnotations>


while this is the excerpt of the one that works

<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="element"/>
<details key="name" value="ResponseProspect"/>
<details key="namespace" value="##targetNamespace"/>
</eAnnotations>