BCS object model in Sharepoint 2010
As you might know that in comparison to a custom webpart, BCS has become a preferred method to bring in and display data from external sources for fairly obvious benefits.. such as BCS entities become searchable, you have the ability to use these entities like SharePoint lists, and you can use certain WebParts and other facilities such as associations and actions on these BCS entities,and the ability to represent any back-end system, in a consistent object model that can be programmed against. Well, nothing to hide that object model is the BCS object model.
This BCS object model has a big advantage. As you know that the back-end systems change and upgrade over time, as long as their equivalent BCS external content types are kept up to date, all existing systems can continue to leverage the same object model, and existing systems will continue to work with changing newer versions of back-end systems without even the need of a recompile. This is because, as long as you update the BCS external content types, the actual BCS object model won’t change, and will continue to work and will simply reflect the updated external content types.
The BCS object model provides you with functionality to both query and maintain the catalog, or to execute methods on individual external content types.
Lets look at an example of using BCS object model Browsing through the catalog on your Sharepoint installation.
Start Visual Studio 2010 and create a .net 3.5 console application. Make sure the target platform is AnyCPU, and you add the following references.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Sharepoint.dll
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.BusinessData.dll
Microsoft.Sharepoint.BusinessData.Administration.Client.dll from the GAC
In your console application add a static variable pointing to your SharePoint site as shown below:
privatestaticstringsiteUrl = "http://SP2010Site";
The you can browse through the existing catalog by using the AdministrationMetaDataCatalog
object in the Microsoft.Sharepoint.BusinssData.Administration.Client namespace.
private static void BrowseCatalogDetails()
{
Console.WriteLine("Now Browsing the details of the catalog:");
AdministrationMetadataCatalog catalog =
AdministrationMetadataCatalog.GetCatalog(siteUrl);
EntityCollection entities = catalog.GetEntities("*", "*", true);
Console.WriteLine("\nEntities in the system:");
foreach (Entity entity in entities)
{
Console.WriteLine(entity.Name);
}
// Lets pick the first entity
var entityEnum = entities.GetEnumerator();
entityEnum.MoveNext();
Entity firstEntity = entityEnum.Current;
Console.WriteLine("\nMethods on the first Entity:");
foreach (var method in firstEntity.Methods)
{
Console.WriteLine(method.Name);
}
}
As you can see in the above code you have access to all the entities and all the details of all the entities in the catalog. In fact if you poke around the object model, you will be able to find that purely through the object model you can create the new entities in the catalog as well.
Next let us look at an example of actually executing a method on an entity, and writing the results out.
private static void ExecuteMethod()
{
Console.WriteLine("\nNow Executing methods");
using (SPSite site = newSPSite(siteUrl))
{
using (newSPServiceContextScope(SPServiceContext.GetContext(site)))
{
BdcService service = SPFarm.Local.Services.GetValue();
IMetadataCatalog catalog =
service.GetDatabaseBackedMetadataCatalog(SPServiceContext.Current);
IEntity entity = catalog.GetEntity(siteUrl, "Northwind Customer");
ILobSystemInstance LobSysteminstance =
entity.GetLobSystem().GetLobSystemInstances()[0].Value;
IMethodInstance method =
entity.GetMethodInstance("Read List", MethodInstanceType.Finder);
IEntityInstanceEnumerator ieie =
entity.FindFiltered(method.GetFilters(), LobSysteminstance);
Console.WriteLine("\nCustomers in Northwind:");
while (ieie.MoveNext())
{
Console.WriteLine(ieie.Current["ContactName"].ToString());
}}}}
As you can see in the above code, I’m able to use a consistent object model, irrespective of the details of the external content type, or the back-end system, and be able to execute methods on the back-end system. Thus as the back-end system changes, and the external content type is maintained.
This BCS object model has a big advantage. As you know that the back-end systems change and upgrade over time, as long as their equivalent BCS external content types are kept up to date, all existing systems can continue to leverage the same object model, and existing systems will continue to work with changing newer versions of back-end systems without even the need of a recompile. This is because, as long as you update the BCS external content types, the actual BCS object model won’t change, and will continue to work and will simply reflect the updated external content types.
The BCS object model provides you with functionality to both query and maintain the catalog, or to execute methods on individual external content types.
Lets look at an example of using BCS object model Browsing through the catalog on your Sharepoint installation.
Start Visual Studio 2010 and create a .net 3.5 console application. Make sure the target platform is AnyCPU, and you add the following references.
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Sharepoint.dll
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.BusinessData.dll
Microsoft.Sharepoint.BusinessData.Administration.Client.dll from the GAC
In your console application add a static variable pointing to your SharePoint site as shown below:
privatestaticstringsiteUrl = "http://SP2010Site";
The you can browse through the existing catalog by using the AdministrationMetaDataCatalog
object in the Microsoft.Sharepoint.BusinssData.Administration.Client namespace.
private static void BrowseCatalogDetails()
{
Console.WriteLine("Now Browsing the details of the catalog:");
AdministrationMetadataCatalog catalog =
AdministrationMetadataCatalog.GetCatalog(siteUrl);
EntityCollection entities = catalog.GetEntities("*", "*", true);
Console.WriteLine("\nEntities in the system:");
foreach (Entity entity in entities)
{
Console.WriteLine(entity.Name);
}
// Lets pick the first entity
var entityEnum = entities.GetEnumerator();
entityEnum.MoveNext();
Entity firstEntity = entityEnum.Current;
Console.WriteLine("\nMethods on the first Entity:");
foreach (var method in firstEntity.Methods)
{
Console.WriteLine(method.Name);
}
}
As you can see in the above code you have access to all the entities and all the details of all the entities in the catalog. In fact if you poke around the object model, you will be able to find that purely through the object model you can create the new entities in the catalog as well.
Next let us look at an example of actually executing a method on an entity, and writing the results out.
private static void ExecuteMethod()
{
Console.WriteLine("\nNow Executing methods");
using (SPSite site = newSPSite(siteUrl))
{
using (newSPServiceContextScope(SPServiceContext.GetContext(site)))
{
BdcService service = SPFarm.Local.Services.GetValue
IMetadataCatalog catalog =
service.GetDatabaseBackedMetadataCatalog(SPServiceContext.Current);
IEntity entity = catalog.GetEntity(siteUrl, "Northwind Customer");
ILobSystemInstance LobSysteminstance =
entity.GetLobSystem().GetLobSystemInstances()[0].Value;
IMethodInstance method =
entity.GetMethodInstance("Read List", MethodInstanceType.Finder);
IEntityInstanceEnumerator ieie =
entity.FindFiltered(method.GetFilters(), LobSysteminstance);
Console.WriteLine("\nCustomers in Northwind:");
while (ieie.MoveNext())
{
Console.WriteLine(ieie.Current["ContactName"].ToString());
}}}}
As you can see in the above code, I’m able to use a consistent object model, irrespective of the details of the external content type, or the back-end system, and be able to execute methods on the back-end system. Thus as the back-end system changes, and the external content type is maintained.
0 comments:
Post a Comment