Everything You Need to Know about BDC: Part 8 of 8

Welcome back to Part 8 of our 8-part series on the Business Data Catalog (BDC). From the previous 7 installments, we have covered everything about BDC, from BDC architecture, ADF, BDC Web parts, BDC search and profile, to the BDC object model in details.  We also touched the surface of BDC actions in Part 4 and Part 5. As promised, we’ll dedicate this final article to actions. We’ll explain what the BDC actions are and what they can do for you.  We’ll then walk you through how to create custom actions and how to perform these actions by using custom Web parts and InfoPath forms. As you will soon learn, this is another power capability of BDC because it extends the ability to link content to Web sites.  This allows you to quickly create mashups that are item-specific so that you can take actions in context, such as write back to your LOB systems.

For your reference, these are our previous seven articles:

1. Part 1, BDC Purpose and technical architecture
2. Part 2, Application Definition File (ADF) and its Development
3. Part 3, Developing an ADF to Connect to Web Services
4. Part 4, Consuming Business Data through Web Parts and SharePoint Lists
5. Part 5, Implementing Enterprise Search with Business Data
6. Part 6, Integrating User Profiles with Business Data
7. Part 7, Working with the BDC Object Model

With that, let’s dive into BDC actions and start by asking what is an action.

What is an action?

An action is simply an operation upon a selected item. The operation can retrieve information about the selected item, or it can launch a program or Web page with the selected item as a parameter. The operation is a predefined URL link in each BDC item that enables you to act on the item, such as editing, or mapping it using Live Search as we demonstrated in Part 4.
An action is composed of a URL target where the action is to occur, and the matching parameters in the URL QueryString format. When we associate an action with an entity, we can pass parameters to that action based on the contents of one or more fields. For example, in the Live Search example in Part 4, we associate the Live Search page’s URL with a customer and provide the customer’s address to parameterize the search.

From the above, major characteristics of actions are as follows:

1. URL-based, parameter-driven
2. Actions on any entity and appear everywhere an entity goes
3. User can take action in ECB menu
4. Custom actions means custom code

A perfect example of action is the default View Profile action, as shown in Figure 1.

Figure 1  View Profile action in a Business Data Actions Web Part

Through a View Profile action we can navigate to the profile page of an entity. Clicking the View Profile action in a Business Data Actions Web Part as shown in Figure 1 above, as well as in a Business Data column, or in a Business Data List Web Part, lets us view the details of an item on that item’s profile page. Figure 2 shows that a Profile page that displays employee details.

Figure 2  A Profile page that displays employee details

What is a Profile page?

A profile page is automatically generated for each entity that has a SpecificFinder method after BDC imports an ADF file, a profile page can display all the information from a record in the BDC.  As we’ve seen in Figure 2, a profile page can display all the fields in a record for a specific employee. The default profile page contains a BDC Item Web Part for that entity.
If we put the profile page in Edit mode, there are actually two Web parts: a Business Data Item Builder and a Business Data Item that connect together. The Item Builder parses the querystring (http://win7:10001/ssp/admin/Content/Employee.aspx?EmployeeID=1) and passes the EmployeeID value to the Business Data Item, which then executes the SpecificFinder method and returns a record of Employee data.

Figure 3  Profile page components

Default Profile Page and default action

As we have seen from above section, the default action (View Profile) along with the default Profile page is automatically created when the entity has a SpecificFinder method.  To provide an ECB menu user experience, we can also add actions in a Business Data List Web part without using the Business Data Actions Web Part.

Defining an Action

There are three ways to add an action: 1) defining it in the ADF, 2) adding it in the BDC admin page after the ADF has been imported into BDC, and 3) through the BDC Object Model. Here we’re focus the first two.

Defining it in the ADF

To define an Action for the specified BDC entity, we’ll first locate the <Actions> section within the <Entities> and <Entity> hierarchy.

Figure 4  Actions is nested within the Entities/Entity in ADF

And insert the <action> portion like this one:

<Actions>
<Action Name=”Update Employee” Position=”1″ IsOpenedInNewWindow=”false” Url=”pages/editemployee.aspx?EmployeeID={0}” ImageUrl=”">
<ActionParameters>
<ActionParameter Name=”EmployeeID” Index=”0″ />
</ActionParameters>
</Action>

Adding an action in the BDC admin page

In the SSP administration page (View Application –> View Entity), the action is defined below and the URL that takes EmployeeID as a parameter: http://dpm:10001/ssp/admin/Content/Employee.aspx?EmployeeID={0}

Figure 5  Add an action the SSP Admin page

Custom Actions

We also can create custom actions for entities in BDC. Among other things, custom actions allow users to navigate to any custom page to manipulate business data.
Here are some scenarios that custom actions can do:

1. Parameterize custom search
2. Update employee in HR system
3. Customize profile page for an entity
4. Integrate BDC search into enterprise report center

We’ll be creating custom actions in the last part the article.

Figure 6 Enable View Profile action in a Business Data List Web part

This enables the ECB-style action, we will specify a Title property and add the following in the ADF:
<Entity EstimatedInstanceCount=”0″ Name=”Employee”>
<Properties>
<Property Name=”Title” Type=”System.String”>LastName</Property>
</Properties>
</Entity>

It specifies which column in the Business Data List/Related List Web part displays the Actions menu. It also specifies the name of the TypeDescriptor that corresponds to the column you want to display as the default column in Business Data lists.

In the Business Data Column scenario, we can also display the action menu and link the column to the business data profile in a Business Data list.

Figure 7  View Profile action in Business Data Column

This is default behavior OOB for a Business Data column.  When adding the column, just make sure the following two are checked:

• Display the actions menu
• Link this column to the profile page to

Figure 7  Enable the actions menu and profile page in Business Data list

These profile pages are used and being indexed by BDC Search. The following search results display the profile pages that contain the search keyword (s).  Notice in Figure 8 how a search for Great Lakes will display the profile pages for both this customer and their orders.

Figure 8  BDC Search Results in Profile Pages

Enhancing the Profile Page

By default, the profile page is hosted on the Shared Services Provider site collection where the BDC administration site is located. The search result (that is, the URL) links back to the Shared Services Administration site collection address that is not scalable when you extend the Web application. In real world, we may not want to give end users access to the SSP Admin site for security reason. A better practice is to create our own profile pages and host them in any site that is not part of the SSP site collection.
In this example, we’ve created a dashboard page in Report Center to replace the default Profile Page. The Report Center provides enterprise reporting capabilities that are scalable and centralized.  We can direct users to custom profile pages by updating the View Profile action.

Figure 9  Replace the default Profile Page with Custom Report Center

As an alternative, we can also replace the default the URL in Action element in ADF with the path to the Profile.aspx page:

<Actions>
<Action Position=”1″ IsOpenedInNewWindow=”false” Url=”http://reportcenter/Pages/Profile.aspx?EmployeeID={0}” ImageUrl=”/_layouts/1033/images/viewprof.gif” Name=”View Profile”>
<ActionParameters>
<ActionParameter Index=”0″ Name=”EmployeeID” />
</ActionParameters>
</Action>
</Actions>

An action to call the Profile.aspx page for each Employee ID has been defined. This action will be the default action provides in the search result.

Now let’s create Profile page to display information about the Employee entity in Report Center. (The Report Center is a site that provides a central location for business-intelligence-related information.)

1. In the http://reportcenter site, create a new Blank Web Part Page called “Profile.aspx”.
2. Add the following two web parts: Query String (URL) Filter Web Part and Report Viewer Web Part.
3. Configure the Query String (URL) Filter Web Part to pickup parameter “EmployeeID” from the URL query string.
4. Configure the Report Viewer Web Part to display the employee profile report called “Employee Profile”.
5. Connect the Query String (URL) Filter Web Part parameter to the SQL Server Reporting Services Report Viewer Web Part parameter “EmployeeID”.

Figure 10  SQL Server Reporting Services Report Viewer

Note: Please make sure you use this Web Part and not the OOB Report Viewer Web Part.

Test that the page is picking up the URL string parameter “EmployeeID” correctly by typing the following URL: http://reportcenter/Pages/Profile.aspx?EmployeeID=108

Figure 11  Custom Profile Page in Report Center

Creating Custom Actions

Creating custom actions requires custom code. The approach we take is to treat the BDC source simply as a data reader, and to build our CRUD (create/read/update/delete) logic in custom code. The BDC object model provides the means to retrieve collections, list items and enumerators, and we can use GenericInvoker to perform CRUD, which has been extensively covered in Part 7. We get the Web Parts to display data, and then we can use custom actions to create and update records by using Web parts and InfoPath Forms.

Creating Web Parts

We have created and deployed two Web Parts using the Object Model as shown below, with one inserting a record and one updating an existing record. (Special thanks to Lightning Tools! I’ve used BDC Meta Man to help with creating the Web parts.)

Figure 12  The two Custom Web Parts can be used to add and update employee records

Add these two actions in the SSP Admin page:

Figure 13  Adding actions in the SSP Admin page

Now you can access the two actions from the content menu in the Employee List:

Figure 14  Custom Actions Add Employee and Update Employee in the context menu

Figure 15  Add Employee Web Part

Figure 16  Update Employee Web Part

Creating InfoPath Form

MSDN has a great article titled Using Business Data Catalog Actions to Pass Parameters to InfoPath 2007 Browser Forms that walks you through this in detail.  So I’ve created our InfoPath Form and added the action using the Form Template path:
http://dpm/_layouts/FormServer.aspx?XsnLocation=http://dpm/FormServerTemplates/EmployeeUpdate.xsn&DefaultItemOpen=1&EmployeeID={0}&FirstName={1}&LastName={2}

Figure 17  Adding Custom Action that uses InfoPath Form

Figure 18  Update Employee in InfoPath Form

Conclusion

In this final article, we have focused on actions that users can take on the business entities. We can define actions in ADF or add it “after the fact”. We have also created custom actions using the BDC object model by using custom Web parts and InfoPath forms to enable CRUD (create/read/update/delete) operation support. Once added, actions can be performed from within the list, which becomes relatively transparent to the user where the data comes from. [The statement that the BDC data is read-only is not true anymore as we have just demonstrated.] As you have learned from our 8-part series, BDC enables user interaction in business intelligence, enterprise content management, collaboration and social features, and enterprise search.

Looking Forward to SharePoint Server 2010

BDC has evolved to what is now called BCS (business connectivity services) in SharePoint 2010. Even though we can use BDC to enable connectivity to external systems, it was difficult to create solutions because of the lack of a designer and it was not so simple to create a solution that enabled users to make changes and write that data back to the external store. BCS now enables you to integrate LOB data into SharePoint and Office with full CRUD support, tighter integration with Office client applications, and better tools for modeling business entities. BCS is all about connecting to external data. We look forward to sharing with you the exciting new features in BCS and what they can do for you in the near future. Until then, aloha!