Moving Beyond InfoPathSELECTING A BETTER E-FORMS TOOL

The Problem

So you have moved beyond the simple InfoPath forms into advanced tasks like:

Have repeating sections within forms with parent, child, even grandchild relationships

Want to report on InfoPath data using tools like SSRS

Want to leverage existing databases/web services for creating rich composite forms

What are the options?

Out-of-box approach - create form from SQL database

Customer Code - extend your existing form with custom code

Common Library (Rules) - use one set of rules for all forms

Business Connectivity Services - connect external data systems

Custom Web Service - middle-tier service-oriented architecture

Obvious Choice – Submit Data to SQL Server

SharePoint lists/libraries don't scale

Document permissions (ACLs) peter out at 5,000 items

View performance degredation after 10,000 items

SharePoint protocol (DAV) is slow

Limited reporting options

Export to Excel is two dimensional, Performance Point is hard to figure out

Relational databases (SQL) enable enterprise scenarios

Central data in one place

Easier to: backup, replicate, repurpose across sites, migrate, integrate with other systems, etc.

Reporting: build dynamic reports with Reporting Services

Performance: filtered queries are faster through SOAP

Out-of-box Database Template

Cons

Can't use with existing forms

Doesn't work in a browser (because of double hop authentication issue)

Limited data types - must conform to SQL data types

Schema change requires down time

Pros

Works out-of-box

Out-of-box Database Template

Out-of-box Templates

Custom Code in the Form

Cons Developer required and browser support requires admin deploy

Tightly coupled solution cannot be reused for other InfoPath templates

Brittle - breaks easily when database schema changes

Expensive - downtime when form datasource changes

Not Best Practice - SQL command cannot be parameterized

Security risk - however, developer can easily "escape" fields to prevent SQL injection

 

Pros Works with existing databases

Does not require deploying a web service

Common Library

Code required for advanced operations

Copying, sorting tables

Converting images to links

Integrating with lists

Submitting to a SQL database

Code will be hardcoded to schema of form

Writing code requires a developer

Maintaining separate DLLs is costly

What is a common library?

No developer required

Inject library in form template

Use commands via rules

Data-driven commands

Same library for all templates

Less cost to deploy and maintain

Business Connectivity Services

Cons

Authentication configuration required

Doesn't support repeating data

Doesn't support certain data types (for ex: bigint)

Stored procedures needed for query performance (to reduce result sets)

CRUD XML is complex

Adding fields requires lots of wizard time to reconfigure and doesn't update list editor (i.e. you have to create a new list)

Pros

Works with existing databases

Provides list-based editing for data

Custom Web Service Cons

Developer required

Parameters most likely hardcoded to form template

Web service must be deployed

Proliferation of Web services complicates migration

Pros

No code in form

No code in DB

Fast queries

Data-driven Web Service

All InfoPath templates use the same web service

All query shapes use the same web service

SQL to XML mapping defined in dynamic query string

Web methods take XML data to query SQL tables

User impersonation means SQL permissions can be defined to lock down users

qDabra Data-driven Web Service (DBXL)

Cons

Web service must be deployed to server

More work to configure with existing databases

Pros

Single web service supports all form templates

Works with existing forms

No code in form, no code in DB

Fast submits (and queries)

No downtime when schema changes

Less cost to deploy and maintain