As discussed earlier in this chapter, 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-ofthe- 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.
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.
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:
The following operations provide additional functionality for use in specific circumstances:
Create an External Content Type
Now that you understand what BCS is and how the BDC service uses metadata to connect to external systems, you’re ready to put this knowledge into practice by creating an external content type using SharePoint Designer.
Define SpecificFinder Operation
Accept the default settings by clicking Next to move to the next page.
Click Finish to complete the creation of the Read Item operation.
NOTEIf we had an additional entity that could be correlated by using a particular field—such as Name—you would imagine that we could flag Name as an identifier, allowing associations between the entities to be made. However, this change has some undesirable implications: since Name is now an identifier, we effectively have a compound primary key. This means that all associations would be created based on both the Name and ProductModelID fields. It would not be possible to create an association based on one field or the other in isolation, thus defeating the object of the change.
Define Finder Operation
Now that we have defined a SpecificFinder operation to retrieve individual items from our data source, the next requirement for creating an external list is to define a Finder operation. The external list, like all other lists in SharePoint, makes use of the XsltListViewWebPart to render the contents of the list. However, rather than retrieving the list contents from the SharePoint database, the View definition contains a Method element specifying the name of a Finder operation that’s been defined on the external content type.
Creating a Finder operation follows a similar process to the creation of the SpecificFinder operation:
TIPEven when external lists are not required, by not setting a filter, we’re allowing the BDC service to return all rows in a table. In most cases, this would represent a significant waste of system resources.
Add a Limit Filter
TIPBy default, none of the fields have Show In Picker selected. Since the External Data Picker doesn’t know which fields to include, it simply includes all of them. A much better user experience can be gained by displaying only useful columns in the picker control.
Create All Operations
We’ve now added the minimum operations required to generate an external list. If we generate a list using only these operations, users will be able to view data in a list but will not be able to add, edit, or delete since we haven’t defined those operations.
We manually created the Finder and the SpecificFinder to give us a chance to review the various configuration options. Thankfully, in the real world, you don’t need to go through the same steps for each operation; you can simply select Create All Operations from the context menu. A wizard will automatically generate the required operations to allow users to read and write to the external data store.
Create an External List
Create an Associated External Content Type
Now that you’re familiar with the tools used to create external content types, you’re ready to create another external content type for product information. Then we’ll define a parent-child relationship between our new Product content type and our existing Model content type.
External Data Picker Control
We’ve now created a new Product external content type that has a relationship with our existing Model content type. To see the effects of this association in action, create a new external list based on the Product content type. In the Create List and Form dialog, set the List Name to Products.
By browsing to the new Products list using Internet Explorer, you’ll see that when editing an item in the list, models can be selected from a list using an External Data Picker control, as shown here:
You should notice a few things when you’re using the data picker. First, the list displays all rows from the Models table. If you enter criteria in the Find box, you’ll get an error message, as shown next. Second, if you select an item from the list and then click OK, the Product Model control contains the ID of the selected item rather than the user-friendly text you might expect.
Both of these problems are easy to resolve and take us back to our Model content type.
Setting Picker Display Text
When opening the Model content type in Summary View, you’ll notice a list of fields on the right side of the page.
Adding Picker Search Functionality
The next problem requires a few more mouse clicks to resolve. Open the Model content type in Operations Design View. Since we want to change the way lists of items are returned, we need to adjust the settings for the Finder operation.
With an understanding of the Is Default and Use To Create Match List In Data Picker options, set both of these options to true.
This time, when viewing the changes in the edit form, try entering jersey in the product model text box, and then click the button to the immediate right. You’ll see an error message indicating that no exact match was found, and you can click the underlined text to see a list of suggestions, as illustrated here:
The picker now behaves as expected, filtering results based on the criteria entered in the textbox and allowing search within the pop-up dialog.
Figure:Pinning object explorers to the navigation bar
TIPWhen moving between different object types in SharePoint Designer, it’s possible to pin one category of objects to the left sidebar. In Figure the External Content Types explorer is pinned to the navigation bar while the List and Libraries explorer is visible in the main pane, making it easy to switch to a particular external content type without first having to bring up the explorer.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.