Creating Custom Edit Forms with InfoPath in SharePoint 2010

Users have the ability to display and edit properties (known as metadata) for items in SharePoint document libraries and lists. This is standard functionality that comes with SharePoint, and SharePoint provides a standard form when displaying/edit an item.

SharePoint also provides the ability for power users or developers to customize these display/edit forms, using InfoPath. I am going to run through the steps to customize a SharePoint 2010 list, to create a custom display and edit form. I will be using InfoPath 2010 (along with Visual Studio 2010) to demonstrate how you can call a web service method from the custom InfoPath form.

 

Customizing a SharePoint 2010 List

When you create a list in SharePoint 2010, a standard display/edit form is used, so the first step in customizing a list to use your InfoPath form is to navigate to the SharePoint list, and click on the List tab in the ribbon. This will display ribbon items for the list, and you can click on the Customize Form button, in the Customize List section (Figure 1).

InfoPath_Figure1

Figure 1: Customize Form ribbon button for a SharePoint list

Once you do this, SharePoint creates a custom template with InfoPath 2010, based on the current columns defined for your list. You can use SharePoint Designer 2010 to verify whether a SharePoint list is using a customized list, as seen in Figure 2 (Figure 3 shows a list that does NOT have a customized InfoPath form):

InfoPath_Figure2

Figure 2: SharePoint list with a Customized InfoPath 2010 Form

InfoPath_Figure3

Figure 3: SharePoint list without a Customized InfoPath 2010 Form

When you click the Customize Form button in the ribbon, InfoPath 2010 Designer will open up with the customized form template created for you. At this point, you should make your modifications to the form (we will discuss this in more detail in the next section) and publish the form back to the SharePoint list. One thing to remember is that if you do not publish the form back to the list at this point (you will be prompted if you exit the form), SharePoint will not save the form template as a customized form, meaning your list will continue to use the default form.

For my example list (named TestCustomEditForm), I just published the custom InfoPath 2010 form template back to the list without making any modifications. Once this was completed, clicking on an item in the library displayed my custom form, as seen in Figures 4 and 5. The next section will discuss how to design more advanced changes to the customized form template.

InfoPath_Figure4

Figure 4: Customized View Item Screen for a SharePoint list

InfoPath_Figure5

Figure 5: Customized Edit Item Screen for a SharePoint list

 

Designing a Custom Display/Edit Form with InfoPath 2010

Once you have created a custom form template using InfoPath 2010, there are a lot of options available to you to design the form to your specifications. I am going to show you three things you can do to customize your form template: Adding a custom field that is a lookup to another SharePoint list, creating different views for the Display, Edit and New forms, and calling a web service method to retrieve data in a column when the form loads.

 

Adding Custom Fields

Adding a custom field is done in InfoPath 2010 Designer, and is very easy to do. Design your form template and in the lower right panel, there is an Actions section. You can click on the Add Field link, and a dialog to add your field information will be displayed (Figure 6).

InfoPath_Figure6

Figure 6: Adding a Custom Field

 

Enter your information about the field you are adding, and press OK to add the field. In my example, I am adding a Genre field, which is a lookup to a SharePoint list called Genre. Selecting a value of Lookup (Information in a SharePoint list) in the Data Type entry field will configure the field to be a lookup to a SharePoint list. I also selected Genre from the Get Information From field, which appears after you select the Lookup data type.

After you have entered all the information for your field and clicked OK, the field will appear at the bottom of the Fields section. You can now drag and drop the custom field onto the form design surface, and InfoPath will create the appropriate control for you. In my example, since the Genre field is a lookup to a SharePoint list, InfoPath creates a dropdown control when I drag and drop the field to the design surface (see Figure 7).

InfoPath_Figure7

Figure 7: Adding a Control for a Custom Field

 

You can now publish the modified form template to SharePoint, and you will see the Genre column added, as well as the field displayed when viewing/editing an item. Figures 8 and 9 show the list after these changes.

InfoPath_Figure8

Figure 8: Update SharePoint list with a Custom Column

InfoPath_Figure9

Figure 9: View Item with a Custom Column

 

Customizing Different Views

If you need to customize the different views (View/Edit/New Item) for a SharePoint list, you can accomplish that by creating different views in the form template in InfoPath. For my example, I created three (3) views in InfoPath: Display Item, Edit Item and New Item. The only difference between these views is the label for the Title field (of course, in a real-world scenario, your changes would be more extensive).

After these views are created, publish the form back to SharePoint, and in order to “wire up” the different views to the custom pages being used, you need to modify the web part in the different custom forms created (when you originally clicked Customize Form for the list). This is done by clicking on the Modify Form Web Parts (under the Customize List section in the ribbon) to display the different custom forms created (See Figure 10).

InfoPath_Figure10

Figure 10: Modifying Form Web Parts

 

The web part properties for each Item form (not the Default forms) needs to be modified to display the proper view. For example, Figure 11 shows the custom form for New Items. Under the Edit tab in the ribbon, select the current view to display that view in the page.

InfoPath_Figure11

Figure 11: Selecting the View for the Web Part

 

You also need to modify the web part properties for the web part on the page, as seen in Figure 12. Click on the Options tab in the ribbon (under Web Part Tools), and select the appropriate view you created (from InfoPath), under the Views dropdown. Apply the change and Stop Editing to finish with your changes.

 

InfoPath_Figure12

Figure 12: Modifying Web Part Properties for the Web Part

Once you make these changes for each of the views, you can see the changes when you display, edit or create a new item, as shown in Figures 13 and 14. Notice that SharePoint automatically makes the controls read only (or editable), depending on which view is being displayed.

InfoPath_Figure13

Figure 13: Customized View Item Form

InfoPath_Figure14

Figure 14: Customized Edit Item Form

 

Calling a Web Service Method from a Custom Form

Another powerful customization is the ability to call a custom web service method (to retrieve data for a field, for example). Before you can allow your custom InfoPath form to call a web service method, you need to verify the Cross-Domain Access for User Form Templates option is selected (Figure 15). This setting is found in Central Administration, under the Configure InfoPath Forms Services area (look in the General Application Settings section).

InfoPath_Figure15

Figure 15: Customized Edit Item Form

 

In order to call a web service method, a data connection must first be configured in the InfoPath form template. Make sure you select a connection to receive data, and select SOAP Web service in the Data Connection Wizard (Figures 16, 17).

InfoPath_Figure16

Figure 16: Receive Data Connection in Data Connection Wizard

InfoPath_Figure17

Figure 17: Data Source selection in Data Connection Wizard

To complete the data connection for your web service, enter the URL to the web service and select the web service method you are using. For my example, I’m using a method titled HelloWorld, which takes no input parameters and returns a simple string value.

Once you’ve created this connection, you need to convert it to use a data connection file (UDCX file). This is needed for security purposes, so that the user is not prompted for credentials. Click on the Convert to Connection File button in the Data Connections window (Figure 18) for your newly-created web service connection. A dialog will appear, prompting for a URL to the data connection file (Figure 19). Enter the path and file name to a data connection file that will be created when you click the OK button. For my example, I created a Data Connection library earlier named DataConnections, and used the URL to that library when creating the UDCX file.

 

InfoPath_Figure18

Figure 18: Converting a Data Connection to use a Connection File

InfoPath_Figure19

Figure 19: Convert Data Connection Dialog

 

At this point, your web service method is configured for use in the template, so the final step is to wire up the method to a field on the form. For my example, I created another string field (named HelloWorld) and added a text box on the design surface. I then set the default value of the text box to be the string returned from the HelloWorld web service method. This was done by entering the Formula Editor and clicking the Insert Field or Group button to allow selection of the return value from my web service method. Please make sure you select your web service method in the Fields dropdown (it will be marked as a Secondary Data Source), and that you select the appropriate field from the dataFields node in the schema (for my example, the string being returned is title HelloWorldResult, under the HelloWorldResponse node).

InfoPath_Figure20

Figure 20: Selecting Output from Web Service Method

Click OK to save the changes, save and republish the form template, and when you display/edit an item in the list, your web service method will be called and displayed on the dialog (Figure 21).

InfoPath_Figure21

Figure 21: Displaying Customized Form with a Web Service call

 

Moving a Customized Display/Edit Form to Another Environment

 

So far, we’ve discussed how to create a customized display/edit form, and I’ve shown you some powerful customizations you can make to your form. You may be wondering how to deploy this custom form from a development environment to a different environment (staging and/or production). I have found that the process is a bit different than you would expect.

Normally, when InfoPath form templates are created in a development environment, it’s a simple matter to “repoint” the publishing URL to your target environment and republish the template. Unfortunately, since this form template is going against a SharePoint list, we do not have access to repoint the publishing URL to a list in the target environment. Due to this limitation, the only way to get your custom form to a different environment is to save your customized list (which will include the form template and any content you might want to include) to a list template. You can then install this list template on your target environment, and create a list in that environment, based on the list template. The only other changes you would need to make is to repoint your web service method call (if you’re using one) to the web service in your target environment. You would do this by editing and republishing the InfoPath form template in your target environment.

Conclusion

Customizing the display/edit forms for SharePoint 2010 lists and document libraries is simple and provides a new level of customizing your SharePoint environment. Adding a bit of custom code can take this customization even further, if you need additional functionality not available with just SharePoint lists. I hope this article has helped you understand how to customize the display/edit forms using InfoPath 2010, and if you have any additions, I would love to hear about them.

 

How to Use BCS in SharePoint 2010

Introduction

Business Connectivity Services (BCS) in SharePoint 2010 is a robust and powerful technology that is part of SharePoint 2010. Microsoft has enhanced BCS with new features, services and tools in order to streamline the development of solutions with deep integration of external data. This article will run through the steps (end to end) to use BCS to use data in SharePoint coming from an AS/400 mainframe system.

Imagine the scenario where a company has line-of-business data stored in a mainframe (AS/400) system, and they want to utilize this data in their new SharePoint 2010 environment. BCS provides the mechanism for reuse of this data, thereby solving the problem of migrating data from the AS/400 system, maintenance of duplicate sets of data. We are going to use this scenario as our example for demonstrating what BCS can do for businesses.

There are a number of steps that will be followed to accomplish this, and are listed here:

  1. Database Configuration
  2. Creation of a Secure Store Application
  3. Setup of an External Content Type
  4. Creation of the External List in SharePoint

For this example, SQL Server 2008 R2 was used for the database server, and SharePoint 2010 Server Enterprise was used for the SharePoint site.

Database Configuration

Accessing the AS/400 data can be done through SQL Server via a linked server. Once a linked server is setup, a normal SQL database can be created to access this linked server through views. In order to create a linked server, follow these steps:

  1. Open SQL Server Management Studio and connect to the server you are working with
  2. In the Object Explorer, navigate to the “Server ObjectsàLinked Servers” node
  3. Right mouse click on “Linked Servers” and create a new linked server. You can use whatever name you choose (I am using the GBCUSTOMERDATA name).
  4. Follow the prompts to create the linked server. Make sure you use the correct remote login and password when appropriate.

Once complete, your linked server should look similar to this:

DB_LinkedServerSetup1_new

After you have setup your linked server, you can now create a separate SQL database and create views that reference the linked server. I have created a database called CustomerData that will be used throughout this article.

Creating a Secure Store Target Application

The next step is to create and configure a Secure Store Target Application. A Secure Store Target Application is used to control authentication to the external data system, in order that the end user in SharePoint is not continually prompted for authentication credentials. This component will be used when configuring an External Content Type.

Creating a Secure Store Target Application is done in Central Administration, under the Security area. Before a new Target Application can be created, a new encryption key must be created for that application. This is done by navigating to the Application Management section, and clicking on the Manage Service Applications link under Service Applications. This takes you to a list of the service applications. Scroll down to the Secure Store Service and click on it to access the area to create new secure store target applications. To generate a new key, click the Generate New Key icon in the ribbon. A dialog will appear, asking you to enter a passphrase. This passphrase is used if you need to edit the target application, so make sure you save this in a secure spot for reference (it is not saved anywhere in the system).

SecureStoreSetup2

SecureStoreSetup4

At this point, you are able to create a new target application for the secure store. Clicking on the New icon in the ribbon will begin this process.

The first screen allows you to enter information such as the Target Application ID, Display Name, Contact E-mail, Target Application Type, and whether the target application has a page that redirects users when they incorrectly enter credentials. Target Application Type should be set to Group, as this allows configuration of a group of users for the target application. Other selections here are Individual, Individual Ticket, Individual Restricted, Individual, Group Ticket, and Group Restricted.

SecureStoreSetup5

SecureStoreSetup6

Please note that here is where you name the target application, along with the Target Application Type, which should be selected as a Group type, so that we can map a group of users to this Secure Store Target Application. If you wish, you can select Individual as the Target Application Type, which will only allow individual users to be mapped to this Secure Store Target Application.  For the Target Application Page URL, I selected None, as I do not want any screen to prompt the user for credentials. You can select a default or custom page if you wish your users to be prompted for credentials.  Clicking on the Next button takes you to the following screen, which allows configuration of authentication fields.

SecureStoreSetup7

SecureStoreSetup8

Please note that you have a lot of freedom in what you configure here for fields names, but the default field names of Windows User Name and Windows Password should be selected. Clicking on the Next button takes you to the next screen, which allows selection of the administrator accounts for the target application, as well as the members who are mapped to the target application.

SecureStoreSetup9

Enter the administrative user(s) for Target Application Administrators, as these users will be the ones managing the Secure Store Target Application. For Members, you can enter any users or groups defined in your Active Directory environment. I selected All Authenticated Users, as I want any user who is authenticated in the AD domain. Click OK to complete the configuration of the Secure Store Target Application.

Now that your Secure Store Target Application is created and configured, you need to set the credentials that will be used. This will be the account that has access to the external data system.

SecureStoreSetup10

Selecting the Target Application and clicking on the Set button in the ribbon (under Credentials) will display the following dialog, allowing entry of the username and password you wish to use with this Secure Store Target Application.

SecureStoreSetup11

Setting the credentials for the target application (which you configured as a group type) is essential, as SharePoint uses these credentials when accessing the external system, instead of prompting the user for credentials each time the external system is accessed.

External Content Types

In order to provide access to external data in SharePoint, an entity called an External Content Type must be configured in SharePoint. An External Content Type (ECT) defines the connection information on where to access the external data, as well as the operations to perform when retrieving (or updating) the external data.

Creating an ECT is done with the Microsoft SharePoint Designer tool. There is a link on the left-hand side panel called External Content Types, that will display the information about the ECTs defined in the system.

ECTSetup1

Click on the External Content Type button in the ribbon, under the New section. This will create a new External Content Type, as seen below:

ECTSetup2

From here, you can configure the ECT, such as setting the name, the Data Source Type,  and creating the operations that the ECT performs. For this example, I set the name as CustomerData.

ECTSetup3

Notice that the new External Content Type does not have any operations defined initially. In order to do this, click on the Click here to discover external data sources and define operations link, under the External Content Type Operations area. This will display the following page, which allows you to define operations for the ECT.

ECTSetup4

Before operations can be created for the External Content Type, you must first create an external data source. Click on the Add Connection button to create a new external data source. You will be asked what type the new external data source is. For this example, I selected SQL Server, as I am connecting the linked server previously created in SQL Server.

ECTSetup5

Once you select the external data source, another dialog will be displayed, so you can enter the details of the data source. For a SQL Server data source, you are prompted to enter the database server name, database name, and how the ECT will connect to the database. We are connecting to this database with impersonated Windows identities, so select the Connect with Impersonated Windows Identity selection. Selecting this option will enable the Secure Store Application ID entry box, which allows you to specify what Secure Store Application is used (for credentials) when accessing the data source. For this example, I entered the NorthwindSecureStore secure store application.

ECTSetup6

When you are finished, pressing the OK button will cause the system to validate the data connection. You will be prompted to enter the administrator credentials for the Secure Store application (NorthwindSecureStore) as part of this validation. Enter the credentials you configured when you configured the secure store application.

ECTSetup7

Once the system is finished, you will be returned to the Operation Designer page for your ECT in SharePoint Designer. You will now notice that there is a data connection in the Data Source Explorer tab that corresponds to the connection you just created. For this example, the SQL connection is to the Northwind database. At this point, you are able to create operations for the external content type. To do this, expand the Northwind data connection and navigate to the table you wish to create operations for. I created Read List operations for the Customers database table by right mouse-clicking the Customers table, and selecting the New Read List Operation selection from the menu.

ECTSetup9

The system will now take you through the steps to create read list operations for the Customers database table. This includes naming the operations name, as well as creating any filters on the data that you need, and any return parameters. Clicking Next progresses you through the different dialog screens, and clicking Finish completes the creation process.

ECTSetup10

ECTSetup11

When configuring filter parameters, you select the Data Source element that the filter uses to filter the data.

ECTSetup12

Selecting return parameters specifies what columns from the data connection are returned when executing the operation. For this example, I want all the columns in the Customers database to be returned, so I selected all the columns available. I also want the CustomerID column to be mapped to the CustomerID column identifier in the database, so I check the Map to Identifier checkbox and select CustomerID, under the Identifier dropdown. You can also configure columns to be required or read-only, as appropriate.

ECTSetup13

Once you press Finish, you are returned to the Operation Designer, and you will notice that the operations you just created are listed under the External Content Type Operations section.

ECTSetup16

As a final step in creating the ECT, go back into Central Administration, and verify that the external content type has proper permissions configured. Under Service Applications, click on the Business Data Connectivity Service.

BDCPermissions1

Right-mouse click the CustomerData external content type and select Set Permissions.

BDCPermissions2

The dialog that is displayed shows what accounts have permissions for the external content type. Verify that the administrative account you configured previously has the proper permissions to the external content type. For this example, I gave the WINGTIP\Administrator account full permissions to the CustomerData external content type.

BDCPermissions3

SharePoint External List Configuration

The final step in configuring the SharePoint system for external data is to go into the SharePoint site and create SharePoint lists that access the external data. These lists can then be used in SharePoint, and will access the data from the external system (AS/400).

To create a list that accesses external data, go to All Site Content and create an External List. When prompted for an External Content Type, select the appropriate ECT that was configured previously.

SharePointSite2

SharePointSite3

At this point, you will be able to configure a new external list based off of the external content type. When you press the Create button, the system will create the external list.

SharePointSite4

SharePointSite5

Conclusion

Business Connectivity Services is a great way to leverage external data in SharePoint, but can be challenging to configure. I hope that this article helps in understanding what steps are needed to configure BCS, and provides a single reference for end-to-end configuration of accessing external data in SharePoint.

 

SharePoint 2010 Web Parts and CRM 2011

Recently I was asked to create a web part in SharePoint 2010 that would allow users to create and update entities in CRM 2011. There were some interesting challenges to overcome, so I thought I’d detail the process I went through, so others could benefit from my experience.

Initially, I thought this task would be easy, as the CRM 2011 SDK provides sample code that calls into the CRM 2011 web services to perform CRUD (Create, Read, Update or Delete) operations. However, I quickly discovered that the CRM 2011 SDK code requires references to the .NET Framework 4.0 DLLs, and since SharePoint 2010 web parts do not support .NET 4.0, I encountered compilation errors in my web part project.

Pic1

The solution I came up with was to create a “middle tier” WCF web service that would perform the calls to the CRM 2011 web services. This WCF web service can be created using the .NET Framework 4.0 to get past the compilation errors, and the ServiceContract can be defined with methods that mirror what is provided in the CRM 2011 web services.

I started by creating a new WCF Services project in Visual Studio 2010, selecting the WCF Service Application project template, and making sure I selected .NET 4.0 as the framework:

Pic2

Once the new project is created, I was able to define the ServiceContract for the web service, as shown below:

namespace CRM2011MiddlewareService 
{ 
   [ServiceContract] public interface IService1 
   { 
      [OperationContract] string GetMessage(); 
      [OperationContract] void AddCRMAccount(string strAccountName); 
      [OperationContract] void AddCRMCase(string strCaseName, string strAccountName); 
   } 
}
Figure 1: Code for ServiceContract

I also needed to add service references in the project to the CRM web services, as listed here:

http://<<server name>>/XRMDeployment/2011/Deployment.svc

http://<<server name>>/XRMServices/2011/Discovery.svc

http://<<server name>>/XRMServices/2011/Organization.svc

Pic3

 

Once this “middle tier” web service is published to IIS, it can be consumed by a typical web part project in Visual Studio 2010. I created this visual web part project and added a service reference to my “middle tier” web service, so I can call the methods that will create the CRM entity I am interested in creating.

namespace VisualWebPartProject1.VisualWebPart1 
{ 
   public partial class VisualWebPart1UserControl : UserControl 
   { 
      protected void Page_Load(object sender, EventArgs e) { } 
      protected void Button1_Click(object sender, EventArgs e) 
      { 
         Service1Client proxy = new Service1Client(); 
         string strCaseName = txtCaseName.Text; 
         proxy.AddCRMCase(strCaseName, ""); 
      } 
   } 
}
Figure 2: Code for Visual Web Part Project

 

From here, creating a simple visual web part for SharePoint 2010 is a piece of cake, and once it is deployed and activated in SharePoint, I was able to test it out to make sure it works properly.

 

In conclusion, creating a web part in SharePoint 2010 to consume methods from the CRM 2011 web service requires that you create a “middle tier” WCF web service to call the CRM 2011 web service. This “middle tier” web service can then be called by your web part in SharePoint 2010. My example here just scratches the surface of what the CRM 2011 web service provides, but shows the process I took to get a web part in SharePoint 2010 working with CRM 2011.