Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Integrating existing applications with SharePoint Server 2007

Options depend on the integration you want to achieve, your in-house skills and your version of Microsoft Office SharePoint Server 2007.

It's likely that you are using Microsoft Office SharePoint Server 2007 in your organization. If not, there's probably a strong contingent within your organization lobbying to implement the technology.

Once you have SharePoint server, though, there's the inevitable challenge of integrating existing applications into the portal framework. So, this begs the question -- if you want to use SharePoint as your enterprise portal platform, how do you integrate applications that aren't "SharePoint-aware?"

More on Microsoft Office SharePoint Server 2007
SharePoint exec tackles technical questions about MOSS 2007

Seven steps for Microsoft Office SharePoint Server disaster recovery

Share your SharePoint expertise on IT Knowledge Exchange and hear what your peers have to say about issues related to Microsoft Office SharePoint Server 2007.

 The answer is it depends. Microsoft has imbued SharePoint with functionality unique to the product, like the Business Data Catalog in Microsoft Office SharePoint Server (MOSS) 2007 and with "inherited" functionality as the result of a "base" technology like the .NET framework. As a result, there are usually a half dozen ways to get anything done.

This article will demonstrate a few ways to integrate applications along with the high-level guidance for deciding which approach might be most appropriate for a given situation.

Integration approaches in Microsoft Office SharePoint Server 2007

The general categories of integration approaches in SharePoint naturally include options that may or may not be available to you based on the version of SharePoint you have -- Windows SharePoint Services (WSS), Microsoft Office SharePoint Server Standard (MOSS Standard) or Office SharePoint Server Enterprise (MOSS Enterprise). You'll have to make the final decision as to what's best for your organization. Here are the options:

  1. "Frame" integration
  2. Integration Web Parts
  3. Business Data Catalog
  4. Excel Services architecture
  5. Custom interface

"Frame" integration -- This type of integration is not a "real" official methodology but rather a generic way of presenting an existing Web-based application within the SharePoint interface using the Page Viewer Web Part. This approach, under the covers, inserts an IFrame -- hence the name -- into a Web Part page with the source pointing to your "integrated" Web application.

Where it works

  • Applications that don't offer radically different interfaces from the SharePoint interface that wraps it.
  • When you want to present a portion of some application that can operate independently.
  • Simple menu interfaces that launch other Web interfaces. It makes SharePoint the launch point but doesn't restrict the user to operating inside of the SharePoint interface.

Where it doesn't work

  • Applications that are incompatible with IFrame elements.
  • Complicated multi-interface Web applications.
  • Applications that don't have a Web interface.

This approach works well for "stop-gap" measures to drive traffic to SharePoint and when only a "simple" integration is necessary or possible. More complicated interfaces don't generally work.

Integration Web Parts -- These are included in another unofficial category that describes using Web Parts that ship with MOSS for Web Services for Remote Portals or WSRP, the Java portal standard and SAP's portal. These Web Parts do an OK job of enabling you to connect to non-Microsoft applications that leverage one or the other standard.

Where it works

  • You have a Java Portlet you want to import into SharePoint that adheres to WSRP standards.
  • The Portlet and integration with SAP Portal is not complex. The WSRP part relies on a Web services interface and may not work in a number of cases. The SAP Portal Web Parts rely on the IViews and, again, they won't work for complicated scenarios.

Where it doesn't work

  • Complex integrations with either a Portlet or SAP Portal.
  • Portlets that don't adhere to WSRP standards.

The WSRP and IView Web Parts seem to be a partial attempt by Microsoft to help transition customers of non-Microsoft portals to SharePoint. Neither Web Part is particularly strong but they could work for simple scenarios and are marginally better than the "frame" option.

Business Data Catalog -- This new service in Microsoft Office SharePoint Server 2007 enables you to construct an "application definition," which acts like a map for primarily database or Web service-based applications. It functions like a consumer of pure data that can, in turn, be presented within SharePoint as entities – meaning tables or stored procedures in database vernacular.

Where it works

  • Integration with data sources, where a "new" SharePoint interface using Business Data Catalog Web Parts are possible.
  • When you want to be able to search data created and/or maintained by another application.
  • When you want to integrate data from more than one application into an aggregated view.

Where it doesn't work

  • Situations where you need to edit data. The Business Data Catalog is read-only.
  • When presentation of the data requires a specialized Web interface. The Business Data Catalog Web Parts aren't really that flexible in their presentation.
  • Applications that require fine-grained security control over presentation of data. The Business Data Catalog can secure only at the entity level and not at the row level.

The Business Data Catalog makes a ton of sense when you want to integrate another application's data with SharePoint or want to make that data available through search. However, given that the Business Data Catalog is read-only and has some display and security limitations, it may not be a fit for all applications.

Excel services -- Excel Services enables you to present an Excel workbook -- or a portion thereof -- in a Web interface without having Excel on the client. Available to MOSS Enterprise users, this service is useful when you need to distribute Excel-based data to non-Excel users. However, just like the Business Data Catalog, it can also be used to present data from other applications by using a data connection stored in SharePoint -- like in the creation of an executive reporting dashboard.

Where it works

  • To integrate the data of another application into the SharePoint interface.
  • When end users need to have control over display of the data – all it requires is modifying an Excel workbook.
  • When you need the entire data source to be accessible to everyone, along with access to the workbook.

Where it doesn't work

  • When you need a specific display of data not supported by Excel or you need to enable data entry.
  • When you need fine-grained security control over the application or function-level authorization.
  • If you need to be able to search the data.

Excel makes an excellent interface for the presentation of data or graphs based on data. As an added bonus, typical business users can manipulate the display, relieving IT of the burden. Unfortunately, this flexibility comes at the price of security, and -- like the Business Data Catalog -- it's read-only.

Custom interface -- The most flexible option available is to build a custom interface inside of SharePoint. Custom integration can come in many forms, from the construction of one or more Web Parts (thanks to the .NET framework) to the building of SharePoint-aware Web pages. Not everything has to be in a Web Part or some combination, which is probably the most typical solution.

Where it works

  • When you need highly customized views or interfaces for your application.
  • If none of the other methodologies work.
  • When you want to create a specific experience that is "not SharePoint" within SharePoint.

Where it doesn't work

  • When you don't have developers on staff or the budget to hire consultants.
  • If you cannot fund ongoing support of the custom interfaces. Many organizations underestimate the cost and effort involved in support.
  • When the overhead of the SharePoint product overly burdens the application. This is subjective, but it's a factor in whether or not to actually integrate.

Custom development is by far the most flexible, which means it's also the most complex. Use this option judiciously and be aware that you're going to become a software development shop – with all of the rights, privileges and associated costs. There are certainly good reasons to pursue this approach – just know what you're getting into.

As far as integrating existing applications in Microsoft Office SharePoint Server 2007 goes, keep in mind that there's usually no single right answer. The approach you take depends on the integration you want to achieve, your in-house skills and the version of SharePoint you're running. The advantage is that SharePoint really does provide loads of opportunities and flexibility for integrating your existing applications. You just need to take the time to figure out the best option for your organization.

Shawn Shell is the founder of Consejo Inc., a consultancy based in Chicago that specializes in Web-based applications, employees and partner portals, as well as enterprise content management. He has spent more than 19 years in IT, with the last 10 focused on content technologies. Shell is a co-author of Microsoft Content Management Server 2002: A Complete Guide, published by Addison-Wesley, and the lead analyst/author on the CMS Watch SharePoint Report 2008.

Dig Deeper on SharePoint administration and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.