Have a REST with SharePoint Designer 2013 Workflow

SharePoint Designer 2013 provides a new set of actions including, finally, the ability to call REST services – sadly I find this feature truly exiting. It even works on SharePoint Online (within limits).

The brief example below will add a row to the MyBikes list. The status entries, log entries and emails can all be ignored.

The rest call will be an HTTP POST to the following method: https://<web>/sites/intranet/_api/web/lists/getbytitle('MyBikes')/items

Ensure that you check the REST URL first to ensure it is correct, running it through Fiddler and checking the JSON is very useful.

1. Fire up SharePoint Designer.
2. Create a site workflow.
3. Create the Dictionary for the Header, the Metadata and the Parameters (see below).

Figure 0 – The workflow.

Figure 1 – The header contains the Accept and Content-Type definitions set to application/json;odata=verbose.

Figure 2 – The metadata indicated the list specific call. Worth checking this with Fiddler.

Figure 3 – The parameters binds to the metadata and defined the columns to be updated.

Figure 4 – Construct the REST call, binding the parameters, and the header (via properties).

Publish. Navigate to Site Content and manually execute - Heh presto a new row is added to the list.

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…

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.

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).

Operation is not valid due to the current state of the object

When your perfectly good SharePoint web service or elevated delegate throws this error it could ruin your day. The cause of the error lies deep inside the SharePoint object model which uses the current SharePoint context assuming all is well with it. I have got around this issue in the past by temporarily wiping the HTTP context after which all is well:

   1:  HttpContext ctx = HttpContext.Current;

   2:  HttpContext.Current = null;

   3:   

   4:  try

   5:  {

   6:      // TODO:your code

   7:  }

   8:  finally

   9:  {

  10:      HttpContext.Current = ctx;

  11:  }

This has always worked for me although recently I spied another approach on Kristian Kjær blog which also works well; the choice is yours.