This project is read-only.
Note that the information on this page is the BETA 1 of a guide that is now released. See http://www.codeplex.com/AppArchGuide for the latest PDF and HTML content.

Chapter 19 - Office Business Applications (OBA)

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Objectives

  • Learn the common application types and patterns for which Office Business Applications are suitable.
  • Understand the architecture of Office Business Applications and their integration with SharePoint and Line of Business (LOB) applications.
  • Learn the key scenarios for Office Business Applications, and the key issues.

Overview

Office Business Applications (OBAs) are a new class of enterprise composite applications. They provide solutions that integrate the core capabilities of backend 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, which can help to improve business insight and assist in integrating existing internal or external systems. OBAs help to extend Microsoft Office into three main areas:
  • Unified messaging, communication, and collaboration; which simplifies team working.
  • Business intelligence, which enables business insight through capabilities such as server-based Excel solutions.
  • Enterprise content management, which allows people to find and use role-based information.

The Microsoft Office clients are used to build user-centric and process-centric business solutions that integrate Line of Business (LOB) processes with a rich user experience. OBAs combine existing LOB systems with the Microsoft Office System to leverage the core abilities required by the solutions. Visual Studio.NET can be used to build Office client add-ins to integrate LOB system interfaces in the Microsoft Office client applications.

OBAIntegrateLOB.PNG

Figure 1. OBA solutions fill and simplify process gaps and integrate LOB systems


OBAs are designed to interoperate using standard file formats and Web services:
  • Open standards and interoperability are the core tenets of the Microsoft Office System.
  • The metadata definitions of OBA solution objects are based on XML schemas.
  • All Office products are service-enabled at all levels.
  • Interoperable OpenXML file formats are the default schemas for business documents created by or generated for Microsoft Office business productivity client applications.

Architecture

The following diagram illustrates the key components and layers of an Office Business Application.

OBAArch.PNG

One thing interesting to note is that this diagram adds a layer between presentation and application named productivity. The productivity layer contains components used to store and manage collaborative work streams in a document-centric manner.

Key Components

An Office Business Application contains:
  • Microsoft Office clients. The client applications include Office Outlook, Office Word, Office Excel, Office InfoPath, and Office PowerPoint. Custom forms in Outlook can be used to host user interface 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 new 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 phone 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 on Microsoft Windows Server 2003, WSS provides content management and collaboration features that can help improve business processes and team productivity. WSS also provides a platform for building web-based business applications that allow users to share documents, information, and ideas with support for offline synchronization and task management.
  • Microsoft Office SharePoint Server (MOSS). Extends the capabilities provided by WSS to offer enterprise-wide functionality for content management, workflow, search, portals, and personalized sites. In addition, MOSS provides 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 allows 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. Windows Workflow Foundation (WF) functionality is built into MOSS. This makes it easy to capture a process, such as a purchase order approval, and reduce user errors and associated delays. The ASP.NET runtime supports Web Page and Web Part rendering to create customized Web sites that reflect the company’s requirements.
  • Collaboration features. Collaboration can be managed by Office Communications Server Office Groove Server, and Exchange Server.
  • Development tools. These include SharePoint Central Administration, SharePoint Designer, Visual Studio, and Visual Studio Tools for Office (VSTO).

Key Scenarios

One of the more common scenarios that you’ll find in business environments is the use of Microsoft Office SharePoint Server (MOSS) or Windows SharePoint Services (WSS) as a content management tool for Office client applications. With SharePoint 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 Microsoft Office Excel to create and display reports. As a result, many of the key scenarios are based on using SharePoint with Microsoft Office Client applications.

CommonPlatFormOptions.PNG

Figure . Common Platform Options for OBA Applications


OBAs can vary from the very simple to extremely complex custom solutions. OBAs generally incorporate one or more of the following seven common patterns:
  • Extended Reach Channel. These applications extend LOB application functionality to a broader user base using Office applications as the channel.
  • Document Integration. These 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.
  • Document Workflow. These applications enable control and monitoring of document-centric processes, and can infuse best practices and enhance underlying business processes.
  • Composite UI. These applications support composition of multiple application user interfaces in an Office document or a SharePoint Web page.
  • Data Consolidation. These 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.
  • Collaboration. These applications augment structured business processes with unstructured human collaboration.
  • Notifications and Tasks. These applications use Outlook as a primary user interface to receive and act on LOB application generated tasks and alerts.

Large and complex solutions may incorporate more than one of these patterns, or may use patterns different from those shown. However, these patterns will help you to think about how you design an OBA. Later sections of this chapter explore each of these patterns in more depth.

Design Considerations

The design of office business applications are based on scenarios you need to support and the Office client applications used to support the scenarios. As a result, the following guidelines are based on patterns associated with the key scenarios introduced earlier in this chapter.
  • Consider using a mediated integration pattern over direct integration. When designing an OBA as a reach channel you can implement an interface directly in documents. For example, an Excel spreadsheet with custom input forms. However, this approach requires custom code and limits the ability to re-use functionality. With a mediated integration pattern you can take advantage of applications like SharePoint and the Business Data Catalog to decouple the interface from the physical documents.
  • Use OpenXML based schemas for embedding LOB data in documents. OpenXML is an Ecma International standard that is supported by Office 2007 applications along with non-Microsoft 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 need to be reused. An LOB template would contain markup along with metadata associated with the LOB that can be bound to specific LOB data 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 SharePoint to control the review and approval process for documents. Microsoft Office SharePoint Server (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 Windows Workflow Foundation (WF) can be used to extend the workflow capabilities found in SharePoint.
  • Follow standard Office conventions when creating Custom Task Panes (CTP). For example, a CTP should become visible as a result of user interaction, such as clicking a button. Attempting to design a CTP that becomes visible and hides itself automatically will add confusion for the user.
  • Use the Collaborative Site 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. The collaborative site pattern addresses this issue by providing an interface geared towards collaboration with other users. An example of this pattern is the Team Site template found in SharePoint.
  • Use Property Bags for Configuration Data. When interacting with Office client applications from a web application they will often execute in a different process. As a result, they would not have access to configuration data contained in the web.config file associated with the web application.
  • 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.

OBA Frame

Category Key Issues
Extended** Reach Channel Duplication of functionality across an enterprise.
Stand-alone applications with limited re-use.
Document Integration Not using open standards for embedding LOB data.
Creating common layouts by hand for each new document.
Document Workflow Not considering workflow requirements.
Building custom workflow components instead of using workflow capabilities in SharePoint.
Composite UI Not following Office standards.
Creating custom components when Web Parts that provide the required functionality are available.
Data Consolidation Not providing sufficient LOB entity data for Office applications to act on.
Collaboration Not considering the unstructured nature of human collaboration.
Tasks & Notifications Using multiple LOB applications to provide task and notification support.

Extended Reach Channel

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 due to duplication of effort, or lack of training.
  • Collecting information from users through email and automatically updating the system.

The Extended** Reach Channel approach supports two different integration patterns:
  • Direct Integration Pattern, where Office client applications 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.
  • Mediated Integration Pattern, where metadata stores such as the Business Data Catalog (BDC) are used to provide an additional level of abstraction that provides common approaches to managing LOB documents, including security with a single sign-on 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.

DirectIntegration1.PNG DirectIntegration2.PNG

Figure 4- The Direct Integration Patterns

MediatedIntegration.PNG

Figure 5 - 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.
  • Generating documents that require custom server-side processing of LOB data.
  • Accepting inbound documents, processing the embedded data, and applying it to the LOB system.

The Document Integration approach supports several different integration patterns that use XML used to pass information to and from LOB system:
  • Application Generated Documents, where the LOB system merges business data with the Office document using batch oriented server side processing, although client side generation is also feasible. Common examples are exporting data to Excel spreadsheets, or generating reports and letters in Word. This is the most commonly used pattern for document data integration.
  • Intelligent Documents: Embedded LOB Information Pattern, where LOB data is embedded directly in the body of the 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.
  • Intelligent Documents: Embedded LOB Template Pattern, where a template is used to combine metadata from a LOB system with document markup, such as Content Controls, XML Schemas, Bookmarks, Named Ranges, and Smart Tags. At runtime, 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.
  • Intelligent Documents: LOB Information Recognizer Pattern, where metadata and document markup, such as Content Controls, XML Schemas, Bookmarks, and Named Ranges, or Smart Tags 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.

AppGenerated.PNG

Figure 6 - The Application Generated Document Pattern

EmbeddedLOB.PNG

Figure - The Embedded LOB Information Pattern

EmbeddedLOBTemp.PNG

Figure - The Embedded LOB Template Pattern

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 by email, to perform multi-step 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.

The Document Workflow approach supports two different integration patterns that initiate workflows:
  • LOB Initiated Document Workflow Pattern, where 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, where 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 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 may also update the document as it passes through the workflow.

Composite UI

Composite UI applications support composition of multiple application user interfaces in 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 back-end systems, and display it in a single UI page or screen.
  • Applications that must provide a customizable composite interface for users to modify to best suit their requirements.

The Composite UI approach supports several different integration patterns that combine information into a composite UI:
  • Context Driven Composite User Interface Pattern, where contextual information determines the UI composition. The contextual information can be static (such as the application configuration, or adding a tab to the Outlook view) or dynamic (such as hiding or showing a 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 runtime between the document components and the source data located in the LOB system.
  • Mesh Composite View Pattern, where 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 customer from a CRM system may be connected at the time the view is constructed to a part that represents a list of open order status in an ERP system. When a customer is selected in the CRM part, the CRM part raises an event and provides the information on the selected customer identity to the open order status part, which in turn displays the list of order status for the selected customer.
  • RSS and Web Services Composition Pattern, which is 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 catalogues 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, which is a specialized version of the Mesh Composite View pattern that presents 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 Business Data Catalog (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. Data Consolidation uses the Discovery Navigation pattern.

The Discovery Navigation pattern 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.

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 URI that link to the results but also actions associated with the found items. These actions can initiate a LOB operation, such as initiating a workflow or performing a process on a document.

[image:DataConsolidation.PNG]

Figure - The content index contains information collated from a range of sources.

SearchResults.PNG

Figure - 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.
  • Applications that collate content and user contributions in unstructured formats, and later need to collate this in structured form in a LOB system.
  • Applications that provide information in an unstructured form that user 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

Notifications and Tasks applications use Outlook as a primary user interface to receive and act on 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 Message Transport 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 Email-based Notifications and Tasks approach supports several different integration patterns that can notify users of tasks and status:
  • Simple Task & Notification Delivery Pattern, where the LOB system delivers tasks and notifications to users as Outlook tasks and emails in a one-way flow of information. Details of the task or the notification are embedded in the body of the task and email, but changes are not reflected back in the LOB system. Options for delivering tasks an 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 SS fed to which users can subscribe.
  • Direct Task Synchronization, where the LOB system sends tasks to users via Exchange or Outlook in a synchronized bi-directional 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 Synchronization is a variant of the Direct Task Synchronization pattern, where MOSS acts as a mediator between the LOB system and Outlook to synchronize tasks. The LOB System publishes tasks to a SharePoint Task List, which is synchronized with Outlook Tasks 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 & Notifications Pattern, where action links located in the Outlook Custom Task Pane (CTP) allow users to initiate specific actions based on the tasks or notifications sent by 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 email sent by HR 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 & Notifications Pattern is a variant of the Intelligent Tasks & Notification pattern, where the email contains an attached InfoPath Form pre-populated by the LOB system. The user can open the email, 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 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.

Security Considerations

Consider the following guidelines for security when creating OBAs:
  • Consider implementing Single-Sign-On so that users access the client applications and the back-end functionality using their current log-on 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.
  • Consider using channel encryption such as 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.
  • Consider filtering data at the server to prevent exposure of sensitive data in client applications where this is not necessary.

Technology Considerations

  • Task pane support. Task Pane support, which lets you programmatically add LOB specific actions, varies by version. Word and Excel have support starting in version 2003. Outlook started with 2007. There is no task pane support in Powerpoint 2007 or Infopath 2007 or earlier.

Deployment Considerations

You can deploy OBA solutions using either a Windows Installer or the ClickOnce technology:
  • ClickOnce 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 it not part of a larger solution, it cannot deploy additional files or registry keys, cannot interact with the user to configure the installation, and 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. Howver, it requires advanced configuration, more developer effort, and cannot provide automated updates.

Additional Resources

For more information, see the following resources:

Last edited Dec 16, 2008 at 8:19 AM by rboucher, version 3

Comments

No comments yet.