Gathering MOSS

New Dev-Centric Features In Office SharePoint Server Keep Your Apps Rolling

Ted Pattison

This article is based on a prerelease version of the 2007 Microsoft Office system. All information herein is subject to change.

Contents

Building MOSS 2007 Portal Sites
Shared Service Providers
User Profiles
MOSS 2007 Search
Business Data Catalog Integration
Web Content Management
Business Intelligence Features
Managing Documents and Business Processes
InfoPath Forms Services
ECM and Single Sign-On
Wrapping It Up

Microsoft Office SharePoint Server (MOSS) 2007 provides portal and search features that represent the next generation of SharePoint® Portal Server (SPS) 2003. However, Office SharePoint Server 2007 is much more than that. The Office team made significant investments in many other areas to give MOSS 2007 extra dimensions in Web content management, document and records management, business process integration and forms, and business intelligence. In this article I'll describe the basic architecture of MOSS 2007 and explore the various opportunities for developers to build portal sites and business solutions.

One of the most appealing aspects of MOSS for developers is that it is built on top of Windows® SharePoint Services (WSS) 3.0 and ASP.NET 2.0 (see Figure 1). MOSS 2007 portal sites are created using WSS features and site definitions along with familiar ASP.NET building blocks such as Master Pages and Web Parts. This means that MOSS solutions can easily be extended with ASP.NET components such as server-side controls and custom Web Parts as well as custom components that utilize WSS features like custom list definitions, document libraries, event handlers, and workflows.

Figure 1** MOSS 2007 within the SharePoint Ecosystem **

It's important to understand the extent of the synergy that exists between MOSS 2007 and WSS 3.0. Many of the new features in MOSS are made possible by new WSS innovations such as Master Page integration, content types, versioning, and workflows.

As a developer, it's also important to set your expectations accordingly about what you'll need to do to get a MOSS solution up and running. Unlike many other development projects, you don't usually start by firing up Microsoft® Visual Studio®. In some scenarios you can get an entire business solution up and running without ever writing any custom code. This is quite different from developing directly on the ASP.NET platform by itself where you need Visual Studio to put together the simplest site.

The Microsoft Office team promotes a philosophy in which you begin building a MOSS business solution with an assemble-and-configure mentality. Once you determine the MOSS features and services you want to utilize, you can create a new portal site and do as much "development" as possible simply by configuring services through browser-based administrative pages. If you are going to succeed at building MOSS-based solutions, it's important to embrace this assemble-and-configure mindset.

However, there will inevitably be times when this mindset doesn't cut it for a particular solution. Then you can put your developer's hat back on and crank up Visual Studio 2005 to create many of the custom component types that are discussed here.

Building MOSS 2007 Portal Sites

You can expect to find all the portal features in MOSS 2007 that you have become accustomed to in SPS 2003, such as user profiles, audience targeting, personal sites (that is, My Sites), search, and single sign-on (SSO). MOSS 2007 also includes several new portal features like the Business Data Catalog.

If you have a background in building portal solutions on top of SPS 2003, you will find that MOSS 2007 is different in many ways. For example, SPS provides its own separate administrative Web application for provisioning and configuring portal sites. MOSS, on the other hand, doesn't require its own separate administrative application. Instead, MOSS integrates its administrative features and configuration links into the WSS Central Administration application using the "light-up" features of WSS 3.0.

MOSS 2007 is also quite different from SPS under the hood. SPS builds its portal site infrastructure around the concepts of areas and listings. However, areas in SPS 2003 represent a strange and undocumented layer on top of WSS 2.0 that developers have found difficult to extend using standard WSS techniques. So areas and listings have been eliminated in MOSS 2007 and replaced with a portal infrastructure that was designed and implemented much more in line with WSS best practices.

A MOSS 2007 portal site is a WSS site collection containing a top-level site along with several child sites below it. Unlike SPS 2003, a portal site does not have to be created at the root of an IIS Web site. This provides more flexibility because you can host hundreds of portal sites inside a single IIS Web site. (Remember that in WSS 3.0 terminology, an IIS Web site extended with WSS functionality is known as a Web application.)

You create a new MOSS portal site just as you would create any other new site collection through the WSS Central Administration application, the stsadm.exe command-line utility, or through custom code. When creating a new MOSS portal site, you typically use one of the portal site templates created by the Office team. For example, there is the Corporate Intranet Portal site template that has an internal name of SPSPORTAL#0. If you want to create a new portal site of this type, you can use the code shown in Figure 2, which works against the object model provided by WSS 3.0.

Figure 2 Creating a New Template-Based Portal

// Create the GlobalAdmin object using(SPGlobalAdmin admin = new SPGlobalAdmin()) { // Open the target Web Application Uri path = new Uri("https://LitwareServer1"); SPVirtualServer webApp = admin.OpenVirtualServer(path); // Create new site collection for portal site webApp.Sites.Add(@"https://LitwareServer1/sites/Portal1", "My new portal site", "My portal site description", 1033, "SPSPORTAL#0", "LITWAREINC\\Administrator", "Litware Administrator", "administrator@litware.com"); }

Figure 3** Configuring MOSS 2007 through Shared Service Providers **

In addition to this template, MOSS also supplies top-level portal site templates titled Internet Presence Web Site and Publishing Site. The Office team has also provided new site templates to create child sites within a portal site collection, such as Report Center and Search Center. In addition, the team evolved some of the older SPS 2003 site templates for use within MOSS 2007 portal site collections such as News, Topics, and the Sites Directory.

Shared Service Providers

The architecture of MOSS 2007 is based on shared service providers (SSPs). An SSP represents a set of services that can be configured a single time and shared across many different MOSS portal sites and WSS sites. Understanding SSPs is critical to being able to take advantage of MOSS features and services.

After you have finished installing MOSS 2007 in a farm, you must explicitly create and configure one or more SSPs to take advantage of MOSS features such as user profiles, audiences, personal sites, Excel® Services, the Business Data Catalog, and search. After creating an SSP through the Central Administration pages, you can then configure the individual MOSS services you need from the main SSP administration page, shown in Figure 3.

This new SSP architecture was designed to replace the shared services infrastructure of SPS 2003 to provide greater flexibility in deployment and configuration. For example, it's possible to create two different SSPs within the same server farm, each with its own configuration, as shown in Figure 4.

Figure 4** Each Web App Has Its Own Shared Service Provider **

Within a MOSS 2007 farm, each Web application is associated with exactly one SSP. One Web application can be associated with one SSP while a different Web application can be associated with a second SSP. The MOSS portal sites and WSS team sites will use the SSP configuration for their parent Web application. As a result, the search results from within one portal site might be very different from the search results within another portal site if they are associated with different SSPs that have been configured to have different content sources.

User Profiles

User profiles are a MOSS 2007 feature that has been carried over from SPS 2003 to track information about the users within an organization. Profiles allow users to learn more about the people they work with and see how everyone fits into their company's organization chart. User profiles also provide the foundation for other MOSS features such as audience targeting and personal sites.

Once you have configured the user profile service through an SSP, MOSS stores the data for user profiles in Microsoft SQL Server. MOSS 2007 makes it possible to import and synchronize user profile data from external sources such as an Active Directory® domain as well as other LDAP-based identity management systems.

MOSS 2007 provides several standard pages and Web Parts to display the information tracked within user profiles. For example, Figure 5 shows how MOSS displays an organization chart based on user data imported from Active Directory. The MOSS object model provides an API to read and modify user profile data from components such as Web Parts, event handlers, and custom workflows.

Figure 5** Org Chart **

As with SPS 2003, user profiles can be extended with custom properties to track user data for domain-specific business solutions. However, MOSS 2007 enhances custom properties by allowing for multivalued properties and properties defined with open or closed vocabularies.

When it's time to write custom code against a user profile, you can program against the UserProfileManager to load and inspect the property values for a specific user. Figure 6 shows a simple example of code written in the RenderContents method for a custom Web Part to display all property values within the user profile of the current user.

Figure 6 Displaying User Profile Values

protected override void RenderContents(HtmlTextWriter writer) { UserProfileManager mgr = new UserProfileManager(); string UserName = Context.User.Identity.Name; if (!mgr.UserExists(UserName)) { writer.Write("User profile does not exist for " + UserName); } else { UserProfile prof = ProfileLoader.GetProfileLoader().GetUserProfile(); writer.AddAttribute(HtmlTextWriterAttribute.Width, "100%"); writer.AddAttribute(HtmlTextWriterAttribute.Border, "1"); writer.RenderBeginTag(HtmlTextWriterTag.Table); writer.RenderBeginTag(HtmlTextWriterTag.Tr); writer.RenderBeginTag(HtmlTextWriterTag.Td); writer.Write("<b>Property</b>"); writer.RenderEndTag(); // </Td> writer.RenderBeginTag(HtmlTextWriterTag.Td); writer.Write("<b>Value</b>"); writer.RenderEndTag(); // </Td> writer.RenderEndTag(); // </Tr> PropertyCollection pc = prof.ProfileManager.Properties; foreach (Property p in pc) { writer.RenderBeginTag(HtmlTextWriterTag.Tr); writer.RenderBeginTag(HtmlTextWriterTag.Td); writer.Write(p.Name); writer.RenderEndTag(); // </Td> writer.RenderBeginTag(HtmlTextWriterTag.Td); writer.Write(prof[p.Name].Value + " "); writer.RenderEndTag(); // </Td> writer.RenderEndTag(); // </Tr> } writer.RenderEndTag(); // </Table> } }

Audience targeting is another valuable feature that has been carried over from SPS 2003. You can create an audience by specifying criteria to define a subset of users. For example, you can create a Sales audience that is defined as all the users who are members of an Active Directory group named Sales. You could define another audience named Carpool as the set of users with the custom Carpool property's value set to True.

Once you have defined an audience, you can then configure a Web Part to conditionally display its content only when the current user is a member of that audience. Audience targeting is a great way to show privileged users links to secured pages while hiding these links from non-privileged users who would receive Access Denied errors when attempting to follow them. This makes it straightforward to target content to those users who need it while hiding that content from users who either don't want to or shouldn't see it.

One more feature carried over from SPS 2003 that is built on user profiles is personal sites. When personal sites are enabled within an SSP, MOSS 2007 will provide each user with his own personal site—a My Site—that is provisioned on demand the first time it is used. Personal sites enable users to edit certain aspects of their user profiles to better describe themselves to their coworkers. A personal site has a public aspect, which makes it easy for a user to share data and documents with other users within the organization. A personal site also has a private aspect, allowing a user to store data and documents that are not meant to be shared.

MOSS 2007 Search

SPS 2003 search makes it possible to search through, not only content and documents within SPS portal sites and WSS team sites, but also through external content such as Windows file shares, public Microsoft Exchange Server folders, and standard Web sites. MOSS 2007 search was designed to give you these same features in a manner that is more performance oriented and easier to configure.

With the previous version of SharePoint, WSS 2.0 and SPS 2003 each used a different underlying infrastructure to support indexing and search. This created problems for companies that upgraded from WSS to SPS. These upgrade problems have been addressed, as the WSS and MOSS search services are now based on the same underlying indexing and search infrastructure, which is an evolved version of what was provided by SPS 2003.

MOSS 2007 search makes it possible to search external content across the network such as Windows file shares and Business Data Catalog (BDC) data, while WSS search is limited to searching within the current site collection. MOSS 2007 search can be configured to run the indexing service and search service on different servers within a farm to increase scalability and throughput. WSS search is limited to running the indexing service and search service on the same physical server.

Configuring MOSS 2007 search is an administrative exercise that entails creating and configuring content sources within the scope of a particular SSP. A content source defines a set of searchable content. When you create a new SSP, MOSS 2007 automatically creates a content source to search through user profile data as well as the content and documents within MOSS and WSS sites in the Web applications associated with the current SSP. However, the SSP administrator must explicitly create and configure additional content sources to support building indexes and searching through external content such as documents in a Windows file share or content from a public Web site.

WSS 3.0 and MOSS 2007 provide a rich user interface for searching by adding search boxes and result pages to each WSS site and MOSS portal site. MOSS 2007 goes even further to supply a dedicated child site named Search Center within a portal site collection that provides a specialized user interface for searching, as shown in Figure 7.

Figure 7** Search Center **

You might conclude that companies can take full advantage of MOSS 2007 search facilities without ever writing any custom code. However, MOSS makes it possible for you customize how search results look by modifying the XSLT transforms it uses to display search results. MOSS 2007 also exposes its search engine through a programmable API that enables you to extend the WSS 3.0 or the MOSS 2007 search service using custom code. For example, you can write a server-side component such as a Web Part or a custom workflow that queries the MOSS search service programmatically and deals with the returned search results in a customized fashion. Likewise, you can create a Windows Forms application that queries the search service from across the network through built-in MOSS Web services.

Business Data Catalog Integration

The BDC is a new framework that provides MOSS 2007 portal sites and standard WSS 3.0 sites with integration into back-end line-of-business systems such as those created by SAP, Seibel, and PeopleSoft. The BDC additionally provides the means to integrate data directly from database systems such as SQL Server and Oracle. While SPS 2003 made it possible to integrate portal sites with back-end systems, it required you to write custom code to manage connections and retrieve the data you needed to display. Furthermore, the required code changed significantly if you switched between back-end systems from vendors such as SAP and PeopleSoft. The Office team designed the BDC to make things much easier.

The BDC enables you to integrate data from back-end systems without requiring custom code for managing connections and retrieving data. The BDC design is based on standardized metadata that describes the location and format of a back-end system and data entities defined within it. The BDC also provides an execution component that is capable of reading BDC metadata and that is able to retrieve external data from back-end systems and return that data to MOSS in a standardized format.

Figure 8 shows the high-level architecture of the BDC. As you can see, connectivity between the BDC and traditional line-of-business systems is achieved by using standard Web services. Connectivity between the BDC and database systems is achieved by using ADO.NET providers.

Figure 8** Accessing Data in Back-End Systems **

The first step in using the BDC is to author an XML file containing the metadata to connect to a back-end system. When you author metadata for the BDC, you define the data you want to retrieve in terms of entities. For example, you might define a customer as one entity and an invoice as another entity. The BDC metadata format also lets you define associations between entities in scenarios when there is a one-to-many relationship such as one that might exist between customers and invoices.

The definition of a BDC entity contains identifiers, properties, and methods. The methods define how the BDC interacts with entry points exposed by the back-end system. For a back-end system accessible through Web services, methods define the names of the Web service operations and the parameters required to call them. For a back-end system that is a database such as SQL Server or Oracle, methods define the names of stored procedure and SQL statements.

Entities can also define actions. A BDC action is used to dynamically parse together the URL behind a hyperlink that allows a user to navigate from a page in a MOSS 2007 portal site to another location. For example, an action defined on a BDC customer entity could be written to redirect users to a Web page in an SAP application that supports updates to customer information. Actions were designed to support scenarios where the BDC is used to display read-only data and to bootstrap the user into another application when updating or some other type of external operation is required.

Once you have the XML file with the required BDC metadata for a back-end system, you must import it into the BDC within the scope of a particular SSP to create what is known as a BDC application. You can accomplish this by using the SSP administrative Web pages. You can alternatively import an XML file with BDC metadata using custom code written against the BDC administrative object model.

Once you have imported the required metadata, there are several out-of-the-box techniques to display the BDC application's data within a portal site. MOSS 2007 ships with a set of Business Web Parts that can be quickly added to pages to query and display BDC data. You can also add new columns to lists and document libraries based on an entity defined in a BDC application. A user editing a column based on a BDC entity is automatically presented with a user interface making it possible to query the back-end system.

The BDC integrates with the MOSS 2007 search service. For example, a back-end system and its entities can be defined as a content source so that the MOSS indexing service will crawl through its data and build indexes for the search engine. This becomes a powerful feature because it allows users to discover data from back-end systems about things like customers and invoices when running standard search queries.

The BDC provides convenient features to map data from a BDC entity to properties in a user profile and to synchronize this data at periodic intervals. For example, if your company has an SAP system that contains employee data you like to include in user profiles, such as phone numbers or social security numbers, you can configure this type of data importing without writing any custom code.

Finally, BDC entities can also be accessed programmatically using custom code written against the BDC object model. This makes it possible to write custom Web Parts as well as other server-side components and services that run their own BDC queries. One nice aspect of writing code to query BDC entities is that you don't have to worry about managing connections or whether you are accessing the back-end system through Web services or ADO.NET. All those details are abstracted away by BDC metadata and the BDC execution engine.

Web Content Management

The Microsoft strategy for publishing content on the Web has been, until recently, based on Microsoft Content Management Server (CMS) 2002. CMS provided a structured way for content authors to add content to a company's public Web site using professionally formatted layout pages. CMS also provided a formalized scheme where a privileged user must approve any page modification before it can be seen by the Web site's visitors. While there is a connector that provides a certain degree of integration between CMS 2002 and SPS 2003, these two products are built on very different architectures, and you cannot build a site that fully benefits from both the CMS Web content management features and the SPS portal features.

With the introduction of MOSS 2007, Microsoft recommends migrating CMS-based Web content management to MOSS. This will obviously have a significant impact on customers who have already become familiar with CMS development. If you have worked with CMS in the past, it's important to note that the CMS concepts of channels and postings are not used in the MOSS 2007 Web content management infrastructure. Instead, the infrastructure has been designed using basic WSS 3.0 building blocks such as child sites, page templates, content types, document libraries, and security groups. This approach lends itself to building custom solutions that extend the basic Web content management infrastructure by using standard WSS components such as custom event handlers and workflows.

When you need to brand a MOSS 2007 portal site, you can modify a single ASP.NET Master Page to customize the appearance of the entire Web site just as you would in a standard WSS 3.0 site collection. However, MOSS 2007 extends this functionality by introducing a publishing scheme based on page layouts. A page layout provides a structured approach to collecting content from content authors and displaying it on a page within a portal site. Some of the page layouts provided by MOSS 2007 include welcome pages, articles, and news items. An example of a page layout in editing mode as seen by a content author is shown in Figure 9. As you can see, page layouts are designed to make it fairly straightforward to add and modify content from within the browser. You might also notice that MOSS 2007 provides a toolbar within the browser to give content authors and approvers a convenient way to move content pages through the editing and approval processes.

Figure 9** Editing Mode **

Each page layout is based on a WSS content type and an associated .aspx page template. By layering page layouts on top of content types, MOSS makes it possible to add custom fields for storing different types of structured content such as HTML, links, and images. Once a custom field is defined inside the content type associated with a page layout, it can be data bound to the associated .aspx page template using another new MOSS 2007 component known as a field control. MOSS 2007 ships with several field controls such as a rich HTML editor as well as others for editing custom fields based on images and links. Many field controls support adding extra declarative constraints to keep portal content within a highly structured format.

Note that the page layout infrastructure is extensible because WSS content types support inheritance. It's fairly straightforward to take one of the built-in page layouts and customize it by extending its underlying content type or .aspx page template.

In addition to field controls, an .aspx page template for a page layout can also contain ASP.NET server controls and Web Part zones. A page layout with Web Part zones provides the content author with the flexibility to add Web Parts displaying content outside the schema of the current page layout. MOSS 2007 provides several Web Parts that have been designed for use in portal pages including the Table of Contents Web Part and the Content Query Web Part.

The .aspx page templates associated with page layouts are stored along with the portal site's Master Page in the master page gallery. The master page gallery also contains a metadata column to associate each .aspx page template with a content type. Note that it is possible to have multiple page layouts, each with its own .aspx page template, that are all associated with the same content type. This is useful when you want to create several different views for the same set of structured content.

Whenever a content author creates a new content page from a page layout, MOSS 2007 creates a new instance of the associated content type and stores it in a document library named Pages. When a content author updates content for custom fields within a page layout, WSS stores the data within a structure defined by the underlying content type. The fact that content page instances are stored in a WSS document library means that the MOSS Web content management infrastructure can take advantage of basic document library features such as versioning, auditing, approval, workflows, per-document security configuration and security UI trimming.

By default, MOSS uses the basic document approval features of a WSS document library to control when the updated content is shown to the site's visitors. However, the infrastructure was designed to make it straightforward to associate custom workflows with the Pages document library for scenarios where you need something more sophisticated than the default content approval functionality.

Note that an instance of a content page stored in the document library does not represent a copy of the page template. Instead, it contains redirection logic to link it with the .aspx page template at run time. That means updating the .aspx page template will always affect content pages that have already been created from the associated page layout.

A number of other MOSS 2007 features focus on Web content management. MOSS provides a framework for document converters, components designed to read content from an external format such as a Word document and convert it into a format that can be displayed within a content page. Several document converters are scheduled to ship with MOSS 2007, as well as a framework for building and integrating custom document converters.

MOSS provides content deployment features that allow you to transfer content from one site collection to another. This is valuable for companies that prefer to author content in a staging environment before moving it into their production environment. You take advantage of MOSS 2007 content deployment features by configuring paths and jobs. A path defines one site collection as a content source and another site collection as a content destination. Once you have defined a path, you can define one or more jobs to move content from the source to the destination. Jobs can be run on demand or they can be scheduled to run at a future time or on a periodic basis.

MOSS 2007 also supports a feature known as site variations for companies that need to duplicate a site's content for translation into multiple spoken languages or for targeting different types of rendering devices. For example, imagine you have configured variation support for German, French, and Spanish. MOSS 2007 maintains a parallel structure across these three different sites with respect to pages and child sites. When a content author adds a new page to the master variation site maintained in Spanish, MOSS automatically adds the same page into the structure of the other sites as well. MOSS can also be configured to create a WSS task marking the required translation as a to-do item for a language translator. While MOSS 2007 will not actually convert your content from one language to another, it does keep multiple sites in sync with respect to their content structure, which provides a good deal of value.

MOSS 2007 provides several caching options. While MOSS doesn't allow you to use ASP.NET output caching directives the same way you do in a standard ASP.NET page, it provides a more sophisticated framework to reach the same end. You can enable MOSS output caching at the site collection scope. When using these caching features, you configure caching profiles to control caching page items and complete pages in memory. Developers should take note that MOSS supplies dedicated caches for navigation nodes and content returned from potentially expensive retrieval operations such as standard WSS queries run using an SPQuery object and cross-site queries run using a SPS SPSiteDataQuery object.

MOSS 2007 also supports Web front-end disk caching. If you enable this cache, MOSS will begin writing the large files it retrieves from the SQL Server database into a special cache on the local file system of the front-end Web server. This procedure eliminates the need to continually move .jpg, .png, gif, .css, and .js files from the SQL Server database server to front-end Web servers on a per-request basis.

Finally, it's important to note that MOSS 2007 publishing sites benefit from WSS 3.0 security advancements. In particular, WSS 3.0 is built on top of the ASP.NET 2.0 authentication provider infrastructure. Unlike SPS 2003, which is tightly coupled to Active Directory, you can configure a MOSS 2007 portal site to use forms-based authentication. That means you can store the user credentials in a SQL Server database or another LDAP identity management system of your choosing.

Business Intelligence Features

SPS 2003, the Office 2003 Web Parts and Components Add-in, and Business Scorecard Manager all provided customers with important business intelligence (BI) features. Developers have used these BI technologies as a platform for building dashboard-style applications that provide upper-level management with up-to-date data that reflects the health of a business and flags potential problems in a timely matter.

Based on their experience with these earlier BI components, the Office team designed MOSS 2007 to include a next-generation platform for building dashboards and integrating with other technologies such as Microsoft Excel 2007, SQL Server Reporting Services, and SQL Server Analysis Services. As with all other aspects of MOSS 2007, its BI platform builds on top of ASP.NET and WSS 3.0 and provides many opportunities for extending the default functionality.

Consistent customer feedback indicated that a large percentage of corporations maintain a significant amount of business logic in Excel workbooks, and that this business logic has been hard to reuse across a large organization. This feedback led the Office team to create MOSS 2007 Excel Services, a server-side version of the traditional Excel calculation engine that has been rewritten from the ground up on top of WSS 3.0. Excel Services doesn't suffer from the same types of scalability problems that occur when you run the desktop version of Excel on the server.

Excel Services also provides a server-side rendering engine that can display worksheets in the browser as HTML. That means a company can store its Excel workbooks in a centralized document library and make them viewable by users who don't even have Excel installed on their desktops. Furthermore, users can see the numbers displayed by a worksheet within the browser without having any access to the business logic behind it, thereby protecting a company's intellectual property.

The 2007 Microsoft Office system introduces a new paradigm, recognizing that companies maintain business logic within Excel just as they maintain business logic within compiled assemblies or SQL stored procedures. To support this new paradigm, the Office team added many new features to the 2007 Office system products designed to expose and update this business logic as well as to protect the intellectual property represented by this logic.

The desktop version of Excel 2007 has been enhanced to allow information workers with Excel expertise to publish and update their workbooks in a document library within an MOSS 2007 portal site or a WSS team site. Users running Excel can view these workbooks through the familiar client experience while other users can rely on Excel Services to view the same workbook inside the browser. Note that this new workbook publishing metaphor allows a company to maintain a single master copy of its critical workbooks. It also allows the workbook author to post updates without the need to involve the development or IT staff.

It's important to note that the use of Excel Services isn't restricted to the browser. You can create a Windows Forms application that uses the server-side Excel calculation engine but that doesn't use the rendering engine. For example, a Windows Forms application can use Web services from Excel Services to load a workbook on the server, enter input data, perform calculations, and return a result as shown in Figure 10.

Figure 10 Calculating with Excel Services

// Create instance of proxy from ExcelService.asmx ExcelService ws = new ExcelService(); // Set up authentication ws.Credentials = System.Net.CredentialCache.DefaultCredentials; // Open the Excel workbook on server Status[] status = null; string sessionID = null; sessionID = ws.OpenWorkbook( textBoxURL.Text, "en-US", "en-US", out status); // Assign the cell values for input data status = ws.SetCellA1(sessionID, "Mortgage Calculator", "CustomerName", textBoxCustomerName.Text); status = ws.SetCellA1(sessionID, "Mortgage Calculator", "MortgageAmount", textBoxAmount.Text); status = ws.SetCellA1(sessionID, "Mortgage Calculator", "InterestRate", textBoxInterestRate.Text); status = ws.SetCellA1(sessionID, "Mortgage Calculator", "MortgageLength", textBoxLength.Text); // Perform server-side calculation status = ws.CalculateWorkbook(sessionID, CalculateType.Recalculate); // Show the result object result = null; result = ws.GetCellA1(sessionID, "Mortgage Calculator", "Payment", true, out status); if (result != null) MessageBox.Show("You pay " + result.ToString()); // Close workbook status = ws.CloseWorkbook(sessionID);

You can see it's not that hard to take advantage of formulas in Excel spreadsheets from across the network in a desktop application. This example furthers the analogy that Excel Services exposes the business logic defined in a workbook just as SQL Server exposes the business logic defined in a stored procedure.

MOSS 2007 provides a special site template named Report Center for companies that want to build dashboard-style applications. Report Center was designed to make the new BI features of MOSS 2007 easy to discover and use. A Report Center site contains a document library named Reports Library that is tuned for storing and displaying BI reports such as Excel workbooks and reports built for SQL Reporting Services.

Another important aspect of Report Center is the built-in support for creating and importing key performance indicators (KPIs), visual BI indicators that tell a manager how some aspect of the business is doing. For example, the KPI for a product inventory level might display a green light when there is enough inventory to supply all the orders for the coming week. However, the light might turn from green to yellow when the inventory level drops below some predefined threshold such as the amount of inventory required to supply orders for the next four days. The light then might change from yellow to red when the inventory level drops to a point where it will run out within the next 48 hours. The main idea is that a KPI flags business problems that require immediate attention.

MOSS 2007 provides out-of-the-box support for several different KPI types. For example, you can create a KPI whose indicator changes automatically depending on data it reads dynamically from a WSS list or an Excel workbook. MOSS also provides integration support for KPIs in SQL Server 2005. That is, if you have already created KPIs with SQL Server Analysis Services, you can import and display them on a Report Center site alongside other supported KPIs.

The last aspect of Report Center I want to discuss is the built-in framework for filtering data before it's shown to the user. This is a key component of the MOSS 2007 dashboard framework because it makes dashboard pages more relevant to the user. When a manager visits a Report Center site, the experience is enriched if the dashboard views have been customized with data that is relevant for that particular manager. For example, a sales manager for the Eastern region can be presented with a different view of sales figures than the sales manager for the Western region. Furthermore, managers like to be able to see high-level data at first and then drill down into more specific categories on demand.

Filtering support is built into MOSS 2007 dashboards at the page level using Web Part connections. MOSS supplies Web Parts that allow page designers and users alike to specify criteria such as the name of the current user, a date range, or a product category. There are also many supplied Web Parts that can be configured to consume the filtering criteria supplied by other Web Parts such as the standard WSS List View Web Part as well as the Web Parts designed for use with the BDC, Excel Services, SQL Reporting Service, and SQL Analysis Services.

Managing Documents and Business Processes

In past versions of Word, Excel, and PowerPoint®, Microsoft relied on a default file structure based on binary files written in a proprietary format. These formats have been very hard to read and modify unless you go through the object model of the hosting Office application, such as Word and Excel. As a result, companies have tried to run Office desktop applications on the server, which poses problems with scalability and robustness.

Office 2000 and Office 2003 added some modest capabilities for creating Excel workbooks and Word documents using XML. In the 2007 Office release, Microsoft takes this idea much further by adopting the Office Open XML File Formats for Word, Excel, and PowerPoint documents. These formats use a new file standard for creating composite documents containing multiple inner XML files that factor out content from other aspects of the document such as formatting instructions, data, and code.

The top-level file in the Office Open XML File Formats is known as a package and it is structured using standard XML and ZIP technologies. The internal files contained within a package are known as parts. Many parts within Word, Excel, and PowerPoint files contain XML structured in accordance with published XML schemas. Other parts within a package can consist of binary files for items such as graphics, audio clips, and video.

A major goal of the Office Open XML File Formats is to provide a standard approach for reading, manipulating, and generating documents in server-side scenarios where using the object model of a desktop application such as Word or Excel isn't a viable option. Think about a scenario in a MOSS portal site when you have created and configured an event handler to fire whenever someone uploads a new Word document. The new Office Open XML File Formats make it significantly easier to extract data or to perform hygiene on the document such as removing comments and personal information. You can also use Office Open XML File Formats to develop server-side components that generate Office documents on the fly using data pulled from content sources such as a WSS list or the BDC.

To get started working with the Office Open XML File Formats, you need to learn how to program against the new WinFX® packaging API. You must also learn the specific package structure and XML schemas for the type of Office document you are working with. Some of these details will change as you move between Word, Excel, and PowerPoint documents. Microsoft has started a developer community effort around the Office Open XML File Formats at openxmldeveloper.org.

InfoPath Forms Services

Since the introduction of Office 2003, many companies have found that InfoPath® provides a quick and efficient solution for creating electronic input forms to collect XML-based data from users. The InfoPath forms designer provides high levels of productivity because it significantly reduces or eliminates the need to write custom code when developing forms. InfoPath also creates a very reliable way to collect data because InfoPath forms are built on top of XML schemas, allowing them to automatically validate the user's input.

InfoPath 2003 provided a convenient integration point with WSS 2.0 where a form designer could publish an InfoPath form on a WSS site, creating what is known as a forms library. A forms library is a hybrid WSS document library that uses an InfoPath form template as its underlying document template and acts as a repository for XML documents containing form data entered by users.

One common complaint that Microsoft received about this forms-based technology is that it required a full installation of InfoPath on the user's computer. This was true not only for those designing forms, but also for any users who needed to read or modify data in an InfoPath form. The problem was that the features of InfoPath 2003 did not extend to users for whom deploying Office 2003 on their desktop wasn't an available option.

MOSS 2007 introduces InfoPath Forms Services to solve this problem. Forms Services renders InfoPath forms within the browser to reach users who are not running InfoPath. In fact, Forms Services doesn't require Internet Explorer® or even Windows on the user's system. The Office team is actively testing Forms Services for compatibility with browsers such as Firefox, Safari, and Netscape as well as several HTML-enabled mobile devices.

You can use the InfoPath 2007 form designer to create Web-enabled forms, which can then be deployed to Forms Services. The form designer provides a compatibility checker to ensure that your forms contain only controls and elements that are compatible with what Forms Services can render to the browser. It's also possible to create and deploy InfoPath forms intended for dual use. Such a form is downloaded to the desktop and loaded into the client environment when InfoPath is available or rendered through the browser when InfoPath is not installed.

ECM and Single Sign-On

Government and other regulatory requirements, such as the Sarbanes-Oxley Act and emerging privacy laws, make compliance ever more complicated for companies that generate and store large numbers of documents. MOSS 2007 provides several Enterprise Content Management (ECM) features that can help address these problems. Many of these ECM features are built on top of the new information policy feature, which is a WSS component that can be enabled and configured within the scope of a list or document library. Default examples that ship with MOSS 2007 include information policies for document expiration, auditing, and the automatic generation of bar code labels to identify physical documents and associate them with electronic copies maintained in a document library.

The WSS framework for information policies was designed with extensibility in mind. For example, you can create a custom policy that checks the integrity of a digital signature on every document within a document library. You can create another policy that promotes document hygiene and privacy by removing all the comments and personal information from documents as they are uploaded to a document library.

MOSS 2007 provides a dedicated site template named the Records Repository. A Records Repository site provides archiving support for companies that are required to keep certain types of business documents as official records of the company's activities. While requirements vary across different regulated industries, keeping records is required to provide evidence of a company's activities in the event of litigation or an audit.

The final topic I would like to cover is the SSO service, an enhanced version of the credential-mapping service that ships with SPS 2003. SSO is used to map the identity of a user who has logged on to a MOSS 2007 portal site with another identity for the same user in a back-end system. For example, imagine a user named Bob has two user accounts. First, he has a Windows account in Active Directory that he uses to log on to the local network and authenticate against the MOSS 2007 Web server. Bob also has a second user account with different credentials that needs to be used when accessing the company's back-end SAP application.

SSO solves the problem of allowing server-side code running on behalf of Bob to seamlessly access the SAP system using his secondary account once he has logged on to the portal site using his primary Active Directory account. SSO accomplishes this by providing a credential-mapping database to store his SAP user name and password in an encrypted format. SSO also provides the means for custom Web Parts and other MOSS 2007 services such as the BDC, Excel Services, and Forms Services to retrieve user credentials that are required when accessing various back-end systems.

Wrapping It Up

The article has provided a broad survey of the most significant services and features provided by MOSS 2007. You have seen the investment in functionality for areas such as portal and search, Web content management, business intelligence, business process management, and enterprise content management. You have also seen that MOSS 2007 promotes an "assemble and configure" philosophy that enables you to construct rich business solutions without ever starting Visual Studio or writing a line of managed code. However, remember that MOSS 2007 is built on top of ASP.NET 2.0 and WSS 3.0, providing ample opportunities for extending standard functionality with custom components such as Web Parts, event handlers, workflows, page layouts, document converters, and server-side forms.

Ted Pattison is an author, trainer and SharePoint MVP who lives in Tampa, Florida. Ted is writing a book titled Inside Windows SharePoint Services 3.0 for Microsoft Press and he delivers advanced SharePoint 2007 Training to professional developers through his company, Ted Pattison Group (https://www.TedPattison.net).