• Illustration: A Typical Portal Application
• Illustration: Four Integration Methods
• Sidebar: Single Sign-On Support

SharePoint Portal Server (SPS) 2003, Microsoft’s product for hosting corporate portals, is most frequently used to publish information for employees and business partners and to index and search both intranet and Internet-based content. SPS can also provide a Web interface to corporate applications and data through its modular "Web Part" architecture. However, to successfully integrate SPS with corporate applications, developers must choose the correct architectural approach and have a deep understanding of the APIs and data schemas of the applications they are attempting to integrate, and they may have to deploy other Microsoft technologies for certain portal architectures.

Why Link Portals to Corporate Applications?

Many corporate applications contain information that could be valuable to a broader audience of users than historically have had access to those applications. These include enterprise resource planning (ERP) applications such as SAP and Peoplesoft, customer relationship management (CRM) applications such as Siebel, and legacy industry-specific mainframe applications, such as banking or reservations applications (typically COBOL-based and built on IMS or CICS).

Although such applications provide their own custom user interface—ranging from simple character-based terminal interfaces to "fat" client-side graphical interfaces—and can generate paper or online reports, these interfaces and reports are generally designed for users who enter data or otherwise spend a great deal of time using them. Interacting with these applications usually requires special skills and training, making it difficult for users who access them only occasionally.

Examples of such occasional use include the following:

• Employees who want to see the status of their benefit programs
• Senior managers who want to track various corporate performance metrics
• Sales managers who want to see sales performance metrics
• Employees who want to see if any key IT systems are down
• Business partners who want to check on order status.

It's possible to give these users access to a subset of data and features offered by back-end applications via a corporate Web portal—a modular, customizable Web site that provides a single, well-organized starting point to access information. (For an illustration of a Web Part that displays an employee’s payroll information from SAP, see "A Typical Portal Application".) This approach can yield many benefits:

Make information easier to find and use. Corporate portals can provide easy access to some of the information contained in corporate applications without requiring special skills and training, and without the need to purchase expensive thick-client licenses.

Relieve support staff. Providing self-service information access to managers, employees, and business partners lessens the need for support staff to do simple look-ups and respond by phone, e-mail, routine reports, or briefings.

Create composite applications with context. Portals can combine information from multiple sources, presenting it in ways relevant to each user’s needs and providing context that can yield additional insight, without forcing developers to merge source applications with each other, which is much more difficult to code and maintain. For example, a portal for customer service representatives could present customer information taken from the organization’s CRM application alongside the same customer’s purchase history taken from the organization’s ERP or accounting application.

Personalization. Developers can tailor the portal interface for specific job roles and present only the data or applications that users in those roles are authorized to view.

No client-side code and little user training required. Because portals require no client-side installation or configuration, they are easier to manage and maintain. Furthermore, like most Web applications, they are designed to be fairly simple to use and should require little or no training.

(Note that Microsoft is also encouraging companies to go beyond portals for distributing data for corporate applications. For instance, it recently launched a developer technology called the Information Bridge Framework to support corporate data access directly in Office applications, which can simplify tasks for users who "live" in those applications. Nevertheless, for many users, a browser and a portal will suffice for data accessed only occasionally.)

Four Basic Architectural Models

Like the Windows SharePoint Services platform upon which it’s built, the SPS 2003 user interface consists of Web Parts—modular ASP.NET server controls that nonprogrammers use to assemble custom Web pages. Developers can take one of four basic approaches when linking SPS 2003 Web Parts to corporate applications, and the choice will depend on the application, the Web Part’s intended functionality, the user load, and security requirements. This choice also drives the selection of technologies used in the solution. (For more information about these approaches, see the illustration "Four Integration Methods".)

Web clipping. If the corporate application or a middleware application (such as SQL Server Reporting Services) already supplies a Web interface suitable for portal users, SPS 2003 Web Parts can wrap all or a part of an external Web page or XML file in a Web Part frame. External portlets compliant with the Web Services for Remote Portlets (WSRP) standard, or certain vendor-specific UI encapsulation methods such as SAP IViews, can also be consumed within specific Web Parts designed for such tasks.

Point-to-point. Developers can use Web Parts to directly access an application’s functions via any Web services it exposes or through its native APIs, or they can query information directly from application databases that support ADO.NET data connections.

Data cache. Similarly, a developer could create Web Parts that make ADO.NET database queries to a database replicated or extracted from the production data. This is particularly useful if the portal needs read-only access only to the application’s data.

Integration server. For more complex scenarios, Web Parts can access one or more middle-tier servers that sit between the portal and the back-end application. Often, it’s more practical and scalable to perform intermediate logic or data transformation before hitting the back-end system, especially when asynchronous transactions or message queuing are needed to communicate with the applications. Centralizing this logic on middle-tier integration servers allows many different portal components to access the application without integration code being developed for each one, thereby simplifying development and making the code easier to maintain and monitor. The portal side components only need to handle presentation layer logic and can communicate with the integration server using Web services.

Reducing Custom Development

Developers can use Visual Studio .NET 2002 (or later) to custom-build the Web Parts and other middleware components needed to integrate back-end applications. However, by taking advantage of existing components from Microsoft and other vendors, developers can dramatically reduce the amount of coding required (both initially and during the solution’s maintenance lifetime), build more robust and scalable solutions, and get those solutions into production much faster.

In addition to SPS 2003, Microsoft sells other components that can help with all four approaches to corporate application integration—namely FrontPage, SQL Server, BizTalk Server, and Host Integration Server (HIS). Microsoft also provides single sign-on (SSO) features in SPS 2003, BizTalk 2004, and HIS that allow developers to map each user’s Windows identity to the various proprietary authentication schemes of the back-end applications. (For more information on SSO, see the sidebar "Single Sign-On Support".)

SPS Components

SPS 2003 ships several Web Parts that can help with application integration using the Web clipping model:

The Page Viewer Web Part allows developer to embed existing Web-based applications, even if they are Java-based and running on a Unix platform. The developer simply provides the URL of the external page to the Web Part.

The XML Web Part can take as parameters a URL to an XML data source and another URL to a developer-authored XSL style sheet that renders the data in the Web Part as HTML. However, this solution is noninteractive; the data is read-only.

The WSRP Web Part (downloadable from Microsoft’s gotdotnet.com site) can link the user interface exposed using the recent OASIS "Web Service Remote Portlets" (WSRP) standard and redirect the portlet into a Web Part.

FrontPage 2003

FrontPage, Microsoft’s Web content creation tool, allows nondevelopers to format and customize Web pages that display corporate data. The latest version, FrontPage 2003, includes new templates and wizards for creating data-driven Web Parts for both Windows SharePoint Services and SPS 2003.

In particular, FrontPage’s "Data View" Web Part can access and display read-only data from ADO.NET database queries, XML documents, or Web services, making it appropriate for the point-to-point, data cache, and integration server architectural models.

SQL Server 2000

In addition to serving as the production data repository behind many popular business applications and thereby being a live data source for a Data View Web Part, SQL Server 2000 can help SPS 2003 portal developers in two additional ways.

Analysis Services. SQL Server 2000 can integrate back-end applications with SPS 2003 using a data cache model. In this model, SQL Server 2000 extracts data from live business applications into a data warehouse, where it may then perform further analytical functions on it. An SPS portal could then use a Data View Web part to access specially constructed data sets rather than the live data source directly. Although the data is not real time, these views are sufficient for many purposes and this approach reduces the load on the production system and can return results substantially faster.

Reporting Services. SQL Server’s Reporting Services component can create and manage human-readable reports (in HTML format) from a variety of corporate data sources. Once a Reporting Services template is created, portal developers can simply use SPS 2003’s Page Viewer Web Part to link the Web Part to the report using the Web clipping model. Web Parts more directly linked to Reporting Services are under development as well.

BizTalk Server 2004

BizTalk Server 2004 can provide more complex middle-tier services for integrating corporate applications into SPS portals using the integration server model. BizTalk is especially valuable in several scenarios:

• When an application does not expose a Web or Web service interface or an ADO.NET-compatible API, and writing Web Parts that communicate using the application’s native API requires enough "heavy lifting" that it’s more efficient to centralize the translation code on a BizTalk server, where it can also be used by other Web Parts that integrate with the same back-end application
• When user requests involve transactions or are handled as asynchronous messages
• When some of an application’s business rules are already handled by BizTalk orchestrations, such as when BizTalk is used to handle exceptions
• When the application does not provide native encryption of security credentials
• When the application’s data must be transformed in some way before it is useable by the Web Part
• When the user load from the portal is heavy and BizTalk’s caching and pooling techniques can off-load the back-end application.

When using BizTalk to link corporate applications to SPS 2003, the Web Parts contain the presentation logic and communicate with BizTalk using Web services. BizTalk in turn communicates with the application’s native API using one of hundreds of third-party BizTalk "adapters."

With their support for ASP.NET, both Windows Server 2000 and 2003 can also function as middle-tier servers that connect to the back-end applications and expose their functions as Web services, particularly in cases where BizTalk might be overkill. These middleware components can be developed in Visual Studio or, for a few popular enterprise applications such as SAP, bought or freely downloaded.

Host Integration Server

When the back-end corporate application runs on IBM-compatible mainframes or on AS/400 systems (now known as iSeries) or when application data is stored in IBM’s DB2 relational database system, Microsoft’s Host Integration Server (HIS) can serve as an integration server and provide a means of linking the corporate application to an SPS 2003 Web Part.

An update to the current version, HIS 2000, will ship in the second half of 2004. HIS 2004 will support the .NET Framework and be able to expose mainframe host applications as Web services. SPS 2003 Web Parts could connect directly to HIS, or could go through BizTalk first if its functions are required.

Because HIS 2000 uses COM to integrate legacy host applications, organizations that do not want to upgrade can still use BizTalk to wrap a Web service interface around an HIS 2000 COM interface.

Third-Party Products Make Integration Easier

While the aforementioned Microsoft infrastructure products all make it faster and easier to expose back-end business applications in SPS 2003-based corporate portals, a plethora of third-party BizTalk adapters, .NET connectors, and Web Parts offer portal architects even more options for accelerating development.

BizTalk adapters. BizTalk’s modular "adapter" architecture has spawned a broad assortment of third-party adapters that translate between BizTalk and back-end applications. These off-the-shelf adapters can save a tremendous amount of developer time and expense. IWay Software alone sells BizTalk 2000 and 2004 adapters for more than 250 different applications and technologies, including Baan, BEA, IBM WebSphere and MQSeries, J.D. Edwards, Oracle, PeopleSoft, SAP, and Siebel.

.NET connectors. BizTalk isn’t the only way to expose a Web service interface to the native APIs of a back-end application. For example, the SAP .NET Connector runs on Windows Server and provides a Web service interface to many of SAP’s native APIs (specifically, its BAPI and RFC interfaces).

Web Parts. Occasionally, third-party Web Parts may do just what the portal designer requires, or they can provide a starting template that can be customized to meet particular needs. For example, the new SAP iView Consumer Web Part allows organizations running SAP Enterprise Portal to view SAP "iViews" (analogous to Web Parts) in SPS 2003 portals. A set of Siebel Web Parts is also in the works.

Deep Understanding of Applications Needed

SPS 2003 combined with Microsoft and third-party components can dramatically reduce the time and effort needed to expose corporate applications and data to portal users and allow organizations to further leverage their investments in those key systems.

However, except in cases where the applications already have some sort of Web or WSRP interface, creating portal interfaces to corporate applications is not a trivial task. Portal developers must have a deep understanding of the applications they want to expose, particularly the applications’ APIs and data schemas. Furthermore, they must take particular care to gather all requirements before deciding on the architectural approach, and they must restrain the scope of the project to avoid re-creating the application’s native interface.

Resources

In-depth information on SharePoint Portal Server 2003 can be found in "SharePoint Portal Server Radically Redesigned" on page 8 of the June 2003 Update.

A catalog of SPS 2003 Web Parts can be found at www.microsoft.com/sharepoint/downloads/components.

A catalog of BizTalk adapters can be found at www.microsoft.com/biztalk/evaluation/adapters/adapters.asp and at www.iwaysoftware.com/products/microsoft/BizTalk.html.

More information on using FrontPage to develop Web Parts that call back-end databases can be found in "FrontPage 2003 Targets Data-Driven Web Sites" on page 14 of the Oct. 2003 Update, and on MSDN at msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_fp2003_ta/html/odc_FPUsingDIWwFP.asp.

For more information on SQL Server's Analysis Services, see "OLAP Breaks Ground for SQL Server" on page 6 of the May 2001 Update. For more on SQL Server Reporting Services, see "SQL Reporting Services Launches" on page 3 of the Mar. 2004 Update.

For more about BizTalk Server's capabilities, see "BizTalk Server Engine Reworked" on page 3 of the Apr. 2004 Update.

For details on the Information Bridge Framework, see "New Platform for Office Smart Clients" on page 24 of the July 2004 Update.