(prepared in conjunction with Avanade)

Published: June 2001

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 http://www.microsoft.com/business/dd/.
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.

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.

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().

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

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.

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:
http://www.microsoft.com/business/dd/.
More information about creating Web Parts can be found in the Digital Dashboard Resource
Kit 3.0, which includes the Web Parts Development Kit.
For more information: http://www.microsoft.com/sharepoint/ and
http://www.microsoft.com/technet/prodtechnol/sharepoint/default.asp.
This is a preliminary document and may be changed substantially prior to final commercial
release. This document is provided for informational purposes only and Microsoft makes no
warranties, either express or implied, in this document. Information in this document is
subject to change without notice. The entire risk of the use or the results of the use of this
document remains with the user. The example companies, organizations, products, people
and events depicted herein are fictitious. No association with any real company,
organization, product, person or event is intended or should be inferred. Complying with all
applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written
permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in
any written license agreement from Microsoft, the furnishing of this document does not give
you any license to these patents, trademarks, copyrights, or other intellectual property.
Unpublished work. © 2000 Microsoft Corporation. All rights reserved.
Microsoft, Windows, ActiveX, FrontPage, Visual Basic, and Visual InterDev are either
registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other
countries.
The names of actual companies and products mentioned herein may be the trademarks of
their respective owners.