InfoPath is a versatile
data-collection tool designed to make the creation of forms within
SharePoint extremely easy, efficient, and connected to out-of-the-box or
custom workflows. And yet, for IT pros and even SharePoint developers,
InfoPath remains a mysterious application. Because SharePoint adoption
is steadily increasing, I want to pull back the veil to show you how you
can integrate InfoPath forms in your SharePoint environment without the
need for coding.
In “
Solve Common Business Problems with InfoPath and SharePoint,”
I discussed the benefits of combining InfoPath with SharePoint. In this
article, I'll dig a little deeper, showing you how to build a form from
the ground up, using InfoPath 2010 Beta 2 and SharePoint 2010 Beta 2.
As I walk through some examples, I'll also point out ways to enhance
certain components or functionality
with custom code.
See also, "
SharePoint 2010's Value for Admins."
Getting Your Feet Wet
First, you’ll want to use InfoPath 2010
to create your first form. I want to focus mostly on InfoPath, so I
won’t spend too much time on the SharePoint infrastructure; however,
I’ll cover some of the SharePoint 2010 requirements where necessary. To
get started, open InfoPath 2010 and click File, New from the top ribbon.
You should see an image similar to Figure 1.
Figure 1: Creating a new form
Select the SharePoint Form Library template, then choose
Design this Form
in the navigation pane. You’ll see a new form in the design window with
a basic-looking table from which to add labels and controls. To start,
we’ll create a lightweight expense report form to illustrate how quickly
you can begin to gather data into SharePoint.
Within the designer, you can select a
color scheme under the Page Design tab. Remove the unwanted rows and add
some quick labels to get the form to look bland and ready to have
controls added to it, as Figure 2 shows.
Figure 2: Ready for controls
Place your cursor in the table cell to
the right of the Date cell, and from within the Home tab select the
Controls menu item. Within this menu, select the DatePicker control. You
should see a new DatePicker control added to your design surface where
your cursor was placed, and a new XML element added to your Fields box
on the right, as you see in Figure 3. These fields represent the data
you’ll capture and their associated type. If you right-click the
DatePicker control and select Properties, you can set formatting rules
and supply a more readable name for the underlying data it represents.
As you add more controls, you’ll get a growing XML container file ready
to capture your form data in a standard format.
Figure 3: DatePicker control
When adding data elements and associated
controls, you should strongly consider giving your data the correct type
(e.g., numeric, text, date, Boolean) and applying specific formatting
and rules for these controls—anything from enforcing currency formatting
to complex functions such as using XPath to evaluate other data
elements to enable or disable controls based on the value of one or more
other controls within your form. Doing so can add significant options.
I’ve filled out the design surface with
some additional controls to show you what a basic expense report might
look like. InfoPath provides much more extensive options for additional
rules, formatting, and connectivity to additional data sources for
querying and for creating business logic within your form. In the case
of expense reports, you might want to query your SharePoint lists or SQL
Server databases to obtain employee department and manager information
automatically, mileage rates, per-diem amounts, and so on. This can
easily be included to make more dynamic and flexible forms. Figure 4
shows a rudimentary expense report form. (I added a repeating table with
some additional data collection to account for a varying number of
expense items that can be filled out by end-users.)
Figure 4: Rudimentary expense report form
Repeating tables are powerful within
InfoPath. They represent something that competing options don’t: easily
capturing any number of user-defined records at run time while still
maintaining all your rules, formatting, and functions. In other
applications, many designers use to collect data (e.g., Microsoft Excel,
Word, ASP.NET) creating a “add another item” for the user can be very
frustrating within a single form. Excel has difficulty with using
functions in named ranges when it doesn’t know how many rows it must
account for; ASP.NET forms must create the new row in code and then be
specifically built to manage the code to iterate over all the submitted
record. InfoPath manages this data very easily because it knows in
advance that there might be any number of rows within a group (XML
Nodes). Most of the rules and formatting are automatically applied to
each new row as it’s created and filled out.
Publish Your Expense Report
If you would like to examine your XML
container file, you can use the File menu in InfoPath and choose
Publish, Export Source Files. Doing so will export the InfoPath package
from an XSN file into native components.
If you open these files, you
can begin to make some sense of how InfoPath is packaged and designed.
Under the covers, it’s basically an XML schema definition, XML template,
an XSL stylesheet (used to create your display elements), and an
associated XSF file, which is a proprietary InfoPath file used to apply
the rules, datasource details, and other native functionality.
If you feel particularly daring, you can
make modifications to these files manually and repackage them into your
XSN file. If you ever want to venture into building InfoPath forms in
Visual Studio to add compiled code, this becomes very easy. Some of the
potential benefits include copying and pasting rules for faster and less
risky reuse, assigning property promotion to SharePoint via specific
Site Columns in advance, and understanding how rules and data sources
are applied. Although this is an advanced topic, it’s important to know
how the files are put together in case you ever need to crack them open.
With a basic Expense Report form built,
we’re now ready to publish and use it inside SharePoint 2010. The first
necessary action is to perform a design check to ensure that the form
we’ve built can properly function within InfoPath Form Services. These
services, native to SharePoint, can convert your InfoPath form into a
fully functional web page by simply publishing the form to SharePoint.
Select File, Info, Design Checker. In the Design Checker window, click
the
Change settings link at the bottom. Choose Web Browser Form
in the dropdown list, then type in the URL to the SharePoint site where
you wish to publish the form. Then, click OK. Select the
Verify on server check box, and click Refresh. A dialog box will inform you that the form is being checked against your server.
The Design Checker will be your friend as
you design larger and more complicated forms, up until your form gets
too big—at which point, it will abruptly cease to be your friend. It
will time out when trying to convert and evaluate your form to make sure
it can be properly converted to a web page. This was a major problem in
InfoPath 2007, and I’m hopeful that a fix is in sight. Even if the
checker times out, your form will still work in SharePoint. The best
option is to disable the Design Checker when it begins to time out. As
long as your forms aren’t very large, you’ll be told if you’re
attempting to use any InfoPath features that aren’t supported with web
forms.
The next step is to select File, Submit Options, and insert the path
to your document library where you want to store the filled-out forms in
SharePoint. In the File Name text box, you need to set something that
will enforce unique values to ensure that you don’t have duplicate file
names. There are many ways to do this, but for now I just used the date
of the report with some text:
concat("Expense Report - ", ReportDate).
Select Next, and choose a name for this data connection. This
represents one way to quickly submit data to SharePoint, but you might
find that you need to add submit buttons with more flexibility. For
example, a button can run some rules and analysis on the data before
allowing a submission.
The next step is to select File, Publish,
Publish form to a SharePoint Library. Insert the URL to your SharePoint list and select Next. On the next page, ensure that you select the
Enable this form to be filled out by using a browser check
box. Choose the Site Content Type radio button, and select Next. By
selecting this radio button, you’re telling InfoPath that you want this
form to be added as the template for a new SharePoint Content Type. On
the following screen, select
Create a new content type and select Next. Now, add a name and description for your new content type and select Next.
On the following page, you need to decide
where to place this template so that it can be used by the new Expense
Report content type. I usually like to put the template in a place where
it can’t be easily accessed. In this example, you can hide it in the
list’s Forms folder so that it will reside in your new form library but
will be tough to readily find. (Here’s where I placed mine:
http://2k8-sp2010-dev/Expense Reports/Forms/ExpenseReport.xsn.)
The following screen is where you’ll
promote local fields in your InfoPath form to SharePoint lists as
columns. Click the Add button on the upper list. In the
Select a Field or Group dialog box, select any fields in your form that you want to promote to SharePoint. In the
Site column group dropdown list, select
(None: Create a new site column).
Below that, create a name for your new SharePoint column. This screen
will enable SharePoint to automatically extract data from your submitted
forms to your SharePoint site columns with no additional effort. You
will see this in action when you submit your first form shortly.
Continue to add as many columns as you want. Figure 5 shows my test
form.
Figure 5: Sample test form
For a more robust and reusable solution,
you’ll want to create your required site columns in advance within
SharePoint. In that case, you can tell InfoPath to use them instead of
creating new ones when publishing your form from within InfoPath. This
becomes a powerful tool for collecting essential managed metadata from
external sources and using custom search options in SharePoint to create
a legitimate application around expense reporting or any other business
process you might need to automate.
Now, you can continue through the
remaining dialog boxes and publish your form. And you can browse to
SharePoint to test your form. When you navigate to your form library,
you must first disable the default form content type and add your new
Expense Report Form content type. To do so, navigate to Library Tools,
Library, Settings, Library Settings from within your Form Library. Click
Advanced Settings, and ensure that the
Allow management of content types? checkbox is selected. Then, navigate back to your Form Library Settings, and in the Content Types section, select
Add from existing site content types,
locate your new content type in the list box, and add it to your
library. Return to the previous page and in the Content Types section,
click
Change new button order and default content type and clear the Form box so that it doesn’t appear in the list of available content types for this library when adding items.
When you’re done with that, you can see
your form in action by returning to the library and selecting Library
Tools, Documents, New Document, Expense Report Form from the available
document types. You should see your form in your browser window, as you
see in Figure 6. (I’ve filled out some data to show what it can look
like.) At the top of your screen, you should be able to submit the form
and return to your SharePoint list.
Figure 6: Viewing the form in your browser
Workflow
Now that you have a working expense
report form, I’ll walk you through the process of creating a workflow to
allow submissions of expense reports to be approved by the accounting
department. You’ll use SharePoint Designer 2010 Beta 2 for this task.
Related: SharePoint Workflows
Open SharePoint Designer and choose to
open your site via the URL. After seeing your site information page,
select Workflows in the left navigation. You’ll see a list of workflows
that already exist in your site. SharePoint 2010 now supports modifying
the out-of-the-box workflows using SharePoint Designer 2010. In this
case, you’ll create a brand-new workflow for your expense reports. To
see some new features in SharePoint Designer 2010, select Reusable
Workflow from the ribbon menu. SharePoint Designer 2010 can now create
workflows that can be saved as templates and reused, or in this case
attached to your expense report content type. Figure 7 shows the Create
Reusable Workflow dialog box.
Figure 7: The Create Reusable Workflow dialog box
Select OK after you fill out the form.
SharePoint Designer will connect to your server and create the shell for
your new workflow. In the ribbon, select Insert, Action, Start Approval
Process. You’ll see your new action appear in Step 1. Click Step 1 and
rename it, for example, Expense Approval—something to help denote the
intention of the step. Now, click the underlined
these users.
In the Participants field, you can put the user or group that will be
assigned the approval task. In the Title field, you can click the
ellipses to build a string with some dynamic values. In this example, I
allowed for a duration of two days for the task. When you’re done, click
OK.
Now, you can save and click Publish in the ribbon. Navigate back to your
SharePoint site and to your Expense Report list. In the ribbon, click
Library Tools, Library, Library Settings, Expense Report Form (
content type), Workflow Settings, Add a Workflow. Select
Expense Report Form for the Content Type,
then select Expense Report Approval Workflow for your workflow
template, and give your workflow a unique name. The rest of the settings
can probably stay as defaults. I ran into what I believe to be a beta
problem that required me to click the Back button after selecting my
content type (in order to select my custom workflow). Remember that some
of these names might be different, depending on how you name your
workflow and what content type is selected. When you’re finished, click
OK. Your workflow is now ready to run. To test the workflow, create a
new expense report and select Workflows in the item’s context menu.
On the Start a New Workflow page, you can
select your custom workflow and click Start. Doing so should create an
approval task for your accounting user. This user will have the option
to approve, reject, reassign, and so on. Assuming he or she approves
your report, you’ll see an Approved link in the custom workflow column
in your expense report library. If you click on the link, you should see
a screen similar to Figure 8.
Figure 8: Approving the report
This screen contains a lot of
information, including any tasks created during this workflow, plus all
the history data logged by the workflow process. There are some errors
logged in my history because I didn’t get email correctly configured in
my test environment. You’ll also notice another new feature at the top
of the image: Visio Services. SharePoint Designer 2010 workflows can be
exported and imported via Visio to provide a more robust and familiar
design surface for workflow creation. These services automatically
created a flowchart to depict my custom workflow. You’ll see the
benefits of this feature as your workflows become more complex with
additional steps and business logic.
This is an example of the most basic
workflow. I don’t have enough space to go into more depth, but if you
look through the available actions for workflow steps, you’ll get an
idea of what’s available. You can also custom-build these actions in
Visual Studio and use them in SharePoint Designer. Workflows can make
decisions based on user input, look up data from the current item or
SharePoint lists, and span multiple users. They are capable of
significant complexity.
Related: Workflow Solution
Extremely Powerful
Although this is a quick and relatively
simple display of the technology, you can see how easy it is to build
custom forms with workflow, and you can get a sense of the additional
power and flexibility at your fingertips. Combining workflow, some
custom code behind the forms, robust rules, datasource connectivity, and
the ability to package and deploy forms for re-use across multiple
locations, InfoPath is an extremely powerful tool in conjunction with
SharePoint. I should also point out that all the form-development
functionality is similar to that of InfoPath 2007 and
Microsoft Office SharePoint Server 2007.
Although some of the screen layouts are different, everything we walked
through can also be built in the current version of these products.
Only the workflow components at the end have changed significantly in
the 2010 release.
