InfoPath Dev

What is the current standard practice for deploying infopath forms to sharepoint. Say you have 50 to 100 infopath forms that vary from an active directory user creation form to an accounting expense report form. Do you deploy all the forms to their own form library? Or is it better to build a single repository for all forms?

Hi Khue,

Great question! SharePoint form libraries currently have performance limitations around 2000 forms. In addition, there are locking and promotion/reporting issues.

In terms of location, I would recommend using form libraries and creating links to the various forms, since you can promote properties to the views and views are the main value of SharePoint.

Patrick Halstead [InfoPath MVP]
InfoPathDev

Patrick,

I wanted to see if you had any two cents on this. What has been your opinion with the overall integration with SharePoint?

On top of the issues described above, if SharePoint becomes the repository for all of your forms with data, you will eventually run into the issue of getting that data back out for reporting. I have heard there are some tools out there that can help you with the retreival of this data in SharePoint. Would it be better for an InfoPath form to submit data directly to a database. If that is the case, where do you think SharePoint comes into the picture?

Hi Very Tender! ;)
Integration with SharePoint? My experience is that this is the way to go! I'm all for InfoPath and SharePoint integration (even with the limitations). In fact, we use InfoPath and SharePoint internally for our own business processes. In addition many of our big enterprise customers love SharePoint and InfoPath. Some value props of SharePoint are the ability to quickly define personal views of promoted data, collaborate on documents (check-in/check-out), and export properties to Excel for reporting.

I think that there is currently a gap with SharePoint and SQL Reporting. Even though SharePoint is actually implemented as SQL it doesn't have a rich relational DB model for the promoted properties, so you can't do "pivots" on data as easily as you can using Rosetta or some other reporting technology on top of SQL. However, you can still export the data. And you can still save your InfoPath forms in SQL and use SharePoint to view it. That's what we advocate. It involves writing webparts that must be IT sanctioned (i.e. installed), but we have solutions that use SharePoint on top of SQL and Web services in between.

For dashboards and quick views onto data, SharePoint is the cats meow. You still need the dashboard. We have developed tools that allow you to easily submit to SQL and we even have a dashboard tool that sits on top of it, but it's still not as "user configurable" as SharePoint's.

My bet is that SharePoint will get a lot better and solve some of the limitations and that there will be tools to bridge the gap between SharePoint and SQL so you can have your fancy pivot reporting and dashboards too.

Just my ten yen,

Patrick Halstead [InfoPath MVP]
InfoPathDev

Thanks. I appreciate that, I was not sure about the concerns around reporting.

Very Tender :-)

I've used the following approach to solve the SQL Reporting issue. InfoPath forms are submitted to a centralized web service, which performs the following checks:

• authenticates the submitting user


• checks against AD roles to ensure the user is authorized to submit


• validates the form based on the InfoPath schema


• validates the version information to see if it's allowable/supported

I use a custom Web Service extension to pass the SOAP payload (the InfoPath form) directly to the web service as a stream.

Once the form passes muster, it is either saved to a network share on our SAN, or else PUT to a SharePoint form or document library (depending on how that form was configured).

Then the form is passed to a separate SQL Server in a parameterized Stored Procedure. It's shredded using OpenXML into one or more transactional updates to the database. Of course, the database is updated with as little or as much of the InfoPath form data as desired.

The whole web service form post is treated as a single transaction. If the DB update fails, the form is deleted from the filesystem or SharePoint library. If the form cannot be saved to SharePoint or the filesystem, the DB update never happens. In either case, an error message is constructed and returned to the InfoPath client.

Authorized Users can browse the forms via SharePoint as usual, but the data contained within the forms is also available via SQL Server Reporting Services. The reports generated from that data also contain links to the original forms in SharePoint (or the filesystem).

Everything is configurable via custom configuration handlers in the Web Service so that each form can post to a different database, if needed.

The nice part is that this backend stuff is all hidden from the user. They open an InfoPath template from a SharePoint form library (or any other source, for that matter), they fill out the form, they submit it.

Regards,
Mike Sharp

Hi Mike,
Sweet solution you've got! This is very similar to what we did with the Database Accelerator. We even use an InfoPath form to configure the shredding. Unlike you we save the XML blob to the DB for data fidelity and use Web parts on SharePoint to view the data. We used to have SharePoint forms and the database but had synch issues when people circumvented the form / ASPX (ala Webdav or something).

Great job integrating InfoPath!

Patrick Halstead [InfoPath MVP]
InfoPathDev