By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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?"

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:

"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.

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.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy