SharePoint 2013: Combine BCS & Local Sites For Unified Search

Hey guys, ever tried to get all your search results from different sources to play nice together in SharePoint 2013? Specifically, integrating data from your Business Connectivity Services (BCS) applications with your standard SharePoint local sites can feel like trying to herd cats. It's a common scenario: you've got critical business data sitting in an external system, brought into SharePoint via BCS, and then you have all your regular SharePoint content like documents, lists, and pages. The dream? A single, unified search experience where users can find everything from one search box, without having to know where the data lives. But then, reality hits, and you find yourself staring at search results that only show your SharePoint content, leaving your valuable BCS data nowhere to be found. This, my friends, is a classic challenge in SharePoint 2013 search, and it’s exactly what we're going to tackle today. We're going to dive deep into how to leverage SharePoint 2013 Result Sources to bring these disparate content types together, troubleshoot why your BCS content might be playing hide-and-seek, and ensure your users get that seamless, comprehensive search experience they deserve. Understanding Result Sources is absolutely crucial here, as they are the powerful tools that let us define what content gets searched and how it's filtered, making them the cornerstone of any successful unified search strategy in SharePoint 2013. We’ll walk through the process step-by-step, making sure you grasp not just how to do it, but why certain configurations are necessary, especially when dealing with the intricacies of BCS integration. Get ready to transform your SharePoint 2013 search into a truly powerful, all-encompassing information hub!

Understanding SharePoint 2013 Search Architecture for BCS and Local Content

To really nail this SharePoint 2013 unified search thing, especially when combining BCS and local SharePoint content, we first need to get a solid grip on the underlying search architecture. Think of it like this: before you can combine ingredients for a killer meal, you need to understand each ingredient and how your kitchen works. In our SharePoint 2013 kitchen, the main ingredients and tools are Content Sources, Crawl Components, Search Schema, and the star of the show, Result Sources. Let's break them down. First up, Content Sources. These are literally where your data originates. You'll typically have at least two for our scenario: one for your Standard SharePoint Local Sites, which includes all your typical SharePoint lists, libraries, and pages, and another specifically for your BCS Application. The BCS content source is special because it tells SharePoint's crawler to connect to external systems (databases, web services, custom .NET assemblies) defined by your External Content Types (ECTs). Ensuring both content sources are properly configured and working is the absolute first step. If your content isn't being crawled from these sources, it'll never make it into the search index. We're talking about making sure your external system is reachable, your BCS models are correct, and your SharePoint sites have proper permissions for the crawler service account. Once these sources are defined, the Crawl Components kick in. These are the unsung heroes that actually go out, gather the data from your content sources, and push it into the search index. They're responsible for reading all that information – from your SharePoint documents to the rows in your external database – and packaging it up for the next stage. A successful crawl is non-negotiable for any content to appear in search, so keeping an eye on your crawl logs is paramount. After the content is crawled, it enters the domain of the Search Schema. This is where raw, crawled properties (the bits of data the crawler pulled in, like a document's author or a BCS field's value) get mapped to managed properties. Managed properties are incredibly important because they are the only properties you can actually search against, sort by, and refine results with. For BCS content, this means ensuring that the specific fields from your external system (e.g., 'CustomerID', 'ProductName') are correctly mapped from their crawled property counterparts to their respective managed properties. Without this mapping, your valuable BCS data might be indexed but effectively invisible or unusable for search queries. Finally, we arrive at Result Sources. This is where the magic happens for unified search. A Result Source is essentially a pre-defined query and scope that tells SharePoint where to look in the index and how to filter the results before displaying them. Instead of just searching the entire index, you can create a Result Source that intelligently combines results from specific content sources or based on certain criteria. For our goal of combining BCS and SharePoint content, a Result Source will allow us to craft a query that says,