Building Office Business Applications

Summary

The 2007 Microsoft Office system provides a set of servers, clients, and tools to make it easier for enterprises and software vendors to build and deploy composite applications in the enterprise. These solutions, called Office Business Applications (OBAs), are quick to build and deploy; empower end users through extensive personalization capabilities; are easy to change when business needs require; and are built using familiar Microsoft Office tools and applications. This paper shows how to architect composite applications, and how the 2007 Microsoft Office system provides a good platform�familiar to end users�for building such applications.

Contents

What Are Composite Applications?
The 2007 Microsoft Office System as a Platform for Building Composite Applications
How Office Business Applications Are Composite Applications
Building an Office Business Application
Building Departmental SharePoint Sites to Host Local Documents and Processes
Conclusion
About the Author

Globalization, specialization, and outsourcing require people to work in more collaborative ways than before. This trend requires a matching change in the tools that information workers use to gain insight, collaborate, make decisions, and take action. Today, most business applications are effective at automating transactions, but do not enable rich collaboration across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this in turn leads to a loss in productivity, as users are forced to cross from one set of tools to another, often manually moving the data through means such as cut-and-paste. These gaps between different business applications and productivity tools need to be bridged for information workers in a way that is seamless, synchronized, and secure.

There really has not yet been an effective way to enable composition of business applications in a way that is contextual, collaborative, easy to use, role-based, and configurable to pull in other platform technologies that are needed for building these kinds of composite applications. Ease of use is important, as the platform, tools, and architecture for composition should not introduce unreasonable technical complexity that requires radical retraining of people.

What Are Composite Applications?

A composite application is a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities.

In the past, an enterprise's software assets usually consisted of independent business applications that were monolithic and poorly integrated with each other. However, to get the business benefits of composition, an enterprise must treat its software assets in a more granular manner, and different tiers of architecture will require such varying assets as presentation, application, and data assets. For example, a Web service might be an application asset, an online analytical processing (OLAP) cube might be a data asset, and a particular data-entry screen might be a presentation asset.

An inventory of software assets by itself does not enable composite applications. This requires a platform with capabilities for composition�that is, a platform that provides the ability to deploy assets both separately and in combination with each other. In other words, these assets must be components, and the platform must provide containers (Figure 1).

Figure 1. High-level representation of a composite application

Containers provided by the platform need to be of different types, which map to the different tiers in the architecture. Enterprise architectures are usually decomposed into three tiers: presentation, application (or business logic), and data. So the platform needs to provide containers for these. However, the three-tier architecture assumes structured business processes and data, where all requirements are made known during the process of designing and building the system. By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed�and so need to explicitly account for people-to-people interactions among information workers that are essential to complete any business process. Usually these interactions are not captured by structured processes or traditional business applications; therefore, it is critical to add a fourth tier�the productivity tier�to account for these human interactions. This is shown in Figure 2.

Figure 2. The four tiers of a composite application

Traditional discussions about the architecture of business applications tend to focus on the application tier as being the connection between people and data. Typically, however, the application tier contains structured business logic, and this holds for discussions about Service-Oriented Architectures (SOAs), Enterprise Service Buses (ESBs), Service Component Architectures (SCAs), and most other architectural perspectives in the industry today, including first-generation discussions about composite applications. However, building a composite application requires the architect not only to consider the productivity tier a critical element of the stack, but also to recognize that it contains the most business value.

To expand on the comparison between composite applications and SOA: Both of them target flexibility and modularization. However, SOA provides flexibility at just one tier: the structured business logic in the middle tier. Composite applications target flexibility at all four tiers. That said, a composite application is a great way to extract information from an SOA, and having line-of-business (LOB) applications exposed as services makes it easier to build support for cross-functional processes into a composite application.

Therefore, to design a composite application, a solutions architect must:

• Choose a composition stack. Pick one or more containers from each tier, and a set of component types that are deployable into those containers.
• Choose components. Define the repository of assets that must be built from this set of component types, based on business needs.
• Specify the composite application. Define the ways in which those assets will be connected to provide a particular cross-functional process. The platform should enable these connections to be loosely coupled.

After deployment, users will have the opportunity to personalize both assets and connections, and the composition stack should enable this through loose coupling and extensibility mechanisms.

The 2007 Microsoft Office System as a Platform for Building Composite Applications

The 2007 Microsoft Office system is such a platform for building composite applications�which are called Office Business Applications (OBAs).

Figure 3. Capabilities provided by the 2007 Microsoft Office system

How Office Business Applications Are Composite Applications

Let us now look at each of the tiers in Figure 2, and examine the types of containers and component types that the platform provides.

Table 1. High-level 2007 Microsoft Office system capabilities

Composition in the Presentation Tier

The first type of container in the presentation tier is the Microsoft Office client application (Excel, Word, InfoPath). These applications are customizable containers that can now more easily extract information and functionality from LOB applications through custom task panes, custom ribbons, and actions that present users with data and actions in the context of their current activity. The component type that can be hosted within these containers is the Open XML document. This is the new XML representation for Microsoft Office documents�which enables rich server-side processing of information stored within. This is shown in Figure 4.

Figure 4. Office client applications are customizable containers for Open XML content.

The second type of container is a Web portal, as enabled by Windows SharePoint Services (WSS), and Microsoft Office SharePoint Server (MOSS). WSS v3.0 provides the following hierarchy of containers, as shown in Figure 5:

• Farm�Installation of one or more load-balanced Web servers, and back-end servers, with a configuration database.
• Web Application�IIS Web site, extended to use WSS, which can host site collections.
• Site Collection�Container for WSS sites, which exists within a specific content database. A site collection contains a top-level site and optional child sites, and is the unit of ownership, securability, and recoverability.
• Site�Container for child sites, pages, and content such as lists and document libraries.
• Page�Container for Web Part zones, and Web Parts.
• Web Part Zone�Container for Web Parts.
• Web Part�Components that display content on a page in modular form and are the primary means for users to customize/personalize pages.

Figure 5. Containers provided by Windows SharePoint Services (Click on the picture for a larger image)

While WSS provides support for building collections of sites for team collaboration, MOSS enables portal functionality on top of WSS, with additional capabilities. For example, MOSS comes with capabilities for enhanced searching, connectivity to business data stores, and Business Intelligence. However, a MOSS portal is a WSS site collection, and so is a hierarchy of WSS sites. MOSS also comes with a Web Part gallery that contains a rich set of Web Parts out-of-the-box, for example to extract Microsoft Office Excel spreadsheets and charts. Solution providers can also provide their own custom Web Parts for application-specific or domain-specific functionality�which can then be uploaded into WSS. Information workers can personalize pages by adding Web Parts from the gallery, removing Web Parts from a page, or rearranging the layout.

Composition in the Productivity Tier

The 2007 Microsoft Office system provides a number of different ways to share information and collaborate on using it. For example, server-side storage provides containers for in-process documents, and other kinds of heterogeneous content with version-control. This allows for collaboration in unexpected or unplanned situations. It is hard to capture all the complex people interactions in a business process management (BPM) system, as work usually never happens as planned. In traditional three-tier architectures, there is little support for this beyond storage of in-transit documents on personal hard drives or e-mail servers, and it can sometimes be hard to decide which document is the correct version. However, the 2007 Microsoft Office system can set up versioned document libraries to store documents at the intermediate stages of a business process, which improves manageability, and also improves the likelihood of graceful recovery from unplanned events. WSS provides the following types of storage:

• List�Container for items, which could be from built-in list types, or from custom list types. Traditionally, this has been the atomic unit of storage, but now a list can store huge amounts of data, such as knowledge bases or Web content. There is also built-in index and query support.
• Document library�Special types of lists that support versioning and source-control of documents. For example, InfoPath forms may be stored in forms libraries, reports in report libraries, and other documents in document libraries.

Figure 6. SharePoint Workflow Architecture (Click on the picture for a larger image)

Information workers can add document libraries themselves and specify particular document templates to be used by all documents in those libraries. For example, a business analyst might use the InfoPath WYSIWYG design tool to create a form, and then use that form as a template to create a forms library. Whenever users create a new document within that library, this template will be used to create an empty form. The 2007 Microsoft Office system also has built-in, server-side support for Windows Workflow Foundation (WF). The WF run-time engine is hosted within MOSS and acts a container for business logic that can be attached to work items and documents in the form of workflows. These workflows may be associated with lists, document libraries, or with particular content types. They are started and completed by user actions, and are managed using WSS task lists. For example, workflow activities create and update task items as required, and users can track workflow progress through history tables. 2007 Microsoft Office client applications are also workflow aware. They can be used for workflow initiation, configuration, completion, and also ad-hoc customization (forwarding/delegation).

Workflows can be associated with lists, document libraries, or particular content types. These associations to WF templates are tracked in a farm-wide workflow association table. WF templates are defined by XML metadata and can include both workflow assemblies and forms. For example, when users create a document library, they can choose to associate that library with a particular workflow and specify the conditions under which the workflow gets triggered (for example, a document in a given library might have been modified or created). This workflow could support a particular business process or support document life-cycle management.

Integration of the 2007 Microsoft Office system with WF provides a variety of benefits (Figure 7). Simple business processes can be automated in a way that is seamlessly integrated into the SharePoint UI. Users are empowered through self-service capabilities, such as support for a broad range of user-controlled document routing and tracking scenarios, in a way that reduces the involvement of IT staff in putting together simple applications. WF also provides vertical solutions providers with an extensibility point to deploy their own business rules and logic into the containers provided by the 2007 Microsoft Office system.

Figure 7. Workflow hosting with WSS (Click on the picture for a larger image)

Finally, the productivity tier must also provide a lightweight way to create and publish information and reports. This is supported by the 2007 Microsoft Office system, which integrates into SQL Server Reporting Services and provides the following components:

• Report Center�A template to create WSS reporting sites.
• Report Library�A document library with special support for storing reports.
• Dashboard�A WSS page assembled from reporting Web Parts.
• Report Viewer�Web Part to view reports made available from SQL Server Reporting Services.
• Web Part�For viewing Excel graphs and tables.
• KPI (Key Performance Indicator) Web Part and List�Information workers can choose to source metrics for this in several ways.

A dashboard might be provided to users as a reporting template built around a specific business function, such as sales, marketing, or inventory management.

Composition in the Application Tier

Typically, structured business logic lives within the application tier. This might be an LOB application such as an Enterprise Resource Planning (ERP) system, or an orchestration across multiple systems such as a BPM system. The application tier will typically include both transactional systems and decision-support systems. There are multiple ways for OBAs to enable composition in the application tier, as well as to consume composite services exposed by other platform technologies (Microsoft and non-Microsoft).

The first level of composition in the application tier is through packaged activity libraries created using Workflow Foundation, and deployed into the 2007 Microsoft Office system. Previously, we discussed how workflows can be attached to lists, document libraries, and particular content types. Figure 7 shows how the WF run-time provides a container for application-specific activities that are packaged and deployed as activity libraries, and on top of which workflows are assembled.

The second level of composition in the application tier provided by the 2007 Microsoft Office system is through Excel Services. This is a server-side Excel calculation engine that is built into SharePoint Server. It provides browser access to live, interactive spreadsheets that are deployed on the server, and also Web service access to server-side Office Excel calculations. With Excel Services, existing Excel power users can now provide server-side application logic in a way that is familiar to them. This means that MOSS is now a container for application logic, as shown in Figure 8.

Figure 8. Excel Services in the 2007 Microsoft Office system

A third way for OBAs to enable composition in the application tier is to consume composite services exposed by other platform technologies. The 2007 Microsoft Office system can be plugged seamlessly into a services-oriented architecture. If the enterprise has a services backbone already under development, these interfaces can be consumed from the 2007 Microsoft Office system. This can be done in a couple of ways. The first is by invoking Web service interfaces in activities that have been built into workflows deployed into the productivity tier. The second is through the Business Data Catalog (BDC), which is described in the next section.

Composition in the Data Tier

The 2007 Microsoft Office system also comes with a Business Data Catalog (BDC) that runs within the server as a shared service. It can read data from multiple types of data sources�databases, analysis services cubes, and Web services�and then display this data in the portal through SharePoint tables and lists. This acts as a metadata repository for descriptions of business-data entities and their attributes, and for mapping these entities back to data stores within the enterprise, as shown in Figure 9.

Figure 9. Business Data Catalog (BDC)

While the BDC cannot be used to create an entity that maps across multiple data stores, it is possible to define relationships that link entities�such as parent-child relationships. So, the BDC can be used to create lightweight linkages between data entities across the enterprise�almost like an enterprise thesaurus. BDC-defined entities can then be plugged back into the 2007 Microsoft Office system, for example in SharePoint lists. This allows users to compose pages with linkages to back-end data and to traverse data tables by following relationships between entities.

Although the BDC enables data composition, it provides read-only access to data. However, users can use the BDC to model actions that can be taken on a data entity, where an action is defined by a name, a URL, and a set of attributes from the entity definition to be passed back to this URL. This can then be used from within a dropdown menu on a SharePoint list. The URL can correspond either to a Web service or to a server-side document such as an InfoPath form, with code-behind to pre-populate the form from the context that gets passed in from the BDC. Information workers can then use the portal to create lightweight applications in SharePoint with tables and lists that extract BDC data and actions.

Summarizing capabilities for composition

Figure 10 shows how some of the capabilities of the 2007 Microsoft Office system map to the tiers in Figure 2. Table 2 provides a list of asset types that are candidates for composition.

Figure 10. Capabilities of the 2007 Microsoft Office system application platform, mapped to tiers (Click on the picture for a larger image)

Table 2. List of application assets for composition

Building an Office Business Application

There are two steps to building a standard business process as an OBA.

1. Build a process pack, which contains process metadata, and packaged application components.
2. Deploy the process pack onto production systems. Both of these steps are described in detail in the following section.

Build a Process Pack

1. Build user interfaces for document-centric processes into Microsoft Office client applications, using Visual Studio Tools for Office (VSTO).
2. Build WSS sites with task-specific Web Parts, pages, dashboards, lists, and document libraries, where each site is designed for a particular business function or process. These sites can be used to create site templates for packaging a standard business process into an OBA solution.
3. Use Workflow Foundation to wire together lists and document libraries in the sites, with server-side rules and business logic for server-side processing of in-process documents. Package these workflows into assemblies for deployment.
4. Define touch points from workflows in the OBA to back-end LOB systems. The process pack metadata should include the Web services interfaces for this integration. The actual connections will need to be made during the deployment phase.
5. Define BDC entities for data connections required for cross-functional processes built into the OBA.
6. Add decision support by defining metrics, reports, dashboards, and Excel charts and tables to be used by the WSS sites.
7. Package solution as a process pack (WSS site templates, WF assemblies, Office documents, and so forth) using the component types in Table 2.

Deploy Process Pack to Production Systems

1. Deploy WSS sites to the SharePoint server on the production system.
2. Configure connections from workflows to LOB applications using Web services�or other custom adapters.
3. Configure data connections by connecting BDC data entity definitions to actual data stores.
4. Provision users.

Deploy a Composite Application in the Enterprise

One way to deploy an OBA in the enterprise might be as follows:

1. Deploy SharePoint sites at the departmental levels.
2. Connect multiple departments.
3. Connect business processes to LOB applications.
4. Add data connections for cross-functional processes.
5. Connect business processes to systems "at the edge."

Building Departmental SharePoint Sites to Host Local Documents and Processes

SharePoint sites must be set up at the departmental level to enable team collaboration, as shown in Figure 11. These sites will have document libraries to store in-process documents. Information workers on the team will have their own personalized pages, customized from the templates available on the team site.

Figure 11. Provision OBAs in departmental sites for team collaboration, coordinate activities with business-process models, and connect to LOB systems through a services backbone.

Note that Figure 11 is a logical view of the architecture, as all these departmental sites would not typically be running on separate servers. Instead, multiple sites could be running on a single server in line with Figure 5, and the physical architecture (that is, the deployment landscape for SharePoint servers) would be chosen based on other factors like load, availability, and geographic dispersion of teams.

In-process documents are stored in document libraries and are associated with workflows that get invoked whenever a document is created or edited. Such a workflow might run validation rules on documents; apply approval policies and actions to the data; cleanse, validate, or filter the data contained within; or update back-end systems.

In addition to business process workflows, in-process documents undergo a life cycle of their own, from authoring and collaboration through management and publication, to archiving or destruction. Whenever a document reaches one of these stages, the appropriate workflow can be set to be triggered, such as for managing the archival process.

Connect Multiple Departments

As shown in Figure 11, business-process models coordinate activities both within a team and across departments. Within a department, business processes can be modeled using WF activities that are deployed into the SharePoint server that is supporting that department. Coordination of activities across departments can be accomplished using collaboration processes that manage the life cycle of individual business entities (orders), and also the life cycle of business processes (procure-to-pay).

The interdepartmental business processes could either be located centrally in IT data centers, or closer to the information workers within the departmental servers. For example, long-running workflows running centrally might be running on Microsoft BizTalk Server, whereas departmental processes would be running in WF workflows within the SharePoint server.

Connect Business Processes to Line-of-Business Applications

Service orientation is one of the ways to expose current business applications into an OBA.

In that sense, SOA promotes modularization which is a basic requirement for composition, and SOA are complementary solutions. new cross-functional business applications boundaries of current applications.

SOA is not the only way to connect LOBs to OBAs. A services backbone can also be exposed using other integration technologies, such as custom adapters.

Add Data Connections for Cross-Functional Processes

The BDC (Figure 9) can be used to connect back-end data stores to the 2007 Microsoft Office system by displaying data in SharePoint lists and Web Parts. This makes it possible to build composite applications for cross-functional processes into the SharePoint portal, using a combination of BDC, SharePoint lists, and Workflow. For example, the BDC can be used to define entities that have a parent-child relationship (such as order header and order details), and SharePoint lists could display them. It would be possible to drill down from the list displaying header information, to the corresponding details information, by following the parent-child relationships. Furthermore, actions can be modeled in BDC metadata, which means that these are displayed as menu items on the SharePoint list and selecting a dropdown from this menu will mean that context from the currently selected row will be passed into the URL defined for the action.

Connect Business Processes to Edge Systems

Often the scope of an OBA is not contained within an organization. For example, an OBA might support a business process that needs to consume a service that is offered by a hosting provider (Software as a Service�SaaS�scenario). Alternatively, the OBA might need to support a business process that offers a service to another organization. This is especially common in supply chain management scenarios, where trading partners are involved. Here, there needs to be a way to transfer documents from one information worker to a counterpart in the trading-partner organization. This needs to be secure, reliable, asynchronous, and transparent.

One way of putting together an end-to-end architecture for this is shown in Figure 12. Message brokers have been set up at the edge of the organization to send and receive messages and documents from trading partners. Messages from different trading partners can potentially be received in multiple message formats and delivered over multiple channels, such as Web services, EDI, e-mail, RosettaNet, and so on. Furthermore, messages can be exchanged in a variety of different patterns: one-way, asynchronous two-way, or synchronous two-way messaging. These message brokers must handle each combination of these message interchange patterns and message formats.

Figure 12. Connecting the OBA to systems at "the edge"

After the message is received by the message broker, it is processed into the single canonical format that is required for downstream services, and the transformed message is persisted to a message queue to decouple public processes from private ones. Next, the message is retrieved from the queue by a routing service that examines the message and routes it to the intended recipient. But before the document reaches its intended recipient, it might have to be preprocessed by enterprise application services such as LOB applications, or BPM orchestrations. Business rules might be applied to messages, to ensure validity and to enforce corporate policies. The result of all this processing is a document that can be processed by a human with enough information to make a quick decision. For example, a purchase-order request from a customer might be fed into an order-promising service, and the response from this service might be used to generate an XML document that corresponds to an InfoPath form with a candidate PO Confirmation. Next, this generated form might be placed into a SharePoint forms library for an information worker in the sales department to approve.

After the information worker has reviewed the proposed confirmation and made changes if necessary, the worker submits the form. This kicks off the workflow for the return trip, which updates LOB systems and then posts the information from the form as an XML document into a queue for outbound messages as a response to the original request. The message broker then converts back into the format used by the trading partner.

There are multiple ways to implement the message brokers at the edge, such as BizTalk Server. This would provide a scalable and manageable solution that would also come with standards-based accelerators and adapters, such as the RosettaNet accelerator for trading partner collaboration. The queues that decouple internal and external processes could be implemented using Microsoft SQL Service Broker 2005.

Sample Office Business Application

To provide technical resources and guidance on building OBAs with meaningful business value, a reference implementation for an OBA is available online here. This reference application pack for supply-chain management covers scenarios for collaboration between the different levels of a multi-tier supply chain.

Conclusion

The 2007 Microsoft Office system provides a powerful set of capabilities to build composite applications, which are called Office Business Applications (OBAs). This enables cross-functional solutions offering a composite user interface that exposes business functions and capabilities across a heterogeneous set of back-end IT assets. These solutions also provide collaborative business capabilities that span the gap between traditional business applications and personal productivity tools.

For More Information

More information about architecting and developing Microsoft Office Business Applications is available at:

http://msdn.microsoft.com/oba and

http://msdn.microsoft.com/architecture/office