Chapter 27: Designing Office Business Applications

For more details of the topics covered in this guide, see Contents of the Guide.

Contents

• Overview
• Key Scenarios for Office Business Applications
• Common OBA Patterns
• General Design Considerations
• Security Considerations
• Deployment Considerations
• Relevant Design Patterns
• Additional Resources

Overview

This chapter introduces Office Business Applications (OBAs), and shows a typical OBA architecture with the relevant components. It also describes typical scenarios where OBAs are a suitable choice, and provides guidance on design considerations and important patterns for OBAs. Additionally, it provides information on integration of OBA with Microsoft Office SharePoint Server (MOSS) and line-of-business (LOB) applications

OBAs are a class of enterprise composite application. They provide solutions that integrate the core capabilities of networked business systems with the widely deployed and widely used business productivity services and applications that constitute the Microsoft Office System. OBAs implement business logic that is maintained through end user forms, providing a rich user experience that can help to improve business insight and assist in integrating existing internal or external systems.

OBAs usually integrate with new and existing LOB applications. They leverage the rich UI and automation capabilities of the Office clients to simplify complex processes that require user interaction, and help to minimize errors and improve processes. Effectively, OBAs use the Office client applications to fill the gaps between existing LOB systems and users. Figure 1 illustrates the key components and layers of an OBA. One thing to note is that this diagram includes a layer named Productivity between the Presentation and Application Services Layers. The Productivity layer contains components used to store and manage collaborative work streams in a document-centric manner.

Figure 1

Key components of an OBA

Components of an Office Business Application

An OBA is made up of a variety of applications and services that interact to provide an end-to-end solution to a business problem. It may contain or be created using any or all of the following items:

• Microsoft Office client applications. The client applications include Outlook® messaging and collaboration client, Word, Excel, InfoPath® information gathering program, and PowerPoint® presentation graphics program. Custom forms in Outlook can be used to host UI controls with the ability to integrate business logic and data from various sources. Word and Excel offer programmability in the form of the Task Pane, Smart Tags, and the Ribbon. This makes it possible to combine natural document interactions with structured business data and processes. Smart Tags use regular expression pattern matching to recognize identifiers such as telephone numbers, government identification numbers, or custom account numbers within the text of a document. Relevant actions can be presented in the document alongside the data.
• Windows SharePoint Services (WSS). Built upon Windows Server, WSS provides content management and collaboration features that can help to improve business processes and team productivity. OBAs can use WSS to store and share documents, forms, and lists; and support offline synchronization and task management.
• MOSS. MOSS extends the capabilities provided by WSS to offer enterprise-wide functionality for content management, workflow, search, portals, and personalized sites. OBAs can use MOSS for these features, as well as using Excel Services for reporting, the Business Data Catalog (BDC) for LOB access, and a security framework for single sign on (SSO) capabilities.
• Technologies and services. Excel Services allow documents to be authored by clients using Excel in the usual way, and then saved to SharePoint Server. End users can view and interact with the documents in a Web browser, and software developers can programmatically invoke business logic stored within the documents. OBAs can also use Windows Workflow Foundation (WF) functionality that is built into MOSS to capture a process, such as a purchase order approval, and reduce user errors and associated delays. In addition, they can use ASP.NET Web Page and Web Part rendering to create customized Web sites that reflect the company's requirements.
• Collaboration features. Collaboration can be managed by Microsoft Office Communications Server (OCS), Microsoft Office Groove® software, and Microsoft Exchange Server.
• Development tools. These include SharePoint Central Administration, SharePoint Designer, Visual Studio, and Visual Studio Tools for Office.

Key Scenarios for Office Business Applications

OBAs are designed to interoperate using open standards, standard file formats, and Web services. The metadata definitions of OBA solution objects are based on XML schemas. All Microsoft Office products are service-enabled at all levels, and use interoperable OpenXML file formats as the default schemas for business documents they create. OBAs generally fall into one of three categories that implement key scenarios. These categories, described in the following sections, are:

• Enterprise content management, which allows people to find and use information based on their role.
• Business intelligence, which enables business insight through capabilities such as server-based Excel solutions.
• Unified messaging, which enables communication and collaboration to simplify team management.

Enterprise Content Management

Enterprise content management scenarios allow people to find and use information based on their business role or task requirements by using Office client applications. These applications may interact directly with the LOB system that provides the data. However, as shown in Figure 2, one of the more common scenarios in business environments is the use of MOSS or WSS as a content-management tool for Office client documents.

Figure 2a

Office client interacting directly with a LOB system

Figure 2b

Office client interacting with LOB system through a SharePoint intermediary

With the SharePoint solution, you can implement versioning and workflow on the files associated with Office client applications. In addition, many of the files can be modified within the SharePoint environment, and features included with MOSS use Excel to create and display reports. As a result, many of the key scenarios are based on using SharePoint with Office client applications. The following OBA patterns, described in detail later in this chapter, are useful for implementing enterprise content management scenarios:

• The Extended Reach Channel pattern extends LOB application functionality to a broader user base using Office applications as the channel.
• The Document Workflow pattern enables control and monitoring of document-centric processes, and can infuse best practices and enhance underlying business processes.
• The Collaboration pattern augments structured business processes with unstructured human collaboration.

Business Intelligence

Business intelligence scenarios enable business insight through capabilities such as server-based Excel solutions. The following OBA patterns, described in detail later in this chapter, are useful for implementing business intelligence scenarios:

• The Document Integration pattern enables the generation of Office documents from LOB applications; enables information workers to embed LOB data in Office documents by interacting with LOB data while authoring the document; and enables server-side processing of documents containing LOB data.
• The Composite UI pattern supports composition of multiple application UIs in an Office document or a SharePoint Web page.
• The Data Consolidation pattern enables a more natural way of interacting with LOB data by allowing users to discover data using searches across multiple LOB applications, and then act on the results. Data Consolidation uses the Discovery Navigation pattern.

Unified Messaging

Unified messaging scenarios support communication and collaboration, which simplifies team management. The Notification and Tasks pattern, described in detail later in this chapter, is useful for implementing unified messaging scenarios. The Notification and Tasks pattern uses Outlook as a primary UI to receive and act on LOB application—generated tasks and alerts.

Common OBA Patterns

OBAs can vary from the very simple to extremely complex custom solutions. OBAs generally incorporate one or more of the common patterns, which are described in the following sections:

• Extended Reach Channel
• Document Integration
• Document Workflow
• Composite UI
• Data Consolidation (Discovery Navigation)
• Collaboration
• Notifications and Tasks

Extended Reach Channel

Extended Reach Channel applications extend LOB application functionality to a broader user base using Office applications as the channel. The Extended Reach Channel pattern is useful for implementing the following scenarios:

• Eliminating duplication of effort that currently exists in your enterprise, such as an Outlook feature for consultants to assign time for meetings to billable projects.
• Extending LOB functionality to a broader set of end users, such as a self-service application that allows employees to update their personal information.
• Improving the use of an existing system that users currently avoid because of duplication of effort or lack of training.
• Collecting information from users through e-mail and automatically updating the system.

The Extended Reach Channel approach supports two different integration patterns: the Direct Integration pattern and the Mediated Integration pattern. The following sections describe these patterns.

Direct Integration Pattern

The Direct Integration pattern describes how Office client applications can expose LOB functionality directly to a broader set of users. In this pattern, access to LOB interfaces is projected directly into an Office client or is extended to an existing behavior such as calendaring. The client application may access the LOB data through a Web service, or may simply display output (such as HTML) generated by the LOB system, as shown in Figure 3.

Figure 3a

The Direct Integration pattern using Web services

Figure 3b

The Direct Integration pattern using HTML

Mediated Integration Pattern

The Mediated Integration pattern describes how metadata stores such as the BDC can be used to provide an additional level of abstraction that provides common approaches to managing LOB documents, including security with a SSO mechanism based on a credentials mapping. This pattern provides more opportunities for composing services and data into a composite UI. A mediator, which could be the BDC, collects data from disparate sources and exposes it in Office-compatible formats and services that client applications can consume. Figure 5 illustrates the Mediated Integration pattern.

Figure 4

The Mediated Integration pattern

Document Integration

Document Integration applications enable the generation of Office documents from LOB applications; enable information workers to embed LOB data in Office documents by interacting with LOB data while authoring the document; and enable server-side processing of documents containing LOB data. The Document Integration pattern is useful for implementing the following scenarios:

• Reducing duplication of LOB data that is stored in individual Office documents located on user desktop systems.
• Exposing specific subsets of LOB data to Office applications for tasks such as mail merge or reporting.
• Generating Office documents that include items of LOB data in the appropriate format, automatically refreshed as the data changes. Manual creation of common layouts should be avoided; the Office applications should create them using templates where applicable.
• Generating documents that require custom server-side processing of LOB data. Open standards should be used for embedding this data.
• Accepting inbound documents, processing the embedded data, and applying it to the LOB system.

The Document Integration approach supports four different integration patterns that use XML to pass information to and from LOB systems. The simplest is the Application Generated Documents pattern. In addition, there are three intelligent document integration patterns: the Embedded LOB Information pattern, the Intelligent Documents/Embedded LOB Template pattern, and the Intelligent Documents/LOB Information Recognizer pattern. The following sections describe these patterns.

Application Generated Documents Pattern

The Application Generated Documents pattern describes how the LOB system can merge business data with an Office document using batch-oriented server-side processing, although client-side generation is also feasible. Common examples include exporting data to Excel spreadsheets, or generating reports and letters in Word. This is the most commonly used pattern for document data integration.

Figure 5

The Application Generated Documents pattern

Intelligent Documents/Embedded LOB Information Pattern

The Intelligent Documents/Embedded LOB Information pattern describes how LOB data can be embedded directly within the body of an Office document, or embedded as an XML document part and exposed through a content control. Alternatively, the Office application can use the Office Custom Task Pane (CTP) to display LOB data that an information worker can browse or search, and embed into a document. Figure 6 illustrates the Embedded LOB Information pattern.

Figure 6

The Intelligent Documents/Embedded LOB Information pattern

Intelligent Documents/Embedded LOB Template Pattern

The Intelligent Documents/Embedded LOB Template pattern describes how a template can be used to combine metadata from a LOB system with document markup, such as content controls, XML schemas, bookmarks, named ranges, and smart tags. At run time, the template is merged with appropriate instances of the LOB data to create a document. The merging can take place through an add-in within the Office client application, or on the server.

Figure 7

The Intelligent Documents/Embedded LOB Template pattern

Intelligent Documents/LOB Information Recognizer Pattern

The Intelligent Documents/LOB Information Recognizer pattern describes how metadata and document markup, such as content controls, XML schemas, bookmarks, named ranges, or smart tags can contain data recognized by the LOB system. The application can use this data to update the LOB system, or to provide extra functionality for users. On the server side, the application may start a workflow using the information. On the client, the application might present context-sensitive information, such as the details of a customer whose name is recognized in a Word document.

Document Workflow

Document Workflow applications enable control and monitoring of document-centric processes, and can infuse best practices and enhance underlying business processes. The Document Workflow pattern is useful for implementing the following scenarios:

• Applications that exchange information, often via e-mail, to perform multistep tasks such as forecasting, budgeting, and incident management.
• Applications where specific legal or corporate compliance procedures must be followed, and audit information maintained.
• Applications that carry out complex document handling and conditional routing tasks, or must implement best practice-based on rules.

You must consider workflow requirements when implementing this pattern. However, avoid building custom workflow components where possible; instead use the workflow capabilities within SharePoint. The Document Workflow approach supports two different integration patterns that initiate workflows:

• LOB Initiated Document Workflow pattern. Documents are passed to a SharePoint document workflow automatically by an action such as saving them to a SharePoint document library or submitting an InfoPath form. The workflow might send the document to the next recipient in a list, store copies, or perform processes on the document depending on the requirements of the application.
• Cooperating Document Workflow pattern. There may be a series of interactions between documents and LOB systems that must follow certain rules or prevent certain actions; for example, preventing edits to a submitted document at a specific stage of the process, extracting specific information, and publishing this information back to the LOB system. This pattern will usually use a SharePoint cooperating workflow that provides the flow logic, while the intelligent document provides the LOB interaction mechanisms. In complex scenarios, the LOB system may also update the document as it passes through the workflow.

Composite UI

Composite UI applications support composition of multiple application UIs within an Office document or a SharePoint Web page. The Composite UI pattern is useful for implementing the following scenarios:

• Applications that collect and display several different types of information in a single UI page or screen.
• Applications that use data exposed by multiple networked systems, and display it in a single UI page or screen.
• Applications that must provide a customizable composite interface that users modify to best suit their requirements.

When implementing this pattern, ensure you follow Office standards, and avoid creating custom components when Web Parts that provide the required functionality are available. The Composite UI approach supports several different integration patterns that combine information into a composite UI:

• Context Driven Composite User Interface pattern. Contextual information determines the UI composition. The contextual information can be static (such as the application configuration, or a tab added to an Outlook view) or dynamic (such as hiding or showing tab-based data in the source document). Each region of the composite UI presents information through an Office client component. However, users cannot dynamically change the linking at run time between the document components and the source data located in the LOB system.
• Mesh Composite View pattern. The UI contains components such as ASP.NET Web Parts or MOSS components that cooperatively interact to expose data from the same or different LOB systems. For example, a part that represents a view of a customer from a customer relationship management (CRM) system might be connected at the time the view is constructed to a part that represents a list of open orders in an enterprise resource planning (ERP) system. When a customer is selected in the CRM part, it raises an event and provides the information on the selected customer identity to the open orders part so that it can show the status of that order.
• RSS and Web Services Composition pattern. A specialized version of the Mesh Composite View pattern that combines data published as RSS feeds or through Web services. Multiple SharePoint Data View Web Parts (or custom parts) format and present the published data within the UI. An example is a composite view of the catalogs of several suppliers, where each published item provides a link to a page on the supplier's Web site that contains extra information.
• Analytics pattern. A specialized version of the Mesh Composite View pattern that presents a data analysis dashboard to the end user. It can use Excel Services and the Excel Services Web Part provided by MOSS 2007 to display data and charts, or other parts to display custom data and information from the LOB system, and from other sources, within the composite UI. A useful part provided by MOSS for dashboards is the Key Performance Indicator (KPI) Web Part that allows users to define KPIs based on data in any SharePoint list, including a BDC list.

Data Consolidation (Discovery Navigation)

Data Consolidation applications enable a more natural way of interacting with LOB data by allowing users to discover data using searches across multiple LOB applications, and then act on the results. They rely on sufficient LOB entity data being available for the Office applications to act upon. Data Consolidation uses the Discovery Navigation pattern, and is useful for implementing the following scenarios:

• Applications that provide search capabilities for a single LOB system.
• Applications that provide search capabilities across multiple LOB systems.
• Applications that provide search capabilities across a diverse range of LOB systems and other data sources.

Data Consolidation Pattern

The Data Consolidation pattern provides a consistent search experience for information workers by combining the results of searches over one or more sources into a single result set, and presenting not only Uniform Resource Identifiers (URIs) that link to the results, but also actions associated with the found items. Figure 8 illustrates the Data Consolidation pattern creating a content index.

Figure 8

The content index contains information collated from a range of sources

Launching a LOB Process

A subpattern of the Data Consolidation pattern uses action links that can initiate a LOB operation, such as starting a workflow or performing a process on a document, as illustrated in Figure 9.

Figure 9

Launching a LOB process based on an action for an item in the search results

Collaboration

Collaboration applications augment structured business processes with unstructured human collaboration. The Collaboration pattern is useful for implementing the following scenarios:

• Applications that involve human interaction that leads to interaction with a LOB system, such as discussion of a sales opportunity before committing an order.
• LOB applications that collate content and user contributions in an unstructured form, and the later must expose it in a structured format.
• Applications that provide information in an unstructured form that users may be able to edit, such as a wiki or discussion site.

The Collaboration pattern uses MOSS Team Site templates that allow users to collaborate around a specific business problem using document libraries, discussion and task lists, team calendars, and simple project management features. The site can be provisioned and populated using LOB data, and exposes links to LOB processes within the appropriate libraries and lists. Access can be through Office documents, or a Web browser.

Notifications and Tasks

Applications that must support notifications and tasks can use Outlook as a primary UI to receive and act upon LOB application-generated tasks and alerts. In addition to Outlook, SharePoint provides notification and task services that can interact with most e-mail systems using the Simple Mail Transfer Protocol (SMTP). The Notifications and Tasks pattern is useful for implementing the following scenarios:

• Applications that assign tasks and generate notifications for end users.
• Applications that integrate multiple LOB operations and must notify users of status or process requirements.

The e-mail—based Notifications and Tasks approach supports several different integration patterns that can notify users of tasks and status:

• Simple Task and Notification Delivery pattern. The LOB system delivers tasks and notifications to users as Outlook tasks and e-mail messages in a one-way flow of information. Details of the task or the notification are embedded in the body of the task and e-mail message, but changes are not reflected back in the LOB system. Options for delivering tasks and notifications include delivering them to Microsoft Exchange Server (the push model), using an add-in on Outlook that fetches them (the pull model), or publishing an RSS feed to which users can subscribe.
• Direct Task Synchronization pattern. The LOB system sends tasks to users via Exchange or Outlook in a synchronized bidirectional flow of information. Users and the LOB can update tasks at any time, and the changes are propagated to the LOB system. The task may be part of a LOB workflow.
• Mediated Task Synchronizationpattern. A variant of the Direct Task Synchronization pattern, where MOSS acts as a mediator between the LOB system and Outlook in order to synchronize tasks. The LOB system publishes tasks to a SharePoint Task List, which is synchronized with Outlook Tasks by using Outlook's native synchronization mechanism. Updates to the task in Outlook are automatically pushed back to SharePoint, which raises an event indicating that the change has occurred and allows custom code to update the LOB system.
• Intelligent Tasks and Notifications pattern. Action links located in the Outlook CTP allow users to initiate specific actions based on the tasks or notifications sent by the LOB system. Common tasks involve automatically logging on to the LOB system, finding the right information, and updating it. An example is a manager viewing an e-mail message sent by Human Resources to approve a vacation request for an employee, where the CTP contains action links that allow the manager to approve or reject the request by updating the LOB system.
• Form-based Tasks and Notifications pattern. A variant of the Intelligent Tasks and Notification pattern, where the e-mail message contains an attached InfoPath form prepopulated by the LOB system. The user can open the e-mail message, fill out the form, and submit it to the LOB system. InfoPath provides data validation, custom calculations, and logic to assist the user when filling out the form. The InfoPath CTP can provide additional information, extracted from the LOB system, to assist the user. A variant of this pattern uses MOSS InfoPath Forms Services to allow users to fill out forms in a Web browser without requiring InfoPath to be installed.

General Design Considerations

The design of a suitable OBA is based on the scenarios you must support, and the types of Office client applications suitable for those scenarios. In addition to considering the base patterns shown in the previous section, consider the following guidelines when designing your OBA:

• Consider using a mediated integration pattern over direct integration. When designing an OBA as an extended reach channel, you can implement interfaces directly within documents. For example, an Excel spreadsheet can contain custom input forms. However, this approach requires custom code and limits your ability to reuse functionality. With a mediated integration pattern, you can take advantage of applications such as SharePoint and the Business Data Catalog to decouple the interfaces from the physical documents.
• Use OpenXML-based schemas for embedding LOB data in documents. OpenXML is a European Computer Manufacturers Association (ECMA) international standard that is supported by Office 2007 applications, as well as by many independent vendors and platforms. By using OpenXML, you can share data between Office applications and applications developed for other platforms.
• Create LOB document templates for common layouts that will be reused. A LOB template contains markup and metadata associated with the LOB that can be bound to specific LOB data instances at a later time. In other words, new documents can be generated by merging LOB data with document templates. End users can create custom documents without developer involvement, and complex documents can be generated using server-side batch processing.
• Use MOSS to control the review and approval process for documents. MOSS provides out of the box features that support a basic workflow process for the review and approval of documents. For more complex processing requirements, WF can be used to extend the workflow capabilities found in SharePoint.
• Use the Collaboration pattern for human collaboration. Most LOB applications are good at handling structured business processes. However, they are not good at handling the unstructured nature of human interaction with business processes. A site implementing the collaboration pattern addresses this issue by providing an interface geared toward collaboration with other users. The SharePoint Team Site template implements this pattern.
• Consider remote data synchronization requirements. Documents that are created, updated, or distributed should be synchronized with the LOB system and then stored for future use. Even though LOB systems are quite useful for handling transaction oriented activities, they are not suited to capturing the significant work that occurs between activities.

Security Considerations

Security is important in Office Business Applications that expose data and functionality through several types of client applications, and have access to corporate LOB data. It is important to secure all access to resources, and to protect data passing over the network. Consider the following guidelines for security when creating OBAs:

• Consider implementing SSO so that users access the client applications and the networked functionality using their current logon credentials, or credentials validated through a federated service such as Active Directory or SharePoint.
• Consider encrypting messages that pass outside of your secure network where possible. You can use channel encryption mechanisms such as Internet Protocol Security (IPSec) to protect the network connection between servers and clients.
• Consider using the trusted subsystem model for data access using role credentials to minimize the number of connections required. See Chapter 19 "Physical Tiers and Deployment" for more information about the trusted subsystem model.
• Consider filtering data at the server to prevent exposure of sensitive data in client applications where this is not necessary.

Deployment Considerations

You can deploy OBA solutions using either a Windows Installer package or the Click Once technology:

• Click Once installation requires little user interaction, provides automated updates, and requires little effort for the developer. However, it can only be used to deploy a single solution that is not part of a larger solution; it cannot deploy additional files or registry keys; it cannot interact with the user to configure the installation; and it cannot provide a branded installation.
• Windows Installer installation can deploy additional components and registry settings; can interact with the user to configure the installation; and supports custom branding of the installation. However, it requires advanced configuration, more developer effort, and cannot provide automated updates.

Relevant Design Patterns

Key patterns are organized into categories such as Collaboration, Composite UI, Data Consolidation Document Integration, Document Workflow, Extended Reach Channel, and Tasks and Notifications; as shown in the following table. Consider using these patterns when making design decisions for each category.

For more information on OBA patterns, see Barker, Rob, Joanna Bichsel, Adam Buenz, Steve Fox, John Holliday, Bhushan Nene, and Karthik Ravindran. 6 Microsoft® Office Business Applications for Office SharePoint® Server 2007. Microsoft Press, 2008. Additionally, you can refer to the excerpt from the book “Getting Started with Office Business Applications” at https://msdn.microsoft.com/en-us/library/bb614539.aspx

Additional Resources

For more information, see the following resources:

• "Automating Public Sector Forms Processing and Workflow with Office Business Application" at https://blogs.msdn.com/singaporedpe/archive/tags/OBA/default.aspx.
• "Getting Started with Office Business Applications" at https://msdn.microsoft.com/en-us/library/bb614538.aspx.
• "OBA (Reference Application Pack) RAP for E-Forms processing" at https://msdn.microsoft.com/en-us/architecture/bb643796.aspx.
• PowerPoint slides and source code at https://msdn.microsoft.com/en-us/architecture/bb643796.aspx.
• "OBA Central" at http://www.obacentral.com/Pages/Redirect.htm.
• "Integrating LOB Systems with the Microsoft Office System" at https://msdn.microsoft.com/en-us/architecture/bb896607.aspx.
• "Understanding Office Development" at https://msdn.microsoft.com/en-us/office/aa905371.aspx.