Adding a Data Connection to Some WebServices Cause InfoPath 2003 to Disappear
When adding a web service data connection to an InfoPath 2003 form template, there is a bug that will cause InfoPath 2003 to disappear if the web service’s WSDL contains a particular recursive schema construct. The following snippet of XSD illustrates the issue:
<xs:element name="RecursiveRoot">
<xs:complexType>
<xs:sequence>
<xs:element name="Branch1" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Branch2" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
This XSD contains a recursive structure in which there is more than 1 path of recursion and the recursive root is not marked as an optional element in the XSD when referenced. InfoPath 2003 will work with the WSDL containing this XSD as expected if both references to RecursiveRoot were optional as illustrated in the following modified XSD (changes in red).
<xs:element name="RecursiveRoot">
<xs:complexType>
<xs:sequence>
<xs:element name="Branch1" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Branch2" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
If you are having issues with a web service that you own, one work around to this issue with InfoPath 2003 is to modify the WSDL for your web service as shown above. In the case that this is not an acceptable work around, or you do not own the web service, the following steps will help you work around the problem:
1. Download the WSDL file for the web service to your local machine
2. Modify the XSD in the WSDL as shown above
3. Add a Data Connection to the local version of the WSDL file
If you are setting up a submit or receive/submit web service connection then the following steps are required as well to ensure that the data InfoPath submits to the web service adheres to the original schema:
4. File --> Extract Form Files to save your form template in an uncompressed format
5. Remove the modifications made to the WSDL XSD in the copy of the XSD that was added to the form template
If you modify the data connection or add another data connection to this local WSDL file for a submit web service then steps #4-#5 will have to applied again. If you expect other users to modify the design of this form template then the local version of the WSDL should be stored in a shared location that all designers have access to.
This issue has been reported to the InfoPath team as occurring in the ItemLookup method of the web services that Amazon exposes (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl). In the case of this method, the modification that is necessary to avoid the InfoPath 2003 bug (step #2) is the following:
1. Find the BrowseNode element that contains references to other BrowseNode elements
2. Add minOccurs=”0” to the BrowseNode references (these occur under the “Children” element and the “Ancestors” element)
Since ItemLookup is a receive only method, there is no need to modify the form template files by hand (steps #4 and #5).