Intelligently Reducing SharePoint Costs through Storage

Intelligently Reducing SharePoint Costs through Storage

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

Traditional Approaches for Getting External Content into SharePoint 

Let’s start by looking at some of the traditional ways of incorporating external content into 

SharePoint. None of these techniques are bad, but they’re not always the best. They offer  compelling features and they help to meet certain business goals, so it’s important that we  consider them as potential tactics. 

Integration 

When you’re dealing primarily with data that lives in external databases, you’re not going  to migrate it into SharePoint unless your plan is to create a SharePoint‐based application  and eventually eliminate that external application (and its database) entirely. For this  discussion, I’ll assume you have data that you want to keep separate from SharePoint, but  that you want some means of accessing that data from within SharePoint. Traditionally, 

Microsoft’s answer—introduced with SharePoint Server 2007—has been the Business Data 

Catalog (BDC). 

The BDC 

The BDC is a shared service within SharePoint, enabling SharePoint to grab business data  from back‐end server applications—ideally without any coding on your part (prior to the 

BDC, integrating back‐end data almost always required some form of custom programming,  which could be expensive to both create and maintain). The BDC allows data to be  integrated into user profiles, custom applications, Web Parts, lists, and even search. It also  provides support for displaying data drawn from both databases and from Web services— such as SAP, Siebel, or other line‐of‐business (LOB) applications. 

Figure 3.2 shows how back‐end data can be integrated into SharePoint portals. Here,  marketing campaign and other information is drawn from a back‐end database or Web  service. 

 

Figure 3.2: Using the data accessed by the BDC. 

40

 

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

From an architecture standpoint, the BDC uses ADO.NET and other data‐access  techniques—such as a Web service proxy—to access back‐end data from a variety of  sources. It then makes that data available to a variety of SharePoint features. XML‐based  metadata is stored in SharePoint itself to help manage that data, and some of the back‐end  data is cached within SharePoint to enable features like search. Figure 3.3 illustrates the  basic architecture. 

 

 

Figure 3.3: BDC architecture. 

That XML‐based metadata is the real functionality of the BDC. It defines the “mapping”  between SharePoint and the back‐end data, defining back‐end entities, data relationships,  and so on. You have to define this metadata when connecting the BDC to back‐end data; 

SharePoint includes tools for doing so. 

 

Business Connectivity Services or “Two‐Way BDC” 

For SharePoint 2010, BDC was renamed Business Connectivity Services (BSC), and given  the ability to do more than just read data from back‐end services. Now, it can also write  data to the back‐end. BCS can also be used from within Office 2010 applications. You might  use Word to perform a mail merge from a customer database, for example. In SharePoint 

2010, “BDC” now stands for “Business Data Connectivity ,” the service that makes BCS work. 

 

41

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

You still have to create XML models of your back‐end data, and those models help control  the ability to write data back to the back‐end. As Figure 3.4 shows (drawn from  http://msdn.microsoft.com/en‐us/library/ee557658.aspx

), the number of ways in which  this data can be consumed is even larger than it was with the old BDC. It even includes  robust caching so that users—say, someone using Excel 2010—can access data even if the  back‐end data source isn’t accessible at the moment. BCS can sync read and write  operations with the back‐end server, once it does become available. 

 

 

Figure 3.4: BCS architecture. 

As shown, you can also write custom .NET Framework assemblies to broker connections to  back‐end data, enabling you to impose and enforce business logic between SharePoint and  your back‐end data. 

Resource 

You can read more about BCS at  http://msdn.microsoft.com/en‐ us/library/ee557658.aspx

 

BCS remains a solid way of integrating back‐end data into SharePoint. It isn’t exactly “no  coding” as sometimes implied because you do need to be able to create your data models,  b ut you won’t have to actually write programming code in order to create those models. 

 

42

 

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

Migration 

Migration: Moving content from place to place. In this case, permanently moving content  from file servers or wherever into SharePoint. This isn’t an option with back‐end data; I’m  not presenting migration as an alternative to the BDC/BCS. But for files, media, and so  forth, migration is an option. 

How It’s Done 

Migration is typically performed using a tool of some kind—and a plethora of them exist  from third‐party vendors, although migration isn’t a space that Microsoft has directly  addressed with any major effort. 

At its simplest, migration can involve simply copying a folder hierarchy into SharePoint,  while maintaining whatever access permissions the file had on its file server. A more  complex migration might also involve restructuring the data because SharePoint offers  organizational metaphors and techniques that aren’t present in a simpler, hierarchical  folder structure on a file server. Migrations can also help automatically populate document  metadata, which helps make those documents easier to find through SharePoint’s search  facilities. 

Benefits of Migrating Content 

The benefits of migrating content into SharePoint are varied and significant. Your content  becomes indexes and searchable. You gain the ability to add version control to documents,  and to enforce workflow rules around document updates. You can in many cases employ  simpler permissions structures, using SharePoint groups rather than individual user  permissions—making long‐term permission maintenance easier. You can even make it  easier for content to be accessed from a variety of places, since SharePoint not only  integrates with the Office suite of applications, but also exposes content via a Web‐based  interface. 

But perhaps the biggest benefit of migration is that you can start to end data chaos. Along  with BDC/BCS, migration can help bring all of your content into one place, as shown in 

Figure 3.5. Users have one place to go to find everything they need. You can start to manage  permissions in this one place, report on utilization in this one place, and so on. You won’t  need to spend days teaching new users where to find everything on the network, and you  can stop mapping a dozen network drives in logon scripts. Users begin to utilize SharePoint  as—well, as a replacement for file servers, perhaps. Everything lives in one place. 

By keeping authoritative copies of data in a single location, you can also start to avoid the  bloat that often accompanies file servers. Users won’t have as strong a need to make copies  of data into their home folders; they can simply keep smaller shortcuts to SharePoint‐ stored documents. Everyone will be working from a single copy of information, rather than  having dozens of copies spread across everyone’s home folders. 

43

 

Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones

 

 

 

Fi gure 3.5: SharePoint migrations can hel p reduce dat a chaos. 

There are a lot of strong arguments in favor of migrating everything into SharePoint.  

Downsides of Migrating Content 

There a re, however, downsides to migrating content, many of which I’ve outlined already . 

• Large content items are going to take up a lot of room in the SharePoint database. 

That’s going to complicate SharePoint performance management, as well as  database maintenance tasks like backups, defragmentation, and so on. 

• Media items don’t work as well from a database—which as I’ve pointed out isn’t  designed for streaming data—as they would from a file system. 

• Some file server‐based data, as I suggested earlier, needs to be on a file server in  order to interact with other processes. For example, you might have a process that 

“watches” a given folder for new files, and does something with them; that won’t  work if the file “lives” in SharePoint. 

Ideally, there’s some middle ground, where we can get the advantages of having content in 

SharePoint—without the downsides. 

44

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents