Does all external SharePoint data have to flow through BCS?

Question

I was asked the question why I need access to BCS Services and have been tasked with documenting "ways to access external data in SharePoint'

I've read one article after the next regarding external data, trying to gain an understanding of ECT's, BCS structure, BDC Connectivity etc. and although I have not trouble with the concepts individually, there is such a plethora of information out there that it's hard to get a comprehensive picture of how it all fits together.

What I'm really trying to do is find out if there are ways outside of BCS to connect to external data sources. For instance, in SPD when a db connection is made to say SQL Server, is that still going thru BCS?

So far, my assumption is that you can consume external data in the following ways:

1. External Content types via BCS Services
2. Custom connections (via Web Services, WCF, .NET assemblies, custom assemblies
3. WCF, .NET assemblies via BCS? this is the part that's confusing..
4. CMIS connector for SharePoint

Is every type of external data in SharePoint considered an external content type? If so, does every ECT have to go through BCS somehow? All mixed up here..

Could someone please explain the 20,000 foot view to me or point me to an article that does? Everything I find seems to go into a deep dive about the individual concepts, but I'm having trouble finding something that puts it all together.

Answer 1

BCS is the way that SharePoint can be made to understand how to access data which is not stored inside SharePoint. Its the abstraction layer between SharePoint and the external system.

Because SharePoint can understand BCS then you get a lot of advantages such as External Content Types which really just present a UI for CRUD operations.

With BCS you also get access to being able to associate external data against documents or list items. You can hook up search to index the BCS content so you can expose that external data inside your Enterprise SharePoint search centre. You can link BCS data against user profiles for example pulling out employee id, job start date from hr systems.

The point with BCS is that if you don't use it then there is a lot of development to get access to external data. All the UI is there to add, edit and delete the data.

If you have complex business rules then you can write a .NET assembly (called a .NET shim ) to handle the CRUD operations.

Here is some more info on bcs with .net assembly. So BCS has some providers that it understands out of the box, it knows about sql server and web services for example.

For systems which it doesn't have native support for, example entity framework or nhibernate then you need a layer that acts as the translator or adaptor between SharePoint/BCS and the external system. So BCS has a series of interfaces which you can create a class which implements the interface to perform the appropriate actions. For example a read function or update function, a filter function for performing select * from object where x = y.

Answer 2

Is BCS the Only Way?

No. BSC is a great tool, but there are lots of ways to access data that doesn't live in SharePoint.

SharePoint Designer Data Connections

Your example of using SharePoint Designer to connect to a database is a great example. That is a non-BCS, legacy option that many have used going back to the pre-BCS days of SharePoint 2003. Even in SharePoint 2007 BDC was complicated enough and expensive enough that SPD Data Connections were more pervasive. However, if you go that route, note that it is a method that is less likely to receive updates or support from Microsoft in the future. Also, BDC was explicitly added to address scalability and permissions issues.

Custom Code

Another common way to access external data continues to be custom code.

Web Parts and Application Pages

In the past the method has been custom .NET code with ADO.Net data connections. SharePoint Application pages and Web parts were deployed in full-trust Farm Solutions and activated through features.

App Model

In the future, Microsoft is pointing us towards the App Model for custom code. It is a viable solution for connecting to external data. One of the most appealing aspects for developers is the broad support for languages and coding methods. ASP.Net MVC is a great example of modern application development that is now supported.

Beyond "Data"

If you broaden the definition of data, there are other ways to connect to information not stored in SharePoint. Federated Search is one example. JavaScript is another way to pull information in. SharePoint 2013 has Script Link web parts that work well with the latter.