It’s
easy to look at Microsoft’s InfoPath 2003 as a frivolous add-on to Office
2003 (specifically the Enterprise Edition, which includes InfoPath). It’s
hard to believe that something that seems an extra, dropped into a desktop
product suite like a basket of breadsticks at an Italian restaurant, can be a
powerful and flexible desktop application tool. Designed for the
not-particularly-technical, it does not appear at face value to be particularly
powerful—and therefore not particularly useful to the enterprise-minded
developer.

But InfoPath
will surprise you, not only with its considerable fundamental capabilities but
with the added utility and features beneath the surface. Below is a sampling of
powerful capabilities that don’t leap out at you from Microsoft’s marketing
material, but may persuade you of InfoPath’s considerable utility and
friendliness, not only to desktop applications, but as a bridge between
desktop, back-end systems and the Web.

10 things

1. InfoPath gives desktop app users ad hoc access to your core database
tables

InfoPath
is generally described as a tool for creating forms that can be used at the
desktop level to access SQL Server and Access data. So easy to use and flexible is
the InfoPath interface, however, that a desktop user can, with little technical
acumen, construct and fine-tune database queries of substantial complexity more
rapidly than you might imagine. This also makes InfoPath ideal for
desktop-level one-shot apps or temporary, multi-user apps requiring database
access.

2. XML can be a new storage medium for your desktop applications

InfoPath
is primarily built as a rapid means of accessing SQL Server and Access
databases. It moves data in and out of those sources, however, by means of XML, to which SQL Server and Access technology are
increasingly friendly. Have you ever considered that XML is a
well-structured and highly utilitarian data storage medium in and of
itself?

InfoPath
offers you the option of creating XML structures (or leveraging existing ones)
not only for data transport but for data storage. While this may seem
unconventional, and would often be inappropriate when working with existing,
large-scale sources or even local Access databases, it might prove particularly
convenient when storing data retrieved via ad hoc queries that will be used for
other purposes.

3. InfoPath 2003 + BizTalk 2004 = desktop enterprise

InfoPath’s
XML underpinnings are shared by Microsoft’s BizTalk Server 2004 application integration engine, making
enterprise-level applications accessible to desktop-level users. You can take
an instance of an InfoPath form and generate a BizTalk message type from it,
enabling you to pass forms data into BizTalk processes—and vice versa, creating
InfoPath forms from BizTalk message type schemas.

You
can also leverage BizTalk 2004’s Business Activity Monitor for real-time user notifications.
BizTalk’s Business Activity Monitor engine tracks business processes from start
to finish, which is powerful in itself—but BizTalk’s natural compatibility with
InfoPath allows you to conveniently plug process status information into Office
2003 tools (Excel, Access, etc.) or into an appropriate network distribution
chain (via Sharepoint Portal), where users can track
it, respond to it or redirect it as necessary.

4. InfoPath has built-in Web protocol support

XML
is, for all practical purposes, the native tongue of Web services.
Increasingly, Microsoft is buying into XML as its data transport method of
choice, in keeping with the over-arching philosophy of Web-centric system
design. No surprise, then, that InfoPath has Web protocol support embedded.

5. Swap out data sources

As
time passes, forms will change, and so will data sources. While it’s not
difficult to create new InfoPath forms when necessary, you can preserve
existing InfoPath development by extending forms, adding new data sources, or
swapping out old ones. With the InfoPath 2003 Toolkit for Visual Studio .NET, you get a set of utilities
that enables you to add ADO.NET data sets, and exchange XSD sources.

6. Extend database access for InfoPath solutions by deploying as ASP.NET
apps

InfoPath
typically resides on client machines where forms are used, but it’s possible to
offer the functionality of your InfoPath solutions as ASP.NET Web apps. You
lose some of the bells and whistles (such as rich-text formatting) but your
users can still edit the information in the form.

To
learn more about extending InfoPath with ASP.NET, check out MSDN.

7. Attach files to your form data

Office
2003 SP1 includes a File
Attachment control for InfoPath. This feature allows users to store
and retrieve files along with form data. An attached file can come from the
client machine, from a file share, or even from the Web. You can, as a
developer, manipulate this control via .NET Framework methods for encoding and
decoding.

8. Implement enhanced digital signature support for application security
(with SP1)

The
Office 2003 SP1 includes security updates for InfoPath. These include enhanced
digital signature support, giving you partial signing, co-signing, countersigning
and non-reputable signing options. Users of your forms can sign different parts
of a form. Users can also add notes when signing digitally, and users can roll
back to earlier incarnations of a form, based on the incidence of previous
signatures.

9. Employ managed code

The
InfoPath 2003 Toolkit for Visual Studio .NET lets you move easily between
InfoPath and Visual Studio. You can customize InfoPath development with VB.NET
or C#, meaning you can implement managed code solutions.

10. Use InfoPath in combination with VS.NET 2003 to implement business
logic in simple forms

Managed
code means you can go farther in implementing logic in your forms. The Toolkit,
presupposing the presence of VS.NET 2003, will insert InfoPath Projects into Visual Studio | New Project, and you’ll see an InfoPath form
icon under VB Projects and C# Projects (this icon represents the template for a
new InfoPath form).

VS.NET
will include your InfoPath forms, and the projects for developing them, in the
Solution Explorer window. If you’ve developed a form and wish to extend it via
managed code, your event-handling script code can be migrated into the VS.NET
project. The script code will be disabled, but the script files are referenced
in Solution Explorer: you can usually import your event-handling code into
managed-code event handlers with just a little tweaking.

You’ll
also have access to .NET classes for InfoPath COM object wrappers, enabling you
to use delegates for event handlers found in the form designer. This is really
convenient, permitting you to rapidly generate event handlers to encapsulate
logic. You can also bolster the security of InfoPath applications by embedding validation in event handlers. And with SP1, you
have open-ended group and field validation expressions; you can format forms
conditionally, modify the execution of an application based on user role, and
implement event-based business rules in the application.