Deploy browser enabled InfoPath forms as SharePoint feature - InfoPath 2007 form and Nintex workflows 2007 - Part 2

InfoPath 2007 form and Nintex workflows 2007 Part 1 covered basics of integrating InfoPath forms with Nintex workflows using in-built Nintex webservices, creating Receive Data Connections, submit data connections, creating Form Load Rules and building complex InfoPath Role based Views.

InfoPath 2007 form and Nintex workflows 2007 - Part 2 covers on how to deploy browser enabled InfoPath forms as Content Types in your SharePoint List/Library.

For deployment, we need to follow the steps mentioned below:

a. Converting InfoPath Data Connections to DCL library in SharePoint.

b. Publishing InfoPath form to a SharePoint List/Library 

c. Creating a .wsp solution package for the InfoPath form and its code-behind

d. Creating a batch script that will deploy the InfoPath form on your Production site.

e. Ensuring the InfoPath form has been deployed as a feature

f.  Modify the DCL's in the production environment.

g. Associate the InfoPath Content Type with the Document/Forms Library

a. Convert all your InfoPath Data Connections into the Data Connections library (DCL) in SharePoint.
This is a very important step before deployment, because you need to modify these Data Connection URL's on the Production server. Suppose you have a Receive Data Connection from a SharePoint list in your InfoPath form, the List GUID and URL will be different for the Production environment, also your Submit data connection URL will be different for the Production environment. This is where DCL's come into picture.

Remember the web.config file in ASP.NET, where we store all our connection strings. Just before giving the msi build, we change the web.config connection settings to point to the correct production url without the need for re-compiling and re-building the project. Same applies to DCL, you cannot move ahead with your InfoPath form deployment without changing converting your existing InfoPath form data connections to a SharePoint DCL library.

NOTE: However, after deployment you have to change these DCLs in the production environment.

Snapshots below show how to convert your InfoPath form Data Connections to DCL's :

1. Create a new Data Connections Library in your Development environment:

2.. You can name it anything you want, for eg: DCL

3. DCL library just got created. This is the place where all your InfoPath Data Connections gets stored in the form of a .udcx file.

4. Go to your InfoPath Form Tools -> Data Connections, you will see all your data connections:

5. Select your InfoPath Data Connection and Click on the "Convert" button besides it. There are two options here: Relative to Site Collection and Centrally managed, choose Relative to Site Collection, because we will later export this site to production environment and there we need to get all these Data Connections.

Give an appropriate name to your data connection and Click on the Ok button

6.  Go to the DCL library, you will see the InfoPath connection appears herem check the status, it shows as Pending 

 7. Click on the Name Context menu, select Approve/Reject link

 8. Select the radio button Approved and click on Ok button.

 9. The DCL is now seperated from InfoPath form and has all the connection details.

 10. The Convert button against the converted Data Connection becomes disabled

11. Once the DCL is created, you cannot re-convert the same InfoPath Data Connection again, so inorder to modify the same you need to recreate the Data Connection and then click on Convert again. Therefore, to avoid rework, it is always advisable to create data connections after test your InfoPath forms thoroughly in your Development environment before moving to test/production.

NOTE: An important thing to remember is, that the DCL still holds the connection URLs for the development environment in the form of .udcx, we need to change them, when we deploy the site to Production environment, if we already know the Production URL, then we can change it here itself, but sometimes there are Receive Connections like Receive From SharePoint List/Library, XML data connection that have the List GUID too. Since we cannot predetermine the List GUID's for production, it is always advisable to modify these DCL's in the production environment. 

b. Publish your InfoPath forms to a SharePoint List/Library: Once all the Data Connections have been converted to the DCL library in SharePoint, we need to Publish the InfoPath form.

1. Build and Re-build your InfoPath code behind solution first

2. Open your Infopath form, Go to File -> Publish, see snapshot below

3. Follow the Steps in the Publishing Wizard, select first radio button i.e Publish to a SharePoint server and click on Next button

4. Enter your Site URL and click on Next button

5. You may get this error at first, do not worry, it is due to the service Event Notification, which abnormally stops the Publishing

6. Be sure to Stop the System Event Notification services, go to Start -> Run -> services.msc, select System Event Notification and stop the service.

7. Now click on the Ok button of your error message pop-up and click the Next button, do not change anything here, click on Next button again

8.  Enter your Publishing Location, this is the path where you will save your Published Form (this form will be used for Deployment to SharePoint), do not miss out to name your Published Form here, for eg: MyPublishedForm.xsn or the same name as your existing Form Template. Click on Next button

9. Promote the required InfoPath fields you want into the SharePoint, the promoted fields become a part of the Content Type that we associate in our Document Library/ Form Library, click on the Next button.

 

NOTE: You can even allow the InfoPath form fields to be editable in SharePoint, by selecting the checkbox

10. Click on the Publish button now.

11. After clicking on Publish button, you will see the following screen, click on Close to complete the publishing process.

c. Create an InfoPath solution package for deployment: We are now ready to create a package of the above browser enabled InfoPath form.

Install the famous WSP builder for Console application from here (Download WSPBuilder.exe version 0.9.9.0728 x86 (Console app)).

1. In your hard disk drive, under the folder of your choice lets say Deployment, simulate the 12 hive structure

i.e create the following folders: 12, Tempalte, Features, Your Feature Name Folder

2. Next Download the sample feature.xml and element.xml files from the FeatureFiles.zip, you need to modify them, I have kept the relevant placeholders, change the values in the placeholders specified. I have scoped my InfoPath feature at the Site level. Next copy and paste your Published InfoPath form.xsn and InfoPath Form.dll within the features folder

3. Next create a solution package for the feature, download the Create WSP batch file sample, all you have to do here modify values in the placeholders I have specified like creating a new GUID and modifying the WSP Name, you may also have to change the WSP Builder path.

Place the createwsp.bat file in the same folder you have your 12 hive structure created, see the snapshot:

4. Run the createwsp.bat and it creates the feature solution package as shown in the snapshot below:

d. Create a batch script to Install your InfoPath forms:  Download the InfoPathInstall.bat file batch file, this batch file will be used to Install the InfoPath form feature, change your InfoPath form .wsp name in the batch file, you may also have to change your stsadm path. See snapshot below:

Remember, this batch file and wsp package will be helpfull to you in case of Production deployment, where you do not have much access due to IT Policies and restrictions, you just need to give the .wsp and InfoPath Install.bat to the Server Administrators and they will do the needfull, only thing you may need to do is to manually Activate the feature via the interface.

I have deliberately not included the activate feature command, since you may undergo a lot of changes in the InfoPath form package and you may have to do multiple re-deployments as well. It created a lot of issues for me while I was upgrading the package and re-deploying as it was making the new version of Content Type and not updating the existing Content Type. But when i only use Retract, Delete, Add and Deploy solution, it updates the Content Type properly. So i stick with this method, you are free to experiment by adding Install Feature, Activate Feature etc in your batch scripts.

e. Ensuring the InfoPath form has been deployed as a feature: We assume that you are in your development environment and have completed the above mentioned steps, so deploying the .wsp created above is the only pending task now. Run the InfoPath Install.bat file you created above in order to install your InfoPath form as a feature

NOTE: 2 Additonal deployment steps for Production environment:

=========================================================================

In case you are ready to move your existing site collection and InfoPath forms into the Production environment, please follow the procedure mentioned below:

 Before running the InfoPath Install.bat file in your Production envrionment, please ensure that:

1. You have exported your development site collection using:

stsadm -o export -url "http://yourwebappname/sites/sitecollname" -filename "C:\Deployment\ITPurchaseBackUp.bak"

2. You have already created a Blank site collection in your production/deployment environment and ran the stsadm import command with the help of the exported .cmp

stsadm -o import -url "http://yourwebappname/sites/sitecollname" -filename "C:\Deployment\ITPurchaseBackUp.bak"

=========================================================================

Since the InfoPath feature is globally deployed, it is available as a feature in all the site collections in my web application. You can choose to scope it only respective to your site collection by modifying the InfoPath Install.bat file, I leave it upto you.

The next step is to check whether our Published InfoPath form has been deployed as a feature or not:

Go to your Site Settings -> Site Collection Features, find your feature and manually Activate it, see snapshot below:

The moment you activate this feature Content Type specific to this solution gets created, Go to Site Settings -> Site Content Types -> Choose Microsoft Office InfoPath from the Show Group Dropdown

f. Modify the DCL's in the Production environment: I believe you would have deployed your InfoPath Form solution wsp package and activated the feature in your respective Site Collection by now.

In case you are in your development environment, the DCLs will automatically get created in your DCL library when you Convert your InfoPath data connections. We already completed that step. Now we want to move this site to the Production environment.

I have specified the 2 additional steps for Production environment deployment in the previous step above., please follow that first.

Once you have imported your site, ensure that you activate your InfoPath form feature by following the steps mentioned in the previous point above.

Login as a user with Owners rights and go to your imported site collections DCL library, it will still have the connections referring to the Development environment. Now its time to change those connections by downloading the DCLs into your local disk, modifying and uploading the DCLs back to the library.

Let us follow the steps mentioned below:

a. Download the DCLs: Go to your Production site's DCL library, right click on the Type icon and click on Save Target As...for a specified Data Connection

b. Save your .udcx file as an XML type file so that it is available for editing, you can either Save it in your Desktop or any other drive for that matter.

c. Right Click the downloaded .udcx file, Open With Notepad and modify the ListID and WebUrl attributes, these attributes vary with the type of Data connection, so in case of a Submit Data Connection you wont see any ListID attribute, instead there will be a FolderName attribute that points to the Document/Form Library path where the form will be submitted to. Modifying your DCL's is nothing more than common sense, so everything is not covered in this post.

The example we will cover is that of a Receive Data Connection type.

d. Once modified with correct Production List GUIDS and Url, you need to upload the updated DCL back to the DCL library, see snapshots:

Go to your DCL library -> Upload button

Browse and attach the modified .udcx file

Click on Ok button, do not uncheck the checkbox.

 

Ensure that the name and title should be the same with proper casing as it appears in the DCL library, do not change the other attributes, click on the Ok button

 

Select the Approve/Reject the modified and uploaded .udcx file and set it status to Approved.

 

g. Associate the InfoPath Content Type with the Document/Forms Library:

1. Go to your Form/Document library where you want to use the InfoPath form content type, go to Document Library Settings

 2. Select Advanced settings

 

3. Select the Radio button : Allow Management of Content Types to Yes and select Display as a web page option in Opening browser-enabled documents

4. Go to Document Library settings again and Add the Microsoft Office InfoPath Content Type that we deployed using Add from existing content type option in the document library.

 

5. Next go to your Document Library and click on New option, the new InfoPath Content Type will be visible with an InfoPath icon besides it. See snapshot

 Your InfoPath form should open up fine, if it throws errors like Cannot connect to the Data Source, then be sure to check your .udcx files in DCL's again.

With this we complete the 2nd part series which covers correct way of deploying your InfoPath forms to the Production environment.

Stay tuned for Part 3 which will cover Nintex workflow deployment, I will share my workflow deployment scripts and share tricks and tips to deploy your Nintex workflows the correct way.

In case you face any issues implementing the same, drop in your comments, I will be glad to help you...

Lotus Notes to SharePoint Application Migration Drill Down Estimation template

There are 4 parts to a typical Notes to SharePoint migration project, they are:
a. User account migration
b. Data migration
c. Application migration
d.  Mail Box migration

Out of all the above parts, Application migration requires a huge amount of skill and effort specially when you rely on Visual Studio's Windows Workflow Foundation (WWF) for your workflow development, on the other hand if you have Nintex workflows your job becomes much more easier.

I am heavily into Application migration one because it is challenging and secondly it helps you understand the nature of the business processes that different companies follow.

Based on my day-to-day experiences with Application migration, I have prepared a Drill Down Application migration estimation template which captures all the key parameters that will help you develop a near perfect estimate.

Click here to download the Lotus Notes to SharePoint Application Migration Drill Down Estimation template

Once the estimation is in place, half the battle is won and success is close by. But overall success of a migration project also depends heavily on technical skills that your team posses, effective planning, resource mobilization, risk management and client communication.

I personally believe team members and tech leads need to be given good solid technical trainings before they actually start a migration project. Especially when you use some third party tool for Data migration like Quest Notes Migrator for SharePoint or Nintex workflows for Application migration, Microsoft InfoPath for business process forms. These tools have their own strengths and limitations, understanding both will help you play in a more safer zone and avoid conflicts and mismatch in the requirements, because lets face it, everything that you can do with Notes cannot be done in the same way in SharePoint and the vice versa. So a healthy relationship with the client and effective communication will help you save tons of hours of rework and change requests.

Do let me know, in case you have any comments or feedback on the template

Lotus Notes to SharePoint Migration Estimation template

My earlier blog post regarding estimating Notes to SharePoint migration project was a very basic method, in fact is was Work Breakdown Structure (WBS) in real-sense. It didn't capture all the parameters required to successfully estimate a notes to sharepoint migration project.

This time after a lot of analysis, I have come up with a new Estimation template. This template effectively captures all the key parameters required to estimate both Data migration and Application migration effectively and leaves little scope of missing out on critical things.

I have come up with the Application Quadrant approach where we analyze Lotus Notes applications based on the 4 Application quadrants. See the diagram below:

I hope it will benefit all.
Click here to download the Notes to SharePoint Migration estimation template

I frequently blog at www.sharepointinsights.com You can also follow me on Twitter: http://twitter.com/Mehul_Bhuva

Nintex My Workflow Tasks webpart for InfoPath forms

There is a problem with the OOTB Nintex My Workflow Tasks webpart. In the case of InfoPath forms, the Item column of the webpart, takes me to the Workflow Tasks List where I can directly edit my tasks as Approve or Reject bypassing my custom InfoPath Task form. This can be a problem, if my InfoPath task form has some other fields, that I want users to fill or if my custom form determines my next level of workflow.

In this case, I want my workflow application users to use my custom InfoPath form as their Task form and not want users to edit tasks directly.

Solution:
I created a custom page in the /_layouts directory based on Nintex provided ApproveReject.aspx, lets name it InfoPathApproveReject.aspx and removed the Task update actions like Approve/Reject radio buttons and Comments, here I only have a read only view of the Task item.
For the webpart to redirect users from My Workflow Tasks Webpart to my custom InfoPathApproveReject.aspx page, I used the following NWAdmin command:

Command Syntax:
NWAdmin.exe -o SetTaskForm -siteUrl teamsiteurl -contentType contenttypename -taskformUrl taskformurl [-formType Edit|View|All] [-updatechildren Yes|No]

Actual Usage:
a. Download the custom InfoPathApproveReject.aspx form from here or the link given below.

b.Paste this form under the following folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\NINTEXWORKFLOW

c. Then run the following NWAdmin command:
NWAdmin.exe -o SetTaskForm -siteUrl "http://nintex/sites/myteamsite" -contentType "Nintex Workflow Task" -taskformUrl "/sites/myteamsite/_layouts/InfoPathApproveReject.aspx" -formType View

So now when users click on the My Workflow Tasks Item column, my custom Task form opens up in the read only mode, now they can't update the task form directly without by-passing the InfoPath Task form.

This solves my problem, but What if my Site Collection contains a Nintex workflow bound to a standard SharePoint List form and another Nintex workflow bound to a Document Library/List with InfoPath form as
Content type.

What happens in this case?
Since, I have customized my Task Form URL to InfoPathApproveReject.aspx, it would redirect my standard SharePoint List workflow users to my custom page and does not allow them to use the OOTB ApproveReject.aspx task form. The above mentioned solution created another problem, we need a more generic solution, check the workaround for this problem in my new post.

Download: Click here to download the custom InfoPathApproveReject.aspx task form.

Feel free to share your comments and ask me in case of any doubts.

I frequently blog at www.sharepointinsights.com You can also follow me on Twitter: http://twitter.com/Mehul_Bhuva

Delete older versions of SharePoint list/library

Just to give you a brief background of why we developed this utility.

Suppose you have accidentally turned on the versioning feature in your document library and you are migrating data from Lotus Notes to SharePoint using any third party utility like Quest Notes migrator for SharePoint and assume you had to re-run the utility again and again on the version enabled document library so as to migrate notes data with full fidelity. What happens then? Many versions of the same document/list item get created.

Assume there are 4000 records which got properly migrated into the versioned enabled document library, but each record created many versions of the same item, as a result average size of each item went to somewhere around 400-500 MB and some of them items were also 1 GB in size.

The site was also deployed into Production. Clients encountered performance issues while accessing items in the document library since the size of the document library had sky rocketed.
What do you do in this case? How do you delete the unnecessary versions and retain only the latest version of the document/list item?

My utility will just do that for you, Delete Item Versions utility will delete older versions of the document library items, while retaining the most recent version of the same. Most of the times, the site is already deployed and running into the production environment, hence , we needed a utility, which can access our production site remotely from any local workstation without touching or deploying anything on the production environment.

We have tested this utility thoroughly and it works like a charm. It uses SharePoint web services and users can run it from their workstations provided they have access to that particular SharePoint webapplication.
We also plan to enhance the features of this utility. Here is a snapshot of the same:

Snapshot of the Delete Item Versions utility

Click here to download the source code.

NOTE: You will have to change the webservice reference in the source code, Build the Project, Test the utility in your test environment and then use the DeleteItemVersions.exe for remotely deleting versions for your SharePoint List/Library.

Feel free to share your comments and ask me in case of any doubts.

I regularly post my SharePoint Insgihts at www.SharePointInsights.com

You can also follow me on Twitter: http://twitter.com/Mehul_Bhuva

What is Web 2.0?

Web 2.0 is not a technology, rather it is a terminology. It means Web as a platform. A platform that brings most of the common user tasks from desktop onto the network or the web.

To be more concise, Web 2.0 is “The power of desktop on the web”. Let me give specific examples:

a. Google Docs/Spreadsheets: Place to create and share online Word docs, Excel spreadsheets, PowerPoint presentations. You don’t need any software’s installed on your desktop, except for a decent web-browser like Firefox or IE. All through the power of Web.

b. Media sharing: YouTube and Meta Cafe are more popular in sharing media resources like Videos, users can now Share, Watch, Videos online, no need for a hard-disk to store videos, everything is on the web and at your finger tips. Slideshare helps users in sharing their presentations online and is very popular in the community.

c. Online File Storage: Want to save folders/files, we have BOX.NET (paid service) which gives 1GB of free space for Free users. Sky Drive is a online file share from Microsoft which gives 25GB of free space for your files/folders. You can create folders, upload files, delete them and share them too.

d. Micro-blogging is at its best these days, as we see Twitter and Yammer flourishing day by day, last month 45 million user visited Twitter. Most of the international celebrities, film stars, rock stars, individuals, businesses, communities etc have a Twitter account . Enterprises use Yammer which connects you to a specific pool of community.

e. Social Networking: Facebook, LinkedIn, Orkut are three powerful examples in this space. Some organizations scan candidates based on their LinkedIn profile and peer recommendations. These sites also promote collaboration by allowing users to create Groups and Communities.

f. RSS Feeds/Aggregator: Information from many sources is collaborated using popular aggregation services like FeedBurner. It converts your data into XML and generates a feed for your website/web-application. Other /applications can subscribe to these feeds using a RSS Reader software, which is mostly plugged-in into all modern browsers.

g. Mash-Ups: A popular mash-up service is iGoogle and PageFlakes. These sites consume web services and use the power of AJAX to make user experience more seamless and less obstructive. There are little context switches as users get to see everything in one window, a typical iGoogle page can have the Weather report, Email Inbox view, Stock ticker, Digital, News & headlines, Feeds from other websites, Game widgets etc. An icing to the cake is that these services are completely personalized per user.

h. Blogs/Wikis: Popular services like Blogger, WordPress allows users to create, maintain and promote their own blogsites. Non-techie users can create blogsites in a flash and start publishing their posts. Wikipedia allows user to manage information on specific topics.

i. Social Bookmarking: Popular social bookmarking sites like Delicious, NewsGator etc manage user bookmarks and promote sharing and collaboration.

j. Maps & Directions: Google Maps is the best example, users can get directions, exact locations, distance etc all via Satellite imagery.

k. Online Shopping, E-Commerce Applications: Most popular in this category are Amazon, e-Bay etc. They track user purchases and manage user preferences too. Online Air ticket booking systems, Railway reservation systems, Payment gateways like PayPal etc are all examples of the Web 2.0.

The applications mentioned above have gradually changed the face of the Internet and how we consume services. All the applications mentioned above are examples of Rich Internet Applications and leverage Web 2.0.

We are gradually moving into Cloud Computing with Google Chrome O/S, Microsoft Azure etc. That will be a space to watch out for. It will be called as Web 3.0. May be i ll talk about Web 3.0 in some other post.

InfoPath 2007 form and Nintex workflows 2007 - Part 1

Integrating InfoPath 2007 form and Nintex workflows 2007 - Part 1 covers how InfoPath forms interact with Nintex workflow web services.

InfoPath 2007 form and Nintex workflows 2007 - Part 2 covers on how to deploy browser enabled InfoPath forms as Content Types in your SharePoint List/Library.

There are two important Nintex workflow web services which integrates InfoPath form with Nintex workflows, they are:
a. GetRunningWorkflowTasksForCurrentUser(string fileUrl)
b. ProcessTaskResponse(string comments, Outcome outcome, int spTaskId)

a. GetRunningWorkflowTasksForCurrentUser:

This webservice identifies nintex workflow task associated with the currently logged in user for a given List Item which the nintex workflow is bound.

It takes fileUrl as an input String parameter. fileUrl is the server relative url of the list item on which the nintex workflow is currently running.

This webservice helps you retrieve various data fields like SharePointTaskId, HumanWorkflowID, WorkflowName, Comments, WorkflowName, WorkflowInstanceId, TaskName, TaskType etc...

We will see the importance of the same in the Implementation Scenario section of this post.

b. ProcessTaskResponse:

As the name suggests, this web service completes the workflow tasks on behalf of the user.It does the job of completing tasks of the type: Approved, Rejected and Continue. You can imagine an Approval/Review task form. Input parameter comments accept Approvers/Reviewers multi-line comments in the form of a string, outcome is generally of the following pre-defined types either Approved or Rejected for the Approver or else Continue for the Reviewer and lastly spTaskId accepts the SharePointTaskId retrieved by querying the GetRunningWorkflowTasksForCurrentUser web service.

Implementation Scenario:

a. Design an InfoPath form: User fills an InfoPath Expense Report form as shown in Figure 1.1.

Sample Expense Report Infopath Form

Figure 1.1















































b. Submit Data Connection: The form has one Submit data connection which submits all the details of this form to a SharePoint document library, snapshots below show how to create a submit data connection in InfoPath:

i. Go to Tools -> Data Connections -> Click on the "Add " button and you will see the wizard shown below: Choose "Submit data" option and click on the "Next" button





















ii. Choose "To a document library on a SharePoint site" option and click on the "Next" button. Select to a document library option





















iii. Enter your Document library URL, File name (must be a unique file name) and Check mark "Allow overwrite if file exists" option and click on the "Next" button






























c. Receive Data Connections: The InfoPath form must compulsorily have two receive data connections that make calls to the Nintex web services namely:

GetRunningWorkflowTasksForCurrentUser and ProcessTaskResponse respectively. You may have other receive data connections in your InfoPath form, for eg: I may have another receive data connection to receive data from a SharePoint List/Library and show it as a dropdown in my InfoPath form.

Snapshots below show us how to create a Receive Data Connection of the type Web service.

i. Go to Tools -> Data Connections -> Click on the "Add " button and you will see the wizard shown below: Choose the "Receive data" option and click on the "Next" button





























ii. Choose the "Web service" option





























iii. Enter the correct URL as mentioned here, URL for root level site collection should be: http://nintex/_vti_bin/nintexworkflow/workflow.asmx?WSDL
 
for eg URL for a site collection with /sites as managed path should be: http://nintex/sites/sitecollectionname/_vti_bin/nintexworkflow/workflow.asmx?WSDL

If your site collection has also a sub site, then your URL should be http://nintex/sites/sitecollectionname/subsitename/_vti_bin/nintexworkflow/workflow.asmx?WSDL





























iv. Select the web service "GetRunningWorkflowTasksForCurrentUser and click on the "Next" button





























v. Click on the "Next" button





























vi. Click on the "Next" button (let the check box remain unchecked)





























vii. Uncheck the check box option " Automatically receive data when the form is opened"





























Similarly make a web service receive data connection for ProcessTaskResponse nintex web service as well.

d. InfoPath Form Options: We need to set the InfoPath form load options correctly. We need to configure Rules and Actions to ensure two different Views are shown for the Requestor and Approver. We also create a string field namely RequestStatus in InfoPath form, this field displays the Current Status of the Request in the read-only mode in the InfoPath form, this field is updated by our Nintex workflow to set the correct Request Status as per the flow of the workflow.

We also need to get the Task information for the current user who opens up the InfoPath form. Here is where our InfoPath webservice: GetRunningWorkflowTasksForCurrentUser comes into picture.

To set Form Options go to: Tools -> Form Options -> Rules -> Add a new Rule





































i. First we check whether the FileUrl is not blank condition, we need to create a string data source field in our InfoPath form for eg: FileUrl which gets updated by the Nintex workflow using the workflow activity "Set Item Value". Our nintex workflow sets the FileUrl to the current server relative url for the current item on which the workflow is running.

ii. We create a new Rule i.e Load Workflow Information, here we check whether FileUrl (data source field) is not blank for the Rule Condition to execute, see snapshot below
























ii. We then assign the value of FileUrl (local data field generated by the Nintex workflow) to, GetRunningWorkflowTasksForCurrentUser web service input parameter: fileUrl and then query the web service using the action "Query using a data connection" in InfoPath.

iv. This gets all the task related information for the current InfoPath form item on which the nintex workflow has been attached like SharePointTaskId, HumanWorkflowID, WorkflowName, Comments, WorkflowName, WorkflowInstanceId, TaskName, TaskType (i.e. Approval, Review, Collect Data) etc. We need the SharePointTaskId, as it will be used by the ProcessTaskResponse webservice. We also need to check whether task has been created for the user who is currently opening up the InfoPath form.

e. InfoPath Views: The InfoPath form is designed to handle multiple Form Views within the same form. This helps us seperate our Requestor forms and Approver forms.

Without much effort I can create two different Views one for the Requestor and another one for the Approver and depending on the workflow needs for a Reviewer too.

Hence, Views addresses the Role management aspect of a Business Process workflow application.

In order to create an InfoPath View -> Go to Design Tasks Pane on the right -> Views -> Add a New view

You can even copy and paste table/structure from the existing view and later change it as per your requirements.

NOTE: This new View will always refer to the same underlying XML schema/data source, InfoPath just creates a new XSLT per view and not the XML schema/data source.

f. Approvers View:

i. By now we assume that the above InfoPath Expense Report form has been duly filled in by the requestor and submitted for Approval. The workfllow has already started and it has created and updated the FileUrl (local field of the published InfoPath form).

ii. The workflow has also created a task for the Approver in the Workflow Tasks list. He has also received an email with the Item URL asking him to take some action on the request.

iii. So when Approver clicks on the Item URL sent to him via notification email, an InfoPath form opens up. Remember we have to setup predefined conditions on Form Load to Switch Views as per the Task Type and other conditions, see snapshot for Rules and Conditions on form load:































iv. The Approver gets to see the "Approvers View" after form loads and the above rules execute properly, see snapshot






The InfoPath Approval Task form above has a multi-line Comments field, Approve, Reject and Cancel buttons respectively.

g. Process Task Response:

i. The Approver fills in his comments and clicks of the "Approve" button, it is like completing the task assigned to him. But how does Nintex know of it? Here is where Nintex's second web service ProcessTaskResponse. plays a role in completing the task on behalf of the Approver.

ii. We need to configure some Rules and Actions on click of the Approve and Reject buttons, see snapshot below:

For Approve button:

























For Reject button:


























Here we set the ProcessTaskResponse webservice input parameters as follows:

1. spTaskId - SharePointTaskId (returned by the former webservice)

2. outcome - Approved (if approved) or Rejected (if Rejected) (you can have either Approved, Rejected, Continue as outcome)

3. comments - Approver Comments multi-line text field

Then finally we execute the Process Task Response using the InfoPath action "Query using a data connection"

In this way using the two Nintex Web services, we have succeeded in integrating InfoPath form with our Nintex workflow.


Important Information:
Submitted, RequestStatus and FileUrl are fields in the InfoPath form.

a. Submitted is an InfoPath form field and is set to false by default, then as the user clicks on Submit button, we set it to true and use it as a condition in the Form Load options. We configure Nintex workflow's "Wait Until" activity, as we do not want the workflow to start until Submitted value is True.

b. RequestStatus can be set either from Code Behind or Nintex Workflow’s Set Field Value activity.

c. FileUrl needs to be set in the Nintex workflow’s Set Field Value activity as: Current Item’s Server Relative Url.

This will be used as an Input parameter for the GetRunningWorkflowTasksForCurrentUser webservice. It fetches the task information like SharePointTaskId and TaskType for the current user who is trying to open up the InfoPath form. The same SharePoint TaskId will be used to complete his task, using the Process Task Response webservice.

We use it to determine the type of user and task assigned to him and switch Views respectively.

Part 2 covers the correct way of deploying InfoPath forms as Content Types and how to associate them to a particular list/library in SharePoint.

Feel free to share your comments and ask me in case of any doubts.

You can also follow me on Twitter: http://twitter.com/Mehul_Bhuva

I also blog my SharePoint Insights http://www.sharepointinsights.com/