I’m a fan of InfoPath, but one barrier to entry has been the need to install the client software on user machines. We have one deployed solution that uses it (as part of ESB Guidance), but I wanted to explore the new Forms Services capability and see how I can use that to simplify BizTalk workflow use cases. In this post, I will examine a few common use cases, and demonstrate how I built them. The theme of the solution is the workflow around system support incident management.
To build this solution, first I needed schemas with which to generate the necessary InfoPath forms. So, within a new BizTalk project I created an “Incident” schema that looked like this:
Next, I have a “Survey” schema which the system owner will fill out after the incident has been successfully resolved.
After deploying the BizTalk solution, I went ahead and built a Web Service using the BizTalk Web Services Publishing Wizard so that incidents can be sent from InfoPath directly back to the running BizTalk workflow process.
Now, I can go ahead and build the necessary InfoPath forms. When designing the form, I’ve chosen to support both the InfoPath rich client AND, InfoPath Forms Services.
The form itself is fairly basic. It simply uses the XSD schema as a data source and allows for capture of incident data.
The first tricky part was getting the “Submit” action to work. On my first iteration building this, the rich client could submit to the web service just fine, but the Forms Services version kept giving me “an error occurred accessing the data source.” So, I had to learn all about UDC files and SharePoint data connections (thanks to the InfoPath Team Blog and Mark Bower‘s posts). So, my InfoPath form’s “submit action” now points to a SharePoint-managed data connection.
I then deployed this Incident form to my SharePoint server. When deploying forms in InfoPath 2007, you’ll see that Forms Services is mentioned.
Once deployed, I can go to the SharePoint document library’s Advanced Settings and set the form to open in the browser by default.
Next I built and deployed the “Survey” form which will be saved directly to the SharePoint library, so no extra submit action is needed.
On the BizTalk side, I built a simple workflow to demonstrate the following use cases:
- Emailing a link to a InfoPath form existing in SharePoint
- Receiving submitted feedback from InfoPath back into BizTalk
- Emailing a link to a “new” document for someone to fill out and save in SharePoint
To send the first email (asking the user to fill out the Incident Report), I need the correct URL to embed in the email message. Since I clearly need a Incident to refer to in this hyperlink, I first send the Incident to the SharePoint library. Because I dynamically set the file name, I have that value in my orchestration, and can use it for my email link. The link looks like:
The next hyperlink I need is for the “Survey” so that I can ask someone to create an entirely new form (that doesn’t already exist in the SharePoint document library). What does that look like?
Running the Scenario
Ok, so let’s kick this off and see how it looks. When I drop a file (to signify a system sending an incident report), I expect to see a message sent to SharePoint, AND, an email with a link to the same document. In my SharePoint library I see …
Notice that a form can be viewed either in the rich client or browser. In my email box I have a link to the web version of my Incident form. Clicking that link brings me to the form served up by InfoPath Forms Services.
Notice that I have both “save” and “submit” buttons available on the web form. The “submit” button will trigger the default submit action, which in my case, calls my BizTalk-generated web service.
Once the form submits, I then get a receipt (via my orchestration), and, a request to fill out a satisfaction survey. The email link creates a new empty form, that when saved, will appear in my SharePoint document library. Notice that I turned off “submit” in this form, since there is no submit action.
So, unlike with InfoPath 2003, InfoPath 2007 makes it very easy to design a form once, and have it surfaced up via the rich client, web browser, or mobile browser with no additional effort. From a BizTalk perspective, instead of emailing forms around and trying to keep track of them, we can now send links to web forms and be confident that any user, regardless of platform or software install, can participate in our workflow. This should make it much more compelling to use InfoPath + SharePoint in workflow solutions instead of doing custom development.