Business Connectivity Service (previously Business Data Catalogue / BDC) was one of the most exciting features in Microsoft SharePoint Server since its first release. Although it had a lot of short comings in its first version, but the idea behind it made it an important tool in the package. In SharePoint Server 2010, we have the possibility of using external data almost like a native list and it is possible to work with BCS in client object model which opens new doors for its extensibilities. Microsoft has made some changes in the next version (2013) to bring it to the next level. The new interoperability between BCS and other services (e.g. Visio Services) makes the ground ready for new solutions that were not possible / easy before.
Here are the most important changes (In my opinion):
- SharePoint now supports OData as a data source for BCS
- It can receive events from external systems
- External content types can be application scoped
- REST support is enhanced
- Richer object model for BCS
- It’s now possible to use external data in Visio / Visio Services and data will be refreshed when it’s changed!
OData (Open Data Protocol) Support
External System Events
The external event system works as a push model meaning that the external system (LOB application) sends a notification to let SharePoint know that an event is occurred, SharePoint then keeps record of the event in a notification list and notifies to it’s subscribers. The external system notifies SharePoint by sending a message to a REST endpoint in SharePoint that is configured as delivery address. [Read the following article in MSDN for more information: External events and alerts in SharePoint 2013]
Accessing external data in Visio
External list can now be used in visio diagrams. The procedure is really easy and from the Visio point of view you don’t feel any difference at all. After you create an external content type with BCS, and an external list. You just need to open up Visio 2013, go to “Data” tab and click “Link data to Shapes” (as you normally do with any data source) and this time select “Microsoft SharePoint Foundation”, Select the web site and the list that you’ve created previously. [More about new features in Visio 2013 on MSDN]
In SharePoint, Property bags are usually used to store values / configurations related to a web site. Reading / Writing them via PowerShell is really easy just fire up “SharePoint 2010 Management Shell” from the Start Menu and type the following commands:
$web = Get-SPWeb "http://yourwebsite"
$web.Properties["PropertyName"] = "Property Value"
How to change search service account using SharePoint Central Administration
The simplest way to change the account of a service in SharePoint is to:
- Run Central Administrator
- Go to Security > Configure service accounts
- Select “Windows Service – SharePoint Server Search”
- In “Select an account for this component” select the account that you want and if it is not in the list, click “Register new managed account” and add it easily.
How to change search service account using PowerShell
But sometimes it’s not as easy as above to change a service account in SharePoint. For example you have installed SharePoint on a server for development whiout adding “Active Directory Domain Services” server role. In that case you can only add Managed Accounts through PowerShell and even though it won’t be displayed on managed account list in Central Administration and you can only use PowerShell to assign them to different services.
Step1 – Here is how to add a managed account in PowerShell:
First, go to the Start menu, then “Microsoft SharePoint 2010 Products” and run SharePoint 2010 Management Shell” which will run PowerShell and adds SharePoint Snapin so you can run SharePoit’s cmdlets. Now you can type the following commands:
$cred = Get-Credential "Username"
New-SPManagedAccount -Credential $cred
Step 2 – How to assign it to OSearch14 (Enterprise Search):
$account = Get-SPManagedAccount -Identity "Username"
$procId = (Get-SPEnterpriseSearchService).get_ProcessIdentity()
$procId.CurrentIdentityType = "SpecificUser"
$procId.ManagedAccount = $account
Remember that the last line is important beacuse you won’t see any changes until this step. It actually restarts the service with the recently assigned account.
Since I have answered this question a few times now I decided to write a post about it. maybe it helps some others who have the same question: “What is the difference between MEX and WSDL as a meta-data description for WCF service” and probably the next question: “When we should prefer one to the other?”
MEX and WSDL are both ways of publishing meta-data information from your services. WSDL is more known since it’s been around for more time than MEX. It is currently in use with a lot of web services in real world. Since they both are automatically generated for your service based on the same meta-data there is no important regarding the completeness and consistency. In short: They are the same! The only differences are as follows:
- WSDL exposes this information as a WSDL document which is accessible by an HTTP GET request (and you can easily check it in a browser) but MEX exposes the same information as a SOAP message over http, tcp and named pipes
- MEX generates one message containing all the meta-data but WSDL generate one that contains a description of Operations and one for each data contract and the URL for those are also included in the root document. In other words, MEX generates a big message containing all the required information which requires only one request to the server and WSDL generates a smaller one which contains URLs for the more detailed information that requires more requests to the server (if required)
- They are slightly different in using XML to provide information
Now that the first question is answered, answering the second one is easier:
If you are using Visual Studio as your IDE for development it can generate proxy client classes for both and if you are using svcutil.exe to generate them it can also generate them so the answer lies in the slight differences. You better use WSDL since it is easier to check in a simple web browser and only use MEX for when you need to publish meta-data through tcp and named pipes channels or for you software there is a benefit that the whole meta-data is read only once.