| Introduction SharePoint Portal Server lets different developers and organisations develop Web Parts that can communicate with each other. The SharePoint architecture supports standard Connection Interfaces for passing information among Web Parts at runtime. The connectable Web Part will act as a provider Web Part by providing information to another Web Part or as a consumer Web Part by consuming information from a provider Web Part. Two Web Parts supported by a connection interface can be connected by an end user with either Microsoft Office Front Page or an Internet browser. Connection Interface Details There are few a different connection interfaces that provide different behaviors. The difference is mainly found in the amount of information that can be passed from one to another. For example, one interface can support providing a single value to a consumer Web Part. There are other interfaces that support more than a single value. The connectable Web Part raises an interface event that executes an action in Web Parts connected to it. These connection interfaces act as pairs by either being a provider or consumer Web Part. An event from the provider will trigger an action in the consumer Web Part, and an event from the consumer Web Part will trigger an action in the provider Web Part. The following are some of the connection interface pairs and their functionality. Connection Interface Pair | Functionality | ICellProvider, ICellConsumer | Provide or consume a single value from one Web Part to
another. | IRowProvider, IRowConsumer | Provide or consume a single or multiple rows of values
from one Web Part to another. | IListProvider, IListConsumer | Provide or consume an entire list from one Web Part to
another. | IFilterProvider, IFilterConsumer | Provide or consume a filter value. |
Table 1 Connection interface pairs and their functionality There are more connection interfaces available from the SharePoint architecture. However, I am mainly looking at interfaces connected using an Internet browser. There are a few more interfaces that are supported by Microsoft Front Page. Web Parts can be connected only if they are compatible with each other. If Web Parts are not compatible, the Connection menu item in the Web Part will be disabled, and a tool tip will display the reason why it is disabled. 
Figure 1 - Connection menu item disable
Compatibility Rules The Web Part won't be able to connect to itself either directly or through a chain of connections. There are a few compatibility rules that SharePoint architecture follows when determining whether the Web Parts are compatible. The following are some of the interfaces that support the cross page connections. This means Web Parts in two different pages can communicate with each other. Source page Interface | Target page Interface | IRowProvider | IFilterConsumer | IFilterProvider | IFilterConsumer |
Table 2 Interfaces supporting cross page connection Web Parts can run on the client side, server side, or both. The connectable Web Part only can connect with other connectable Web Parts in the same location. This means both Web Parts should run either client side or server side. A client side Web Part won't be able to connect to a server side Web Part and vice versa. When the developer creates the Web Part, he can determine the number of connections supported by the Web Part. This is done when the interface is registered in the code. The connection number can be either one or unlimited. Connect Web Parts through an Internet Browser According to the SharePoint Portal Server 2003 Client section on Microsoft's SharePoint Portal Server 2003 System Requirements page, "To use the SharePoint Portal Server 2003 client, you need: Portal access: - Microsoft Internet Explorer 5.01, plus the latest service pack
- Internet Explorer 5.5, plus the latest service pack
- Internet Explorer 6, plus the latest service pack
- Internet Explorer 5.2 for Mac OS X, plus the latest service pack
- Netscape Navigator 6.2 or later
- Netscape Navigator 6.2 for Mac
- Netscape Navigator 6.2 for UNIX
Portal management - Internet Explorer 5.5, plus the latest service pack
- Internet Explorer 6, plus the latest service pack
The Web page that contains the Web Parts should be in design view to support the connection functionality; otherwise, the connecting Web Part option won't be available to the end user. To access the design view of a SharePoint Web page, navigate to the top right hand corner and select Modify My Page or Modify Shared Page depending on whether the end user is using personal or shared view. Then select Design this page option from the dropdown menu as displayed below. 
Figure 2 - Selecting design view
A right mark will indicate whether the page is in design view as displayed below. 
Figure 3 - The design view is selected
There are more options available in a Web Part menu when its holding page is in design view. The Web Parts "Connections" option only is available when the Web Part is displayed in design view. Connecting Web Part Exercise I am using an ICellProvider Web Part to display the functionality of a connectable Web Part. The Cell Provider Web Part contains a textbox where end users can enter a value and a button. When the Cell Provider Web Part is connected to another Web Part, the value entered to the textbox will be passed to the consumer Web Part. Article two in this series will focus on how to create Cell Provider Web Parts. The end users select the dropdown arrow at right hand corner of the Web Part when they are ready to connect the Web Part. End users should make sure that the page is in design view. The information about the Web Part will display as shown below, explaining the functionality of the Web Part. 
Figure 4 - Connection information about Cell Provider Web Part
The developer has the option to enter a meaningful description about the Web Part when developing it. It will display a list of Web Parts that are compatible to connect to the Web Part as displayed below. 
Figure 5 - "Cell Consumer Web Part" is available from the list.
Currently only one Web Part is indicated compatible with the Provider Web Part.
Simply clicking the "Cell Consumer Web Part" will connect the Cell Provider Web Part with "Cell Consumer Web Part". A right sign will indicate which Web Part is connected to what as displayed below. 
Figure 6 "Cell Consumer Web Part" is connected to "Cell Provider Web Part "Web Part
Article three in this series will focus on how to create ICellConsumer Web Parts. Figure 7 displays the connection between and ICellProvider and ICellConsumer Web Part. Figure 7 - The connectable Web Parts The value entered in the textbox at Cell Provider Web Part will get consumed by Cell Consumer Web Part. Disconnecting the Web Parts To remove the connection between two Web Parts, navigate to design view of the Web page and click the connected Web Part title. (The connected Web Part title will display with a right mark in front.). A message will display to confirm your action as displayed below: Figure 8 - Removing connection between Web Parts Web Services and Connectable Web Parts Web services are mainly developed to provide specific data to a consumer. The developer has full control overexposing the Web service. The connectable Web Parts provide the option to the end user. The connectable Web Part can stand alone as individual Web Parts providing their dedicated information and then connect them together to provide filtering of information. For example, there can be an employee list Web Part and employee details Web Part. Both of the Web Parts can stand alone providing information. If the end user wants to display the details of a selected employee, the end user has the option to connect the employee list Web Part to the employee detail Web Part. In this way, when the end user selects an employee from the employee list, the selected employee details will display in the details Web Part. If you develop a Web service to cater to the above scenario, the developer has full control of the end result. The functionality provided by the web service is not visible to the end user and the end user won't have knowledge or control to reuse the web service if they need to in the future. At the end of the day it's reliant on whether you want to create a dedicated web service or individual Web Parts that can stand alone and work together if needed. The biggest benefit Web Parts have over a Web service is the reusability and the option for the end user to have control of their environment. This is a very important aspect in a portal architecture where end users have control over what they see. Portals are mainly developed so that end users can gather information relevant to them and centralise it. End users having more control over their environment is better than depending on a developer in a portal environment. Conclusion The connectable Web Parts are similar to normal Web Parts. The only difference is they are inheriting from a connection interface class that provides capability to communicate with other Web Parts at run time, so they can act as service if needed. Articles two and three of this series will show how to develop connectable Web Parts using the ICellProvider and ICellConsumer interfaces. About the Author Gayan Peiris is a Senior Consultant for Unique World Pty Ltd (www.uniqueworld.net) in Canberra, Australia. He is a MCSD with MCAD, MCP, Bcom and MIT certifications. Gayan has designed and developed Microsoft Web and Windows solutions since 1999. His expertise lies in developing scalable, high-performance applications with Microsoft Enterprise Server Products in .NET technology .His core skills are ADO.NET, ASP.NET, C#, VB.NET, Web Services, XML, SharePoint Portals, DNA and SQL Server.
| 
