InfoPath is Dead, Long Live SharePoint Forms

In a statement, that we have all be expecting for some time, Microsoft announced that InfoPath 2013 would be the last release of the “desktop client”. The InfoPath Forms Services technology within Office 365 will be maintained and it will function until further notice. Product support will continue until 2023.

Microsoft InfoPath was released in 2003 as a client only electronic forms product. InfoPath Form Services, released in 2007, provided the ability to create web based electronic forms hosted within SharePoint. While a fantastic product, InfoPath Form Services is not a great fit for Office 365. SharePoint 2013 development is now CSOM, HTML 5 with mobile device support.

So what is the future? The article spells out pretty much what we have been hoping for, a unified electronic forms product across the whole of Office with a migration path from your existing InfoPath forms investment:

“In an effort to streamline our investments and deliver a more integrated Office forms user experience, we’re retiring InfoPath and investing in new forms technology across SharePoint, Access, and Word.”

“If you’re an InfoPath customer, we want to reassure you that we’re working on migration guidance in parallel as we’re building our next generation of forms technology”

“If you’re attending the SharePoint Conference in March, you can get a sneak peek of what we’re building in “InfoPath and SharePoint Forms Roadmap” session”

All in all a very positive and exciting statement.

SharePoint Online, InfoPath and the World of Tomorrow …

I have read a number of articles on the above topic, some good and some not so good. I will try and clear up some of the confusion:

What is Microsoft InfoPath?
Microsoft InfoPath 2013 is part of the current Microsoft Office Product set. It provides the ability to create, codeless, integrated enterprise forms within the InfoPath Filler client, within Outlook and on the web via InfoPath Form Services (part of the SharePoint 2013 Enterprise CAL).

Will InfoPath be in Office v Next?
To date Microsoft have not made any public announcements regarding the next version of Office. The official line from Microsoft is that "InfoPath is currently in the product".

Does SharePoint 2013 support InfoPath?
Yes.

The SharePoint 2013 on-premise experience is good with a number of enhancements over SharePoint 2010. The SharePoint Online experience is very limited.

Can I connect to SharePoint Web Services from InfoPath Forms within SharePoint Online ?
Not currently.

Loopback protection is enabled on the SharePoint Online environment and will block calls to SOAP and REST from InfoPath Form Services. http://support.microsoft.com/kb/2674193
What about external web service calls?

These are blocked by the Cross Site Domain Access security rule which is not currently configurable within the SharePoint Online Control Panel.

Should I use InfoPath 2013 ?
This question gets asked a lot and my answer is “maybe”.

If you are developing for SharePoint 2010 or upgrading to SharePoint 2013 on-premise then “Yes” if the solution fits.

Many ‘experts’ state that InfoPath should not be used on SharePoint 2013. As I understand it the message Microsoft is promoting is that if possible all new solutions should not contain server based user code e.g. No custom web parts, no event receivers, no SharePoint Web Services. The future is client side coding with JavaScript and CSOM, Web Apps and Azure.

It’s clear that the server based InfoPath Form Services component does not fit into this model - but a client side variant would…

My InfoPath Form Services 2013 Wish List

While I truly love the new interface for InfoPath 2013 I do have a little wish list which should only take a day or two to implement:

• Please support Managed Metadata (you do within the Document Information Panels)
• Please implement a native Spell Check
• Please provide actions for inserting and deleting rows via rules
• Please improve the submission validation UI
• Please support the inclusion of style sheets / current theme
• Please improve the support for tables to support background images

While you can work around most of the items above, it gets a lot harder when working with Office 365.

Put an end to NaN and other tips

When you are using InfoPath you will often come across fields being rendered as ‘NaN’ (Not a Number). This usually occurs when a repeating element does not exist.
I have seen a number of ‘solutions’ to this problem so I thought I would add my two penny worth:
If you convert the number to a string then you cannot get the ‘NaN’ error. Finally you may want to do something with the number so prefix it with a zero:

concat(‘0’,string(<element>))

The number always defaults to zero and you may use round, floor max with the warm feeling that NaN will no longer make an unwanted appearance.

... and what about another tip? The other day I was trying to put a validator on a multi-line textbox to restrict the number of characters, I have done this before but for the life of me I could not remember how I did it. Dutifully I added the regular expression which of course failed, after some puzzling I remembered you can simply use string-length(expression) > 255. Regular expressions in InfoPath should always be a last resort.

Give a bit of feedback

Ever had a InfoPath Form Services form with a simple Submit and Close mechanism but wanted to give the user that little bit more ? Wouldn’t be great if we could display a status message to the user ? Well you could create a separate form view to display a confirmation message or we could just display a SharePoint status message like the one below…

By using a custom link to launch the InfoPath form and including a query string within our source message we can trigger a status message within a content editor web part.

Just add a content editor web part to the page and add a little JavaScript magic:

   1:  <script type="text/javascript">

   2:   

   3:    var l = window.location.href;

   4:    l = l.replace('?','&');

   5:    var p = l.split('&');

   6:    

   7:    for(var i in p)

   8:      if (p[i].indexOf("status=") >= 0)

   9:      {

  10:        var values = p[i].split('=');      

  11:        var value = values[1];

  12:   

  13:        if (value=='ok')

  14:        {

  15:           ExecuteOrDelayUntilScriptLoaded(ShowStatusInfo, "sp.js");

  16:        }

  17:      }

  18:   

  19:     function ShowStatusInfo()

  20:     {

  21:        msg = SP.UI.Status.addStatus("Expense Form", "<img src='/_Layouts/Images/mewa_info.gif' align='absmiddle'> <font color='#AA0000'>Your expense claim was submitted successfully</font>", true);

  22:        SP.UI.Status.setStatusPriColor(msg, "yellow");

  23:     }

  24:   

  25:  </script>

 

 

Launch the page with a query string including &status=ok and hey presto you have a happy user.

Of course the close button will also display the same message but I leave that as an exercise for the reader…

User Conflict & InfoPath

Conflict? Users love InfoPath ! Well they don’t if their changes get overwritten by another user who opened and edited the form at the same time. What we need is some conflict resolution.
Conflict resolution comes in three flavours: None, Optimistic and Pessimistic:

• None, nothing, nada, zilch – this is the default conflict resolution that InfoPath Form Services provides out of the box. One user’s changes will simply overwrite another's.
  
• Optimistic resolution optimistically presumes that no-one would have the audacity to edit and change the form while another is editing it. Before saving the form it checks to ensure the form timestamps match and if they don’t breaks the bad news to user that it cannot save their changes. This is the default mechanism used by SharePoint lists.
  
• Pessimistic resolution takes no chances and locks the form as soon as the user opens it for edit. While this may sound like the obvious answer to our problem it does come with a few issues such as managing the locking. For example, imagine user A opens a form for editing and a lock is put in place. User A suddenly realises it is past 5pm, they close the lid on the laptop and leave work looking forward to their two week skiing holiday. Oops our form is now locked for two weeks. SharePoint implements this mechanism through Check In / Check Out.

So which mechanism should I choose ? If there is only one user editing the forms then no conflict resolution is required. If the form is not substantial or is rarely updated then optimistic should be sufficient. Large or heavily edited forms should take the pessimistic route.

Implementing Optimistic Locking within InfoPath

This is relatively straightforward create a SharePoint library data connection to retrieve the current item’s metadata (include data for the active form only) including the the modified date and who modified it. When the form is opened retrieve the information and store it within the Main data source. On submit query your data source and check the dates match, if they don’t break the news to the user, possibly on another view.

Pessimistic Locking

This is slightly more complicated.
Step 1: On opening the form we need to check that the form has not been checked out to another user, if available we can then present the user with an Edit button (we don’t want to check out the form just for a user wanting a quick look). If checked out to another user we can display a message to the user and disable or hide the edit button.
Step 2: With the form checked out the user can edit their form with confidence. The form could be automatically checked in on Submit or you could provide a Check In button so they can close the form and come back to it.
This can all be achieved without code thanks to the foresight of those chaps and chapesses that implemented the SharePoint web services. You will need to create three data connections:

• FormInfo : The same connection you created for optimistic locking to acquire the Checked Out To property and the name / title of the form.
  
• CheckOut : Add a data connection to the SOAP web service http://<site collection>/_vti_bin/lists.asmx?WSDL and select the CheckOutFile method. The method takes three parameters: PageUrl – the URL to the form; CheckOutToLocal – false; LastModified – this can be left blank.
  
• CheckIn : Add a data connection to the SOAP web service http://<site collection>/_vti_bin/lists.asmx?WSDL and select the CheckInFile method. The method takes three parameters: PageUrl – the URL to the form; Comment – Automatic Check Out; CheckInType – 1 (see link).
  

Add some rules

• Add a Form Load rule to query the FormInfo data connection and set the query field PageUrl for the CheckIn and Check Out data connections.
  
• Add a formatting rule to hide a section containing the checked out message if the FormInfo Checked Out To, Person count = 0 or the Checked Out To, Person, Account contains the current user.
  
• For the edit button we simply need to add an action to query the Check Out data connection.
  
• For the Submit or Check In button we add an action to query the Check In data connection.

That’s it… Well you may want to add a few more rules and potentially some security checks such as checking the SharePoint group the user belongs to (see this excellent article) or getting more information on the user using our old friend the userProfileService.

Note: Since SharePoint 2010 Service Pack 1 there may be issues with performing the above where Claims based security is enabled.

Filtering the InfoPath 2010 Multiple-Selection List Box

So you want to have a Multiple Selection List Box on a form that displays values from a secondary data-source but want to store the value ids within the main data source. No problem.

Now just the selected values need to be displayed. Just filter the main data source values with a lookup right – wrong! This is not compatible with InfoPath Form Services. In order to achieve this you must add the secondary data source as a repeating section. Add a calculated field within this for the display value with conditional formatting to only display the values that occur within the main data source. This works !?

To check that the ID is within the main data source: Count how many nodes exist within the main data source exist with the same ID as the one being displayed, if it is less than one then don’t display i.e.

count(xdXDocument:get-DOM()/my:myForm/my:MainList/my:mainItems[. = current()/d:ID]) < 1

Spell Check within InfoPath 2010 Browser Forms

One thing I have never understood is the lack of a spell check facility within InfoPath Form Services forms. SharePoint has a spell checking web service which can be viewed at “_vti_bin/SpellCheck.asmx” so why can this not be used ?

Well it can and here’s how:

Override a list form into an InfoPath form via the Customise form options:



Once saved select the Form Web Parts and edit the New Form as follows: Add a Content Editor Web Part to the top; edit the HTML and add the following:

   1:  <script language="javascript" src="/_layouts/1033/SpellCheckEntirePage.js?rev=zYQ05cOj5Dk74UkTZzEIRw%3D%3D" type="text/javascript"></script>

   2:  <script language="javascript" type="text/javascript">

   3:     function CheckSpelling()

   4:     {

   5:        SpellCheckEntirePage('/_vti_bin/SpellCheck.asmx', '/_layouts/SpellChecker.aspx');      

   6:     }

   7:  </script>

   8:   

   9:  <a onclick="CheckSpelling();" href="javascript:"><img alt="Spell Check" src="_layouts/1033/images/RTE2SPCHK.GIF" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px"/></a>

  10:   

The form spell check relies on the SpellCheckEntirePage JavaScript file so this must first be included. All that is left to do is call it.

Save and close the page and now should end up with something that looks as follows:



Press the spell check button and the form is spell checked. Should you not want to spell check a specific field then you will need to exclude the controls first by setting the attribute excludeFromSpellCheck to true.

It would be nice to package this into a feature for the Ribbon but I will leave this as an exercise for the reader.

Microsoft InfoPath : Electronic Forms for the Business

I’ve been using InfoPath since 2004 and am continually amazed at how many businesses have never heard of it, or have it but have never considered using it. The thing is, you have probably used it without knowing it; have you ever completed a Document Information Panel in Word or a workflow form in SharePoint?

Microsoft InfoPath is part of the Microsoft Office family, providing a facility to design, distribute and complete electronic forms within your business. The current iteration of Office (Office 2010 Professional Plus) offers InfoPath as two products: InfoPath Designer 2010 and InfoPath Filler 2010.

Why migrate your company forms from Word and Excel format to InfoPath ?

• InfoPath forms can be published on the desktop, via Email or to the Intranet, Extranet or Internet.
• The forms can contain validation and business logic far above what can be achieved in Word and Excel without writing a line of code.
• Instances of the form are stored in XML format which can be easily integrated into your back office systems.

Publishing forms
InfoPath offers a design once use everywhere approach. Forms may be published to the network, via email / Outlook, Microsoft Forms Server, SharePoint 2007, SharePoint 2010, or Office 365.
Please note that for browser based completion of your forms within SharePoint a SharePoint Enterprise CAL will be required.

Client based Forms may be completed via the InfoPath Filler 2010 application or embedded within Office or a Windows forms application via the InfoPath form control. InfoPath is integrated into most Office applications in the form of the Document Information Panel. In Outlook 2007+ forms may may be viewed as emails.

Form Design
Forms may be designed within the InfoPath Designer application which provides the same Office user interface most users are familiar with. The designing of forms is aimed at the Knowledge worker and after a little training is fairly easy to get to grips with. Controls may be dragged into position where validation and business rules may be applied in an intuitive manner. The form can connect to multiple data-sources but is most at home connecting to web services.

InfoPath is designed around the XML paradigm. Instances of the form are stored as XML files which makes post processing very easy. The form templates are stored in XSN format. This is a CAB format file which contains a mixture of XSL files (for each form page view) and XML to define the form business logic and data-sources.

Managed code may be added to the forms via installing the optional VSTA (Visual Studio Tools for Applications) module from the Office CD/ISO. Personally I consider this a last option when designing InfoPath forms preferring instead to put this logic into reusable web services wherever possible.

Conclusion
If you have never looked at using InfoPath then I hope this brief introduction may inspire you to check it out. I must however finish with a word of warning, as with any product please plan carefully before deploying InfoPath to the Enterprise (I will try and cover this in a future post).