Thursday, December 17, 2009

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















Monday, December 7, 2009

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