July 2008 - Posts

• Codeless way of getting DBXL document properties (docid, doctype and DBXL URL)

  A DBXL solution that is designed to be generic needs to be able to access several DBXL properties. For example, a solution that wants to display a hyperlink in an e-mail needs to be able to determine its DocId and the DBXL URL. While it's easy to write code to retrieve this data, it is often not desirable to do so. For instance, browser-based solutions are much harder to deploy when they contain code. This blog post describes a way of getting this information using only rules. Here is what you need to do. To get the DBXL Document ID, add a DocID field to your data source and set it on load via this rule: substring-before(substring-after(/processing-instruction()[local-name(.) = "QdabraDBXL"], 'docid="'), '"') Note that this value will not be set for a new document. To get the DBXL URL, add a url field to your data source and set it on load via this rule: substring-before(substring-after(/processing-instruction()[local-name(.) = "mso-infoPathSolution"], 'href="'), "/Forms") Finally, to get the DBXL document type, add a DocType field to your data source and set it on load via this rule: substring-before(substring-after(/processing-instruction()[local-name(.) = "mso-infoPathSolution"], concat(<url>, "/Forms/")), "/template.xsn") Note how the last rule builds on the URL value we've gotten previously. You’ll need to replace <url> with the xpath for the URL saved previously. It is important to understand that these rules will only work after the InfoPath solution has been published to DBXL. You can download a full sample here: http://www.infopathdev.com/files/folders/examples/entry41179.aspx As an alternative, you could use qRules. You can find documentation for qRules by clicking here. Posted Jul 22 2008, 04:08 AM by davidair with 1 comment(s) Filed under: Qdabra PI

• 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. Posted Jul 17 2008, 09:46 PM by davidair with no comments

• Excel to XML – automatically generating InfoPath forms from Excel data

  Does your data live in Excel? Would you like to move it to InfoPath? Qdabra Excel to XML Tool to the rescue! This simple command-line based tool will take an existing Excel spreadsheet and generate XML documents with your data. The tool will also optionally upload the documents to Qdabra DBXL to further streamline your data processing. The tool is driven by a simple configuration file that maps Excel columns into fields on an InfoPath solution. Suppose, for example, that you have a spreadsheet with two columns, "name" and "phone". You also have a ContactInfo InfoPath form with those two fields. In order to generate multiple ContactInfo forms, just add the following to the MappingInfo section of the configuration file of the tool:<add key="name" value="/my:myFields/my:name" /> <add key="phone" value="/my:myFields/my:phone" />Once you run the tool, it will generate one line for each row in the spreadsheet. The tool skips already generated files so it can be re-run incrementally whenever additions are made to the spreadsheet. Things to watch out for: - "nillable" - this optional attribute of the mapping info should be used if a datatype in InfoPath cannot be null (bool, date/time, integer/double) but your spreadsheet contains blank values for some rows - namespaces: make sure that you have correctly listed all namespaces used in the xpaths. InfoPath uses the "my" prefix but it may refer to different namespaces so check carefully or you will end up with empty documents! Posted Jul 16 2008, 08:35 PM by davidair with no comments

• Installing DBXL – beware of multiple hostnames!

  When you install Qdabra DBXL on your server you may encounter errors such as "Error initializing DBXL database" -->The request failed with HTTP status 404: Not Found". One of the reasons this happens is that your site is configured to use multiple hostnames or multiple IP addresses. If DBXL picks the wrong hostname/IP, the installation will fail. The easiest workaround is to go to your site settings (IIS management console) and temporarily remove all hostnames/IP addresses that will not work. Make sure only to leave the hostname that the currently logged-in user can access. After DBXL installs successfully you can re-add the additional hostnames and/or IP addresses. Posted Jul 16 2008, 07:54 PM by davidair with no comments

• Deleting all documents for a document type using the Qdabra DBXL Migration Tool v2

  The Qdabra DBXL Administration Tool (DAT) allows you to quickly delete all documents from a document type: simply open the configuration for the document type, select the "Documents" tab and click on the "Delete All" button. However, you may encounter an error due to timeout if your document type contains too many documents (usually in the order of thousands).The good news is that you can use the Qdabra DBXL Migration Tool to individually delete all the documents one by one so that the timeout does not occur. Here is how you do it: Download a copy of the Qdabra DBXL Migration Tool from here: http://www.infopathdev.com/files/folders/document_deployer/default.aspx   Download a scenario file for documents removal: http://www.infopathdev.com/files/folders/document_deployer/entry31629.aspx Open the Migration Tool UI, select the "custom" tab and load the scenario you've downloaded in step 2. Scroll down in the scenario variables list and set "docTypeName" to the document type you want to clear. Select "RemoveDocuments" in the scenario runs and click "Run". This should delete all the documents from the specified document type:   Posted Jul 08 2008, 07:36 PM by davidair with no comments