Home Library Learn Downloads Support Community
Sign in | United States - English | |
This topic has not yet been rated - Rate this topic

Differences Between Using the .NET Assembly Connector and Writing a Custom Connector

SharePoint 2010

Published: May 2010

This topic describes when you should use the .NET Assembly Connector provided with Microsoft Business Connectivity Services (BCS) and when you should write a custom connector to connect to external systems not directly supported by Business Connectivity Services.

A custom connector is written to be agnostic of external content types that connect to a kind of external system (example, all databases or all Web services), whereas each .NET connectivity assembly is specific to an external content type. Also, a custom connector provides Administration user interface integration, but a .NET connectivity assembly does not.

When you use the .NET Assembly Connector instead of writing a custom connector, you do the following:

  1. Write code as Microsoft .NET Framework classes and compile the classes into a primary DLL and multiple dependent DLLs.

  2. Publish the DLLs into the Business Data Connectivity (BDC) service database.

  3. Use Microsoft SharePoint Designer to discover the .NET Connectivity Assembly and create a model.

  4. Map each entity to a class in the DLL, and map each BDC operation in that entity to a method inside that "Class".

At run time, when a user executes a BDC operation, the corresponding method in the primary DLL is executed.

When you write a custom connector instead of using the .NET Assembly Connector, you do the following:

  1. Implement ISystemUtility, IConnectionManager, and ITypeReflector interfaces (only ISystemUtility is mandatory). Potentially, one can also override default connection manager and EntityInstance interfaces. In addition, implementing IAdministrableSystem provides Administration UI property management support and implementing ISystemPropertyValidator provides import time validation of LobSystem properties (not on the Microsoft Office client).

  2. Compile the code in step 1 into a DLL and place it in the global assembly cache on the server and clients.

  3. Author the model XML for the custom data source (SharePoint Designer 2010 does not support a model authoring experience for custom connectors).

  4. At run time when a user executes a BDC operation, this invokes the Execute method in the ISystemUtility class. Thus, the responsibility of executing the actual back-end method is given to the Execute method (as implemented by the custom connector).

The following table lists the benefits and disadvantages of using the .NET Assembly Connector versus a custom connector.

.NET Assembly Connector

Custom Connector

DLL that implements business logic is stored in the BDC store. Therefore, you do not have to place the DLL separately in the global assembly cache on client and server.

Binaries that implement a custom connector must be placed in the global assembly cache on the client and server.

The .NET Framework DLL that implements business logic is deployed to thick client computers via ClickOnce based Business Connectivity Services deployment.

A separate setup process is needed to install binaries that implement a custom connector.

No administrator privileges are required on the client computer for deployment.

Administrator privileges are required on the client computer to put the assembly in the global assembly cache.

Taking external lists offline will work seamlessly because the required assemblies are deployed through ClickOnce.

Taking external lists offline breaks if client setup does not put the assembly in the global assembly cache.

Provides a useful approach if business logic can be exposed through static APIs that rarely change.

Provides a useful approach when back-end interfaces frequently change (are dynamic).

Does not provide facility to override the default TypeReflector (Business Connectivity Services component that interprets types as .NET Framework types).

Provides facility to override the default TypeReflector and implement a custom TypeReflector.

One-to-one mapping of the BDC entity and the .NET Framework class is required. Thus, if one BDC entity must aggregate multiple classes, a wrapper must be written. This requires recompiling and redeployment of the .NET connectivity assembly.

There are no such restrictions.

DLL interfaces work like a back end for Business Connectivity Services, thus the actual the back end is completely abstracted from the Business Connectivity Services stack. Because the .NET Framework assembly DLL is loaded in process with Business Connectivity Services, there are no security requirements. It is always considered as "Passthrough".

In the custom connector approach, different kinds of security mechanisms offered by Business Connectivity Services can be used, including a custom security mechanism (Business Connectivity Services natively supports RevertToSelf, Passthrough, and Credentials and WindowsCredentials).

Business Connectivity Services has tooling support for the .NET Assembly Connector both in SharePoint Designer (discovery) and in Visual Studio 2010 (development and deployment of the DLL and the model).

No tooling support is provided for custom connectors.

Both the .NET Assembly Connector and custom connector are highly valuable Business Connectivity Services connectivity extensibility mechanisms that are offered by Business Connectivity Services.

The .NET Assembly Connector approach is recommended if the external system is static. Otherwise, for every change in the back end, you must make changes to the .NET connectivity assembly DLL. This, in turn, requires recompilation and redeployment of the assembly and the models.

If the back-end interfaces frequently change, the custom connector approach is recommended. By using this approach, only changes to the model are required.

Date

Description

Reason

May 2010

Initial publication

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
About static vs dynamic content, and data models
Since the BDC Model file is used to define what the external content types look like (fields, filters, etc), it is preferable not to change the models. Changes to the models may have an impact to all places that the model is used. $0Example: a list (promotions) includes a BDC/BCS column (customers), and perhaps pulls several related fields into the list as well (region, timezone, etc)... changes to the model (removing the 'region' field) can impact the list, and is therefore discouraged if possible.$0 $0$0 $0 $0The BDC Model file specifies WHERE to obtain the data from (SQL, WCF, assembly connector, or custom connector), and how the source data is mapped to the model (maybe the WCF returns a complicated object model, but the BDC model is flat).$0 $0$0 $0 $0The connector (SQL, WCF, custom .net assembly, or custom connector) dictates HOW it gets the data... (WCF uses HTTP, perhaps something custom would need to obtain data via telnet/SSH).$0 $0$0 $0 $0So going back to static vs dynamic content... an Assembly Connector includes the BDC model (which is assumed not to change)... a Custom Connector is written with the assumption that the model may change, and must then read the model to understand what must be queried.$0 $0$0 $0 $0In analogy form:$0 $0- SQL and WCF connectors are equal to Custom Connectors... given a model file which dictates the server, query, and results, the connector reads the model to build the query, and read the results. Any time you add another source (database, WCF service, etc), you need to reconsider the query and results; because of this, the model may (frequently does) change, and is considered to be dynamic$0 $0$0 $0 $0- A .Net Assembly Connector could be used to read from MS CRM; since the model of an Account never changes (always query the same way, always expect the same fields back), the query (select id, name from accounts) and results (id as integer, name as string) can be hard coded, which the model would match. In this case, adding another source (MS CRM server, assuming same version/etc) would always work with the same model/code; no change to the model; the model is static.$0
History
Writing a Custom Connector
The last statement says

"If the back-end interfaces frequently change, the custom connector approach is recommended. By using this approach, only changes to the model
are required."

When we include the proxy class that provides access to the repository, where BCS methods get implemented, it goes as part of the assembly.
We will have to recompile and redeploy the assembly even in this case.
How does it work with the change only in Model file?
History