Send Data Down the InfoPath
InfoPath 2003 delivers XML forms-based clients for SQL Server, Jet, and basic XML Web service data sources.
by Roger Jennings
July 2003 Issue
For This Solution: SQL Server 2000 or MSDE 2000, Access 2002 or later, Microsoft Office InfoPath 2003 (Beta 2 or later)
Microsoft Office InfoPath 2003 (formerly "XDocs") is a forms-based XML-editing application that lets ordinary Windows users generate well-formed and validated XML documents in a familiar, Office-like environment (see Resources). InfoPath's primary selling point is its simplicity: Creating a form template by dragging fields from the Data Sources task pane to an empty form-design canvas is a quick and easy process. After the initial template design, users author XML documents by filling out the template's auto-generated XHTML form and saving the resulting XML document to a file. It's easy to make incremental alterations to the templates that accommodate form users' recommendations or minor data-source changes. In this article, I'll describe InfoPath's architecture briefly and then illustrate the process of designing a moderately complex form to display, edit, and insert SQL Server data.
InfoPath, which runs only under Windows XP or 2000+, bases a form template on an arbitrary XML Schema Definition (XSD) file or a schema that the application infers from a sample XML document. The 25 business-form examples, which open from the More Forms link on the Fill Out a Form task pane, typify forms generated from conventional XSD files. InfoPath also generates schemas from ActiveX Data Objects (ADO) data sources or document-centric XML Web services. XML documents saved by forms that are based on ADO rowsets include data-attribute values before and after editing, and the rowset schema. This means that the XML data behind ADO-based forms isn't useful outside the InfoPath environment without a further transformation process. Web services generate usable element-centric XML documents, but InfoPath's reliance on the Microsoft SOAP Toolkit 3.0 for consuming Web services imposes limitations, such as lack of built-in support for SOAP headers. Setting up a Web service data source is similar to the Office XP Web Services Toolkit 2.0's Web Service Reference tool (see Resources).
Alternatively, starting with an empty form and adding HTML controls from a toolbox defines a new data-source schema automatically. The toolbox includes standard textbox, dropdown list, listbox, checkbox, option button, and submit button controls, along with additional InfoPath-specific controls I'll describe shortly. Experienced Microsoft FrontPage and Access designers will adapt to InfoPath's UI quickly; designing data-entry and editing forms is similar to creating data-access pages in Access 2000 and later. Forms support JScript or VBScript event handlers, but scripting isn't required for basic query and data-entry operations. Developers don't need to enter the scene until it's time to integrate InfoPath XML documents into the workflow process, so the implementation cost is low.
InfoPath stores all template-related files in a compressed archive (cabinet or CAB) file called an InfoPath solution file—TemplateName.xsn (see Figure 1). The solution file contains manifest.xsf, which lists the other files the solution requires: template.xml (an empty form document), a ViewName.xsl transform for each form view, and a schema.xsd file for the data source. For data-bound forms, schema.xsd imports schema1.xsd for the data-entry fields and schema2.xsd for query fields. TemplateName.xsn also includes JScript or VBScript files, if form customization requires script. JScript is the default, and data-bound forms include an autogenerated internal.js for changing views. The manifest.xml file contains other form-related data, including an adoAdapter element that defines the connection and command strings for the data source. A File, Extract Form Files menu choice uncompresses the XSN file for viewing or editing individual files.
Start With Data Sources
The first step in designing data-bound InfoPath forms is to open InfoPath and click on the Design a Form task pane's New from Data Source link to specify the template and form data source with assistance from the Data Source Wizard. The underlying data source for the form is called the primary data source. Primary ADO and Web service data sources are read-write for query and data-entry operations. Primary ADO data sources, which are restricted to SQL Server and Access (Jet) databases, support multiple related tables; a Wizard dialog enables specifying the relation fields. A Sort Order dialog lets you add an ORDER BY clause for a maximum of three fields and select whether a query against the parent table returns more than one record. SQL Server data sources enable selection from tables, views, and Analysis Services cubes. For cubes or related tables, the Wizard specifies the OLE DB Data Shaping Service provider and uses shape syntax to generate the template's schema. Single table or query/view sources generate conventional SQL-92 SELECT statements.
Clicking Finish in the last Wizard dialog generates a query view with a queryFields section that contains textbox controls for all of the data source's fields, a New Record button to open a query view containing a Section with Controls element, and a Run Query button to interrogate the data source. Sections, Repeating Sections, and Repeating Tables are InfoPath-specific design elements. By default, the data entry view is empty; dragging the dataFields element to the data-entry view canvas populates the page with data-editing controls.
Secondary, read-only data sources populate dropdown or standard listboxes from static XML source documents, SQL SELECT statements that execute when users first open the form, or requests to Web services. Static XML documents deliver the best performance and minimize database server connections, but updating static XML documents is a manual design-mode operation (see the sidebar, "Tips for Designing Data-Bound InfoPath Forms").
Back to top
|