BCS
data is surfaced in SharePoint via external content types. Regardless
of the mechanism used to connect to the data, whether it’s via an
out-of-the-box connector such as ADO.NET or WCF or via a connectivity
assembly or custom connector, the end result is a series of external
content types, each of which represents a single entity definition in
the source system. So, for example, in an underlying CRM system,
entities may be defined for Customer, Address, and Sales Order.
1. Associations
Naturally, in any data system, entities
have relationships—for example, a Customer entity may be related to a
Sales Order entity. BCS allows for the modeling of such relationships
using associations. It’s possible to create associations between any two external content types provided they have appropriate identifiers.
To take our CRM example a bit further, let’s say we
also had an ERP system with stock information on individual products.
The product stock level was defined in an entity called Product in the
ERP model. If the Sales Order entity in our CRM model contained a
ProductId field of type Int32 and the Product Entity in our ERP model
contained an identifier named ManufacturedProductId, also of type
Int32, it would be possible to create a relationship between these
entities regardless of the fact that they exist in separate systems.
2. Stereotypes
You may wonder how a system that’s capable of
retrieving data from practically any data source works. In general
programming terms, where an object must communicate with other objects
of unknown type, a common standard is adopted, either via the
implementation of a known interface or via inheritance, which requires
that all objects inherit from a common base class. The BDC service, the
engine behind BCS, employs a similar mechanism known as stereotyping.
You may also be wondering, why call it stereotyping?
Why not use an established term that makes more sense to developers?
There is a very good reason for this: The BDC service is all about
defining the connections between two systems, not physically making the
connections. None of the code in the BDC service actually sends or
receives data between A and B; instead, the BDC service simply
delegates the request to the appropriate endpoint. As a consequence,
there is nowhere to implement an interface and no abstract classes to
inherit from—it’s all about metadata. Stereotyping denotes a particular
endpoint and configuration as being appropriate for a particular
operation. For example, one important stereotype is SpecificFinder. A model may contain metadata that specifies that requests should be sent to the ReadRecordFromDataBase function in the MyBDCModel assembly whenever a SpecificFinder operation is executed.
The BDC Service defines a number of stereotypes
covering every data access operation supported by the platform. Not all
of these operations are commonly required, although the following
operations are used in most models to provide create, read, update,
delete, and query (CRUDQ) functionality:
| Operation | Description |
|---|
| Creator | Creates a new item in the external data store. |
| SpecificFinder | Returns
a single specific item from the underlying data store. The parameters
for this operation are defined by the identifiers that are associated
with the external content type. |
| Updater | Updates items in the external data store. |
| Deleter | Deletes items in the underlying data store. |
| Finder | Returns a list of items from the external data store usually based on some criteria. |
The following operations provide additional functionality for use in specific circumstances:
| Operation | Description |
|---|
| AccessChecker | Retrieves the permissions of the calling security principal for each of a collection of items. |
| AssociationNavigator | Retrieves a collection of items that are associated with a single specified item. |
| Scalar | Calls
a method on the external system that returns a single value (for
example, use a scalar operation to get the total sales made to date
from the external system). |
| Associator | Associates two specific items. |
| BinarySecurityDescriptorAccessor | Retrieves
a sequence of bytes from an external system. The byte sequence
describes a set of security principals and the associated permissions
of each security principal for a specified item. |
| BulkAssociatedIdEnumerator | Retrieves pairs of source and destination items for a specified association. |
| Operation | Description |
|---|
| BulkAssociationNavigator | Retrieves
destination items that are associated with multiple specified items for
each of the sources of the specified association. |
| BulkIdEnumerator | Retrieves
a set of instance IDs and a small subset of important fields of items
that are identified by the specified set of Instance IDs. |
| BulkSpecificFinder | Returns a set of instances of an entity, given a set of instance IDs. |
| ChangedIdEnumerator | Retrieves a collection of items that were modified in an external system after a specified time. |
| DeletedIdEnumerator | Retrieves a collection of items that were deleted from an external system after the specified time. |
| Disassociator | Removes an association between two specified items. |
| GenericInvoker | Performs a specific task in an external system. |
| IdEnumerator | Returns
a collection of identifiers for entities of a specific type. Works
similar to the Finder operation, except that IdEnumerator returns
identifiers only. |
| StreamAccessor | Retrieves a field of an item as a data stream of bytes. |
