Yeah, I’m back to SharePoint and InfoPath after a period of disconnection. What caused it is that I’m currently working with the internal administration team to help them build and internal portal for self-services. You bet I’m telling them to use SharePoint for that, and one of the services is to automate the increasing number of administrative forms they have. Of course, those forms are best fit for InfoPath, but we have a number of challenges:
- Our IT policy delivers SharePoint out of the box, and don’t allow us to build code-based solutions –> we need to use whatever we have in SharePoint, and use design-only methods for custom solutions.
- Most of the administrative forms contain private information that we can’t just post to SharePoint. We either need to secure forms one-by-one, or we need to just avoid publishing forms to SharePoint at all. We have chosen the latter in our case.
With the above constraints, we needed to design forms (only design, no code pieces), and we need to find a way to publish tracking information only to a SharePoint list. Since we’re going to use this tracking mechanism in different forms – tens of them – I have chosen to go with an InfoPath template part for reusability. This blog post is all about that. I’m using SharePoint 2010 and InfoPath 2010, but the same can apply on InfoPath and SharePoint 2007.
Step 1: Create a SharePoint Custom List for Tracking Requests
I have installed SharePoint Foundation 2010 on my Windows 7. Thanks to the new support built in SharePoint 2010 for Windows client machines to make it easy for developers and designers to test out their work without the need for Windows Server installations or virtual machines. I have followed the MSDN article titled: Setting Up the Development Environment for SharePoint Server. In case you face issues, you can consult the following great blog: Common Microsoft SharePoint Server 2010 Installation Issues and Resolutions.
The custom list I have created contains simple columns to track different requests and allow comments as well:
Step 2: Design an InfoPath Template Part for Tracking Information
Starting InfoPath Designer 2010, you’ll be presented with different options. Click on Blank (InfoPath Filler) under Template Parts. I have chosen InfoPath Filler since I’m going to use this in client-only scenarios.
You’ll be presented with a blank design surface. Save this form template part and give it a name (preferably without spaces such as RequestTrackingTemplatePart.). It’s time that we build some data connections. I’m using the technique posted in this blog post: Submitting to a SharePoint List from the InfoPath team blog.
1. Define the fields that will be used as an interface for this template part:
In Fields task pane, rename the root to spListTracking instead of myFields, and add the following fields in the given order:
2. Define a data source to be used as a schema for submitting to a web service later on:
We’re going to use a Web Service to submit our tracking data to SharePoint. The Web Service is coming from /_vti_bin/Lists.asmx">/_vti_bin/Lists.asmx">http://<your server here>/_vti_bin/Lists.asmx, and the method we’re going to use is called UpdateListItems. The requirement for this method (as described in Lists.UpdateListItems Method (Lists)) is an XML document with a Batch node which instructs SharePoint to add a new item with the given properties. We’ll create this XML file. Open Notepad, or your favorite text editor, and type the following:
1: <?xml version="1.0" encoding="UTF-8"?>
2: <Batch OnError="Continue">
3: <Method ID="1" Cmd="New">
4: <Field Name="Title" DisplayName="Title"></Field>
5: <Field Name="RequestType" DisplayName="Request Type"></Field>
6: <Field Name="RequestStatus" DisplayName="Request Status"></Field>
7: <Field Name="RequestComments" DisplayName="Request Comments"></Field>
8: </Method>
9: </Batch>
The DisplayName is not required in our case, so you can freely remove it. Save the file and give it a name such as: Tracking – Add List Item Template.xml.
Go to InfoPath, and under choose Data –> From Other Sources –> From XML File.
Browse for your XML file, and continue with the wizard to include that as a resource in your template part. Allow automatically retrieving data from this data source. You’ll notice how that gets added as a secondary data source in your form as the following shows:
and by choosing it, you’ll see the XML schema reflected as fields inside the data source in InfoPath.
Now is the time to sync up our data source (XML) and the local fields (represented as the main data source of the form). You may wondering why would I need that, and the reason is that the above doesn’t allow you to talk to the specific fields (Title, Request Type, Request Status, and Request Comments) at design time. The schema shows only that there is a field and its content, and nothing else. We need to present a way for the user of out Template Part to see all fields at design time, in order for him to be able to assign some values.
3. Sync the Main fields with the XML fields of the Batch node:
Go to the Main data source, and choose the first field spItemRequestTitle. Right-click and choose “Rules …” to see the following task pane:
Click on New –> Action. Give your rule a meaningful name “Sync with title in XML”. There will be no condition in our case, and we need to choose from the action list “Set a field’s value”.
You’ll be presented with a dialog to set a field to a value:
Click to choose the field, and select Field from the ‘Tracking – Add List Item Template (Secondary)” and click OK.
Choose the spItemRequestTitle for the value. You’ll end up with a dot in this field, since you’re already in the title field context.
Do the same steps for the other fields: spItemRequestType, spItemRequestStatus, and spItemRequestComments. All will set the Field value from the XML template to their own!
We’re not finished yet, cause the above will sync the field “Field” to the values from the form fields. The dominant will be the last one… simply because we’re not choosing the right field index from the array of fields we’re expecting to have in in the XML template. Unfortunately, this cannot be done in design, and we need to tap into some of the source files of our InfoPath template part (as explained by the post above from the InfoPath team blog).
4. Modify the InfoPath rules to have indexed field assignment for the sync operation above
Let’s save the template part as source files in order to tap into the XML behind the scenes. Don’t worry it’s very simple to do. Go to File –> Publish –> Export Source Files:
Save that to a location you can refer to later. Open the manifest.xsf from the export location but in Notepad. Scroll down in the file in order to point out your rules that set the field values as follows:
1: <xsf:ruleSets>
2: <xsf:ruleSet name="ruleSet_2">
3: <xsf:rule caption="Sync Batch Field - Request Title" isEnabled="yes">
4: <xsf:assignmentAction targetField="xdXDocument:GetDOM("Tracking - Add List Item Template")/Batch/Method/Field" expression="."></xsf:assignmentAction>
5: </xsf:rule>
6: </xsf:ruleSet>
7: <xsf:ruleSet name="ruleSet_3">
8: <xsf:rule caption="Sync Batch Field - Request Type" isEnabled="yes">
9: <xsf:assignmentAction targetField="xdXDocument:GetDOM("Tracking - Add List Item Template")/Batch/Method/Field" expression="."></xsf:assignmentAction>
10: </xsf:rule>
11: </xsf:ruleSet>
12: <xsf:ruleSet name="ruleSet_4">
13: <xsf:rule caption="Sync Batch Field - Request Status" isEnabled="yes">
14: <xsf:assignmentAction targetField="xdXDocument:GetDOM("Tracking - Add List Item Template")/Batch/Method/Field" expression="."></xsf:assignmentAction>
15: </xsf:rule>
16: </xsf:ruleSet>
17: <xsf:ruleSet name="ruleSet_5">
18: <xsf:rule caption="Sync Batch Field - Request Comments" isEnabled="yes">
19: <xsf:assignmentAction targetField="xdXDocument:GetDOM("Tracking - Add List Item Template")/Batch/Method/Field" expression="."></xsf:assignmentAction>
20: </xsf:rule>
21: </xsf:ruleSet>
22: </xsf:ruleSets>
We’ll change the target fields in lines 4, 9, 14, and 19 to be indexed in the order of fields in our XML files:
Field[1] –> Title
Field[2] –> RequestType
Field[3] –> RequestStatus
Field[4] –> RequestComments
So line 4 will look like the following:
<xsf:assignmentAction targetField="xdXDocument:GetDOM("Tracking – Add List Item Template")/Batch/Method/Field[1]" expression="."></xsf:assignmentAction>
You can then apply the same to other fields, incrementing the index each time.
After the modifications, save the file and then open it in InfoPath by right-clicking and choosing design:
The form template part will open normally in design mode in InfoPath, and it’s time to save it back to one file (with the extension .xtp2). Open the saved file in design mode in InfoPath, and you’ll see your rules reflected by going to the Rules Inspector (under Data tab):
We’re now good to go for using this template part in our original form. I have just added some visual to the form template part to be able to see what’s happening. The final design of my template part is the following:
Step 3: Build an InfoPath Form and use the Template Part
It’s now time to use our template part inside our form, which happens this time to be a Business Card Request. I have launched InfoPath and designed a new form as it shows below:
We need to import our template part as a control, and this is very simple:
1. Click to expand the Controls on the Home tab
2. Select “Add or Remove Custom Controls”. Click Add on the dialog, and choose “Template Part”, and browse for your template part named “RequestTrackingTemplatePart.xtp2). And finish the wizard. The list of controls will have your template part at the bottom:
3. Click on the template part to add to your form design. You’ll notice how the visuals have been embedded, with the respective fields (spListTracking node and its children) and all rules.
I have chosen to add that to a different view, to separate the data entry from the submission and tracking data. The shot below shows exactly that:
Let’s switch back to the default view, and do a couple of things to be able to use the above template part for submitting to SharePoint list (named Tracking in my case, and is under http://aqahtani1/Lists/Tracking).
Step 4: Create submit data connections
We’re going to use two data connections for submission:
- Email Submit: which will submit the form to an email address
- Web Service Submit: which will submit the tracking information to a SharePoint list
The email submit is very simple, and the below show the dialog with proper To and Subject lines:
To create the web service submit, follow these steps:
1. Choose Data –> Submit Form –> To Other Locations –> To Web Service
2. Type the web service URL as follows: http://<your sharepoint server>/_vti_bin/Lists.asmx
3. Choose UpdateListItems from the list of methods
4. On the next page, assign the parameter “listName” to spListName
5. Assign the parameter “updates” to “Batch” node coming from “Tracking – Add List Item Template_RequestTrackingTemplatePart (Secondary)” data source. Make sure you choose to include “XML subtree, including selected element”
The dialog should like like the following:
You can now click Next, and give you new connection a name. I have chosen “Tracking Submit”.
We now have two submit connections in place, which we’ll use in the next step.
Step 5: Create Submit Rules
Double-click on the “submit” button in your form to bring the Controls Tools properties tab/panel:
In the Action selection, choose Rules and Custom Code, and click on “Manage Rules” on the far right to set the submit rules for this button.
The rules are going to be a number of “Set a field’s value” and “Submit” actions, fired only when the spItemRequestTitle is blank to avoid resubmitting by mistake. The following Rules Inspector screen shows a summary of that:
Notice how I’m building the request title from the form field values and concatenating that with the username and current date and time. I’m also assigning the request type and status to predefined strings that represent the choices in the SharePoint list columns. The comments field is more of a narrative.
These field submissions are followed by two submits: Email and Tracking, and then switching to the view for getting a summary on what has happened.
Notice the sync rules that are coming from our template part.
We’re done. We just need to test that in action and see the results.
Step 6: Preview the form and test your work
Click on Preview (or press F5) to run the form. Fill in the fields, and click submit to see your tracking view coming up with the assigned values.
And SharePoint will have a new entry as assigned in the form. See below:
The beauty is that I’m only holding tracking information in SharePoint, and the confidential information (if any) will only be submitted to the authoritive person in the administration team via email.
You can access the source files from this post here: http://algahtani.net/source/BusinessCardRequest.zip
Enjoy SharePoint and InfoPath!
Summary
In this post, we have learned how to track forms submitted by email using SharePoint Lists. We have implemented the tracking in a reusable template part, which we have used in our original form. We have learned how to deal with XML templates as resource files in InfoPath, and how to submit to Lists web service in SharePoint. Hopefully in the future, we’ll see how to get updated information from SharePoint and how to enable the admin team and the user to comment on their requests and the status of execution.
