InfoPath data connection: what if secondary data source does not display the structure? - David Airapetyan
in

InfoPath Dev

David Airapetyan

InfoPath data connection: what if secondary data source does not display the structure?

When a data connection is added in InfoPath the data structure is inferred from the data. This functionality is very important because we want to be able to design against the secondary data source and we need the data to show in the Data Source Pane (DSP) for that.

In the case of web services, InfoPath will use the parameters provided by the user during the data connection configuration to retrieve a sample data and generate the data source based on it. In some cases this may fail to work. For example, suppose your web method returns an XmlDocument called "resultDocument". All you may see in the DSP is the node "resultDocument" without anything underneath even though InfoPath has successfully downloaded the data.

Warning: the following steps require advanced knowledge and may render your solution unusable.

When adding a web service connection, InfoPath will usually generate three schema files:

ConnectionName
.xsd – will contain the same structure as the DSP (query fields and data fields).
ConnectionName1.xsd – will contain the details of the web service parameters and return types. If an XML node is returned, the type will be listed as "any".
ConnectionName2.xsd – will contain the schema that was automatically inferred from the sample XML that was downloaded when the data connection was created.

Note that the schema stored in ConnectionName2.xsd is not directly connected to the other schemas. Instead, a special node is inserted into sampledata.xml that links them, namely xd:RequiredAny. In the case when no data structure is displayed, this node will be missing. Here are the full steps to fix the problem:


1. Inspect ConnectionName1.xsd for the return type of your web method (in our example, resultDocument). You are likely to see that the any element is listed as non-required:

<s:element minOccurs="0" maxOccurs="1" name="resourceXml">
 <s:complexType mixed="true">
  <s:sequence>
   <s:any minOccurs="0"></s:any>
  </s:sequence>
 </s:complexType>
</s:element>

Remove the minOccurs element to make it required.


2. You now need to specify what schema replaces the "any". Inspect ConnectionName2.xsd and locate the root element of the XML that is being returned. Edit sampledata.xml and add the following node under <xd:RequiredAnys/>:

<xd:RequiredAny SOM_Path="{namespace}nodeName/{namespace}nodeName/##any[1]" NamespaceURI="namespace" LocalName="rootNodeName"/>

Here the SOM_Path will be the path to the response node, the NamespaceURI will be the namespace of the node being returned and LocalName will be the name of the root node.

You can find an example of this path by generating a data connection that does not have the issue that this document is trying to address.


3. In sampledata.xml, locate the section of the data that corresponds to the returned result. It will be an  empty node (such as <resultDocument/>). Replace it by <resultDocument><ns:rootNode/></resultDocument> where rootNode refers to the root node of the sample data. Make sure to define the namespace prefix somewhere in the sampledata.xml file (can do this at the root).
 You should be now able to design against the data source!


Huge thanks to
Tom for discovering this workaround.

Comments

No Comments

About davidair

I am a Computer Science graduate from McGill University in Montreal, Canada. I have over seven years of industry experience including almost five of them spent with the Microsoft Corporation where I shipped several versions of Microsoft Office InfoPath. Originally from Russia, I am fluent in several languages, including Russian, English, French, C#, C++ and Perl. I currently reside in Montreal and work for Qdabra Software.
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.