AXForum  
Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.01.2009, 02:07   #1  
Blog bot is offline
Blog bot
Участник
 
25,631 / 848 (80) +++++++
Регистрация: 28.10.2006
Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0: Understanding Connections
Источник: http://blogs.msdn.com/crm/archive/20...nnections.aspx
==============

List Web Part supports three different types of connections that you can use to build various dashboards on a SharePoint portal. They are:
  1. Field to field connections
  2. Row to row connections
  3. Table to table connections
Let us walk through each of them to understand how they work, and what job they are best suited for. But before we dive into greater details, I’ll briefly put together the concept of connections in web parts for the uninitiated.

A web part connection is like a contract between two web parts to exchange some data. There are two parties in a connection: provider, and consumer. The provider sends the data as agreed in the contract to the consumer. The consumer can then use this data in whatever way it wants.

While one List Web Part provider can provide data to many consumers simultaneously, a List Web Part consumer can consume data only from a single connection at a given point of time. The same instance of List Web Part can act as both a provider and a consumer at the same time, thus enabling branched connections and cascaded connections. More on this in a bit after we go through each of the connection types List Web Part supports.

Field to Field connections:

The field to field type connections enable filtering based on relationships between two entities in CRM. For example, let’s consider Accounts and Orders in CRM. They are related by a one-to-many relationship on the attribute Customer. So if you enable a field-to-field connection between Account and Order List Web Part instances, with Account being provider, and Orders being consumer, then selecting a record in Account grid will show you all those records in Order, which have Customer as that selected account.

If there is more than one relationship between two entities, then the result in the consumer is an OR of all the relationship fields. For instance, let’s say, order has one more relationship with account on an attribute called Partner Customer. Then selecting an account record in the provider will return all those order records, which have the selected account either as Customer, or Partner Customer, or both.

List Web Part supports this connection for all the three types of relationships in CRM: One to Many, Many to One, and Many to Many.

How to create a field to field connection:
i. Add two List Web Part instances on a SharePoint web page.

ii. Open the web part page in Edit mode.

iii. Choose one of the web parts as provider, and other as consumer.

iv. Click the provider part’s connection menu. Select ‘Send Selected Field To’, and choose the consumer web part from the list that shows up.


Figure 1: Configuring field to field connections

That’s it! Your field to field connection is ready to be used.

Field to Field Connections with custom web parts

Custom web parts can connect to a List Web part using field to field connections, if they implement the following interface:

1: public interface IWebPartCrmData 2: { 3: /// 4: /// Schema name of the CRM entity 5: /// 6: string EntityLogicalName{ get; } 7:  8: /// 9: /// Display Name of the CRM entity 10: /// 11: string EntityDisplayName{ get; } 12:  13: /// 14: /// Schema name of the primary key of the CRM entity 15: /// 16: string PrimaryKeyLogicalName{ get; } 17:  18: /// 19: /// Display name of the primary key of the CRM entity 20: /// 21: string PrimaryKeyDisplayName{ get; } 22:  23: /// 24: /// Value of the Primary Key of a particular instance of CRM entity. 25: /// 26: string PrimaryKeyValue{ get; } 27:  28: /// 29: /// Value of the Primary Attribute of a particular instance of CRM entity. 30: /// 31: string PrimaryAttributeValue { get; } 32:  33: }

If your custom web part is a provider, then it needs to implement this interface. If it is a consumer, then its consumer method should consume an instance of this interface.How to write custom web parts is beyond the scope of this blog, but more details can be found here.

Row to Web Part Parameter Connections:

This type of connection enables one set of fields from provider web part to be mapped to another set of fields from the consumer web part. While configuring this connection between two List Web Parts, you need to perform a mapping between various columns shown in the provider grid to another set of columns in the consumer grid. The consumer then filters its results based on the data from provider.

Here's an example that'll help explain this. Suppose you want to reach out to all contacts in CRM who belong to the same city as yours, then this is how you'll do it:
i. Add two list Web Part instances on a SharePoint web page. Configure first for User Entity, and second for Contacts. User will act as provider and Contact will be the consumer. For our example scenario, you should configure both User and Contact with a view that has City in its column set.

ii. Open the web part page in Edit mode.

iii. Click the provider part’s connection menu. Select ‘Send Selected Row To’, and choose the consumer web part from the list that shows up.


Figure 2: Configuring row to web part parameter connections

iv. A Configure Connection webpage dialog shows up, which will let you map one or more columns from the provider to respective columns in the consumer. Please note that only those columns show up in the list, which are present on the grid. Map the City from User to Address1_City in Contact. Keep clicking Next until you reach Finish.



Figure 3: Configuring connection mappings

The connection has been configured. Now select yourself from the list of users shown in the User web part, and you should see only those contacts which have the same city as yours. Select any other user with a different city, and the results in contact web part should change to reflect the new city.

You can configure this connection so as to filter on a group of columns instead of a single one. Just map as many columns from the provider to respective consumer columns as shown in the transformer screen, and you should be good to go. The result shown is an AND of all columns. What this means is that if you apply a filter on City, and zip code, only those contacts which satisfy both the city AND zip code will be shown.

Also, if you map more than one column from the provider to the same consumer column, then consumer will filter results only on the last mapped column from provider.

This connection is really powerful as it enables you to filter data crossing the organization boundaries in CRM. You can connect List Web Parts from two different CRM organizations, or two different CRM Server deployments, and filter data. You can even connect and filter data from other LOB applications, if you have custom web parts built for them.



Row to Web Part Parameter Connections For Advanced Scenarios

While configuring Row to Web Part Parameter type of connection, you'll notice that there are some columns which appear twice on the Transformer screen. For example, for a Contact Web Part, you should be able to see two columns with respect to Parent Customer, namely Parent Customer and Parent Customer: Id.

And here's why: Every CRM column has a property called Attribute Type, which represents the nature of data a column is used to store. The Attribute Type could be a boolean, a picklist, an integer, a nvarchar, and so on and so forth. While some of these columns store their values in text format, others store them using IDs, and do a reference lookup when showing up in the text format.

Examples of the latter kind are Lookup Types, Booleans, Picklists , Integers(of type Time Zone, Duration, or Language), etc.

Let's get back to the previous example of Parent Customer, which is a lookup field from Account in Contact. In CRM, lookup fields are referenced using GUIDs, and while displaying, their display names are shown. So from a provider web part, if you map Parent Customer to some consumer attribute, the actual data passed will be its display value. For example, if the Parent Customer in a record is called Active Cycling, and behind the scenes, has an ID as {E6E82758-99BB-4717-8D46-BC6A848A3442}, then mapping Parent Customer from provider will send the value 'Active Cycling' and mapping Parent Customer: Id will send the value ' {E6E82758-99BB-4717-8D46-BC6A848A3442}' to the consumer.

The point to note here is that mapping IDs will make sense as long as the two web parts in the connection have been configured for the same CRM organization. Also, if we choose to map Parent Customer: Id, then the receiving field in the consumer should be of a type that accepts a GUID, i.e. in a mapping, the data type of the receiving field should be compatible with the data that provider is sending. In case, it is not, the consumer web part will show an appropriate error message, telling you that your field mappings are incorrect.

You should use ID fields to map, in case you are connecting two web parts configured for the same organization. This will give you a better performance, and accurate results.

You can still choose to map the Non-ID fields(example Potential Customer) even when in the same organization. But because you are mapping on display names now, then all the records with the same display name on the mapped attribute will be considered while applying filtering on the consumer.

Of course, Non-ID field mappings make sense when you are connecting across CRM organizations, or to other custom web parts, which do not understand CRM IDs.



Removing Row to Web Part Parameter Connections:

You can remove this connection by following the steps below:
i. Open the web part page in Edit mode.

ii. Click the provider part’s connection menu. Select ‘Send Selected Row To’, and choose the consumer web part from the list that shows up.

iii. The configure Connection web page dialog shows up as shown in the figure below:



     Figure 4: Removing row to web part parameter connection

iv. Click on Remove Connection.

Table to Table Connections:

List Web Part acts as a Table Provider, and you can connect it to any other web part that consumes the IWebPartTable interface. The provider sends the entire data displayed in the grid to the consumer, and the consumer is free to use it in whatever way it wants. Possible examples of consumers could be: A charting web part, that takes a view containing revenue, and customer cities, and then creates a city wise distribution of revenues.

Please note that List web Part by itself does not consume any table data.

Dashboard creation using connections:

Now that we know the various connection types supported by List Web Part, we can use them to build dashboards, which give you a 360⁰ view of you data. You can create cascaded connections, branched connections, and also combine various type of connections.

For example, you can create the following dashboard to take a look at all Opportunities and Orders associated with a particular account that belongs to a certain user:


Figure 5: CRM dashboard using List Web Part


Figure 6: CRM Dashboard

To accomplish this, create a Row to Row Connection between User and Account on the column Owner(present in both User and Account), with User being Provider, and Account being Consumer.

Next create a connection between Account and Order using Field to Field Connections, with Account being provider and Order being Consumer. Similarly, you can create a field to field connection between Account and Opportunity.

NOTE: While configuring the connections above, please ensure that you add web parts on the web page and configure connections in the same order in which data is flowing from provider to consumer. For example, in the above scenario, data flows from User -> Account -> Order, and User -> Account -> Opportunity.

Hence the order of steps here can be:
1. Add User web part

2. Add Account web part

3. Add Order web part

4. Add Opportunity web part

5. User to Account connection

6. Account to Order connection

7. Account to Opportunity connection

I believe you are pretty excited to try your own hands on connections by now, and hopefully, you have all the raw material to get started. Happy dashboarding!

Nimisha Saboo



Источник: http://blogs.msdn.com/crm/archive/20...nnections.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Microsoft Dynamics CRM Team Blog: Building Rich-Client Dashboards for Microsoft Dynamics CRM with Windows Presentation Foundation Blog bot Dynamics CRM: Blogs 1 31.03.2009 13:24
Microsoft Dynamics CRM Team Blog: List Web Part for Microsoft Dynamics CRM 4.0 Deployment Scenarios Blog bot Dynamics CRM: Blogs 0 30.01.2009 22:05
Microsoft Dynamics CRM Team Blog: Microsoft Dynamics CRM 4.0 Bookshelf Blog bot Dynamics CRM: Blogs 1 22.01.2009 04:46
Microsoft Dynamics CRM Team Blog: Trust for Delegation in List Web Part for Microsoft Dynamics CRM 4.0 Blog bot Dynamics CRM: Blogs 0 15.01.2009 03:13
Microsoft Dynamics CRM Team Blog: Announcing List Web Part for Microsoft Dynamics CRM 4.0 Blog bot Dynamics CRM: Blogs 0 18.12.2008 06:06
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:13.