Architecting Web Parts for Business Applications

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 1, 2001

On This Page

Introduction
Designing an Effective Web Part for Business Applications
Planning Your Web Part Architecture
Meeting Challenges
Deploying Your Web Part
Conclusion

Introduction

This paper describes how to build and deploy Web Parts to distribute mission-critical information from a variety of business applications. This paper includes information about how to architect a Web Part for business applications, the tools and skill sets needed to build them, and the challenges that a developer must overcome in the process.

This paper describes the architecture that was used to create the Microsoft-Avanade Siebel and SAP Toolboxes. A toolbox is a collection of Web Parts and related technologies. In this case, the related technologies included COM components and installers).

You can download and install the SAP and Siebel Toolboxes from the Microsoft Web Part Gallery at https://www.microsoft.com/business/default.mspx.

Readers of this paper should be familiar with the following technologies:

  • Active Server Pages (ASP).

  • Microsoft® Visual Basic®.

  • COM+ components.

  • Microsoft SharePoint Portal Server

  • The digital dashboard framework.

  • Extensible Markup Language (XML) and Extensible Stylesheet Language Transformations (XSLT).

  • Certificates and Public Key Interoperability (PKI).

Designing an Effective Web Part for Business Applications

Web Parts are reusable components that contain Web-based content such as XML, HTML, and scripts. Web Parts have a set of standard properties that control how they are rendered in a digital dashboard. These properties make Web Parts and dashboards storage-neutral and completely reusable. Because Web Parts adhere to a common standard, you can store them in libraries from which you can draw to assemble a variety of digital dashboards in your organization.

An effective Web Part should display information in a manner appropriate to a digital dashboard. The goal of a dashboard is to summarize, synthesize, and reduce the information users see all the time.

An important first step in designing an effective Web Part is to determine what subsets of application data users require in their daily operations. Additionally, the designer should find out if there are any subsets of data that relate to one another. This can be useful for designing Web Parts that communicate with each other to create a digital dashboard application with separate components. For example, a Web Part that displays customer names from Siebel could be linked to a Web Part that displays customer purchase orders from SAP, so that clicking a customer name in the Siebel Web Part will display the purchase orders in the SAP Web Part. Customizable Web Parts, in which the user can sort, filter, and add/remove columns of data further enhance the user's experience.

Planning Your Web Part Architecture

Designing Web Parts for business applications is similar to designing other distributed enterprise applications. A popular architecture for enterprise applications is the 3-tier, or n-tier, architecture, where services are split into Presentation, Business, and Data tiers. The classic 3-tier architecture is therefore a good architecture to start with when building Web Parts for business applications using SharePoint Portal Server. The following figure describes the three tiers.

Cc723725.spsweb01(en-us,TechNet.10).gif

Figure 1: Classic 3-tier architecture

The Presentation Tier

Web Parts are rendered in a digital dashboard, and require a Web browser on the client machine. Currently, SharePoint Portal Server supports browsers that are HTML 3.2 compliant. Web Parts are, at the risk of oversimplification, like small Web pages. Therefore, developers must address the same issues that are inherent with cross-browser compatibility, including deciding whether or not to use DHTML, XML, and other client-side technologies in the Web Part.

Developers should be skilled in the variety of technologies associated with traditional Web-based application design. These technologies include HTML, JavaScript, and VBScript. To maintain a consistent look and feel among Web Parts, the digital dashboard should uses common style sheets that the user interface developer should use. At this stage of development, traditional tools such as Microsoft FrontPage® and Microsoft Visual Interdev® are helpful for HTML and script development.

The digital dashboard also provides a rich set of services that aid in communication and state management. Developers should plan how to take advantage of these services in order to create unique digital dashboard applications that are more than simply the sum of the individual Web Parts. The digital dashboard provides the client-side services through the Digital Dashboard Services Component (DDSC). The presentation tier developer should fully understand the DDSC to create good Web Parts that can communicate with each other.

Digital Dashboard Services Component (DDSC)

The DDSC is a client-side component that is included in every dashboard page as a hidden object. This component makes Web Parts truly reusable and easier to build by providing a standard infrastructure for the following services:

  • Part Discovery. Allows Web Parts to discover other Web Parts on a dashboard.

  • Notification. Allows Web Parts to respond to external events that occur at the dashboard or Web Part level.

  • Session state management. Allows Web Parts to interchange information and objects within a browser session.

  • State management. Allows dashboards and Web Parts to maintain global state and to persist this state between activations.

  • Item Retrieval. Allows Web Parts to retrieve and maintain the state of items in the store module.

For more information about the DDSC and digital dashboard factory, see the Digital Dashboard Resource Kit.

Cc723725.spsweb02(en-us,TechNet.10).gif

Figure 2: Presentation Tier with DDSC

Business Tier

It is useful to separate the business tier into two more logical tiers: the user-centric tier, which deals with the delivery of HTML that will render in a client's browser, and the data-centric tier, which handles the complexities of accessing resources in the data tier.

Web Part properties determine how the Web Part is rendered in the dashboard.

The User-centric Tier

The digital dashboard factory is a code engine, implemented as an ASP page or compiled code on the Web server. This server assembles the Web Parts into a layout suitable for rendering Web Parts in a dashboard. Web Parts can contain embedded content, including HTML, scripts, Microsoft ActiveX® controls, or XML. They can also contain links pointing to any type of Web-based content in any location.

The factory also exposes a programming object model and a scripting host on the server. Services exposed by this object model include server-side object creation, querying of standard IIS server variables, and querying of factory inspection variables that expose information about the type of factory and environment the current part is running in. SharePoint Portal Server and the digital dashboard use Microsoft Internet Information Services (IIS) to render Web Parts. Developers can use the scripting host to build rich Web Part content. Web Parts are defined as an open specification and are meant to run in a platform-independent fashion. Because of this, Web Part authors must use the factory object from the scripting host as to ensure portability of the Web Parts.

In an enterprise environment with multiple browsers, and devices in the field, the Web Part must be able to detect what type of client browser is requesting the data and then be able to send the appropriate Web content for that particular platform. This is best accomplished by using script in a Web Part that queries the factory object for the type of client and then sends the appropriate content.

An effective method for dynamically formatting raw data into Web content is to use XSLT. This technique, coupled with determining the dashboard factory browser, allows the developer to take raw XML data, delivered from the data-centric tier, and format it into Web content that can best be viewed in the user's particular environment. By using the scripting host provided by the factory, the developer supplies the Web content by implementing a function called GetContent().

Cc723725.spsweb03(en-us,TechNet.10).gif

Figure 3: User-centric Business Tier

Data-centric

Using XML is the most effective technique for passing data from the data-centric tier to the user-centric tier. This gives the user-centric developer the flexibility to format the data into the appropriate Web content. Therefore, the first step for the data-centric developer is to build an XML Generator. This is a component wrapper around the application programming interface (API) for the business application that retrieves data and formats it into XML.

The data-centric developer may include an interface for the component that allows the Web Part builder to supply some constraints to the information. Filtering and sorting the information from the business application are two examples of such constraints.

Although the work for data-centric developers appears to be relatively straightforward to this point, they have the extremely difficult task of programmatically accessing the business application's data. This is a crucial exercise that requires extensive knowledge of the business application.

Business applications are inherently intricate. Usually, the data in such applications are contained in data stores whose schema complex. For example, a full instance of SAP R/3, with all the modules, requires a database that contains over 10,000 tables.

Given the complexity of business application data stores, the fact that schemas always change, and the fact that most of the data is locked behind a fortress-like application layer, many business application vendors provide published APIs or input/output (I/O) mechanisms for accessing the data. Because Microsoft Windows® is prevalent in most enterprises, many of the application vendors have COM components that expose these APIs. When building Web Parts for the digital dashboard, using these COM components is the preferred method for accessing business application data.

Again, most business and legacy applications are important applications. To use data appropriate for the Web Part, the developer must have deep knowledge of the application and the API or I/O mechanism used to access the business or legacy application data. If this is not the case, the development team should consult with experts that do have such knowledge.

Cc723725.spsweb04(en-us,TechNet.10).gif

Figure 4: Data-centric Business Tier

Meeting Challenges

Authentication

Most business and legacy business applications use separate usernames and passwords for authentication into the system, and these are not based on Windows authentication. This becomes a challenge for the Web Part builder. Users should not have to enter a user name and password to view each different Web Part on a single page. A user's login information should be requested only once for each business application, especially if multiple views against the data are needed.

To give the user a single sign-on experience, another component should be supplied to translate a user's authenticated user name (NTLM) and map it to the business application user name and password. A signed digital certificate is required to keep the process secure by encrypting the transfer of user name and password. After a user is authenticated against the business application, other Web Parts requesting data from the same business application should not have to be re-authenticated.

A handy utility designed to solve such a problem is the Avanade Security Broker. The Avanade Security Broker stores encrypted data mapping NTLM user names to business and legacy application security authorization schemes. All communications between this utility, the user name/password database, and the calling XML Generator are encrypted using PKI standards to ensure security.

Cc723725.spsweb05(en-us,TechNet.10).gif

Figure 5: Data Tier

LOB Application API Latency

Given the complexity of business applications, it is no surprise that the APIs for those applications can complicate retrieving the information one needs. For example, SAP has a rich set of COM APIs that assist the Windows Developer access data from its popular ERP application, R/3. However, many of the function calls that must be made to the system are complex and require a strict order with data from one call feeding into the next.

With such complexity, it is often difficult to retrieve summary data quickly. In such cases, it is helpful to create a staging database that contains summarized data that can be retrieved quickly. By using this technique, a Web Part data-centric component can be more efficient in its operation and, ultimately, more useful to the user of the Web Part application.

Cc723725.spsweb06(en-us,TechNet.10).gif

Figure 6: Data Tier LOB Application

Deploying Your Web Part

Deploying Web Part applications and digital dashboard applications should be easy for an administrator. By using the example in this white paper, a Windows installer application, a Microsoft Installer File (.msi), can be used to install the XML Generator COM+ application, provide for any business application dependencies, and copy all the self-contained Web Parts to a gallery. The dashboard administrator can then allow users in the field to import the Web Parts in a digital dashboard.

Conclusion

The release of Microsoft SharePoint Portal Server and the digital dashboard offers the enterprise a powerful, yet simple and cost-effective platform on which to easily deliver business and legacy application information. In addition, third party vendors are building Web Parts that allow companies to pick from pre-built components that quickly plug into a digital dashboard, providing quick, powerful solutions.

Visit the online Web Parts Gallery for the latest versions of Web Parts and tools including the Microsoft Avanade SAP and Siebel Web Parts. The link to the gallery can be found at: https://www.microsoft.com/business/default.mspx.

More information about creating Web Parts can be found in the Digital Dashboard Resource Kit 3.0, which includes the Web Parts Development Kit.