Application Architecture Guide - Chapter 20 - Office Business Applications (OBA)

From Guidance Share
Jump to navigationJump to search

Note - The patterns & practices Microsoft Application Architecture Guide, 2nd Edition is now live at http://msdn.microsoft.com/en-us/library/dd673617.aspx.


Chapter 20: Office Business Applications (OBA)

Objectives

  • Define an Office Business Application (OBA).
  • Understand the common application types where OBAs are suitable.
  • Understand the architecture of OBAs and their integration with Microsoft® Office SharePoint® and line-of-business (LOB) applications.
  • Understand the components found in an OBA.
  • Learn the key scenarios for OBAs.
  • Learn the design considerations for OBAs.
  • Learn the key patterns associated with OBAs.

Overview

Office Business Applications (OBAs) are a class of enterprise composite applications. They provide solutions that integrate the core capabilities of back-end 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 line-of-business (LOB) applications. They leverage the rich user interface (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.

Architecture

Figure 1 illustrates the key components and layers of an OBA. One thing to note is that this diagram adds 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

OBAs are designed to interoperate using standard file formats and Web services; for example:

  • Open standards and interoperability are the core tenets of the Microsoft Office System.
  • The metadata definitions of OBA solution objects are based on Extensible Markup Language (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.

Key Components

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 clients. The client applications include Microsoft Office Outlook®, Microsoft Office Word, Microsoft Office Excel®, Microsoft Office InfoPath®, and Microsoft Office PowerPoint®. 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 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 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.
  • Microsoft 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). 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 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. 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 run time 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 Microsoft Office Communications Server (OCS), Microsoft Office Groove® Server, and Microsoft Exchange Server.
  • Development tools. These include SharePoint Central Administration, SharePoint Designer, Microsoft Visual Studio®, and Visual Studio Tools for Office (VSTO).

Key Scenarios

OBAs generally fall into one of three categories that implement key scenarios. These categories are:

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

Enterprise Content Management

Enterprise content management scenarios allow people to find and use role-based information. 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. With either of these SharePoint solutions, 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.


Figure 2a Office client interacting directly with an LOB system


Figure 2b Office client interacting with LOB system through a SharePoint intermediary

The following OBA patterns, described in detail later in this chapter, are also 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.

Summary of Common OBA Patterns

OBAs can vary from the very simple to extremely complex custom solutions. OBAs generally incorporate one or more of the following 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 UIs 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 UI 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 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. An 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. 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.
  • 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.

OBA Frame

There are several common issues that you must consider as your develop your design. These issues can be categorized into the base OBA patterns listed and described in this chapter. The following table lists the common issues for each pattern where mistakes are most often made.

Table 1 OBA frame

Category Key issues
Extended Reach Channel * Duplication of functionality across an enterprise
  • Stand-alone applications with limited reuse
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
Notifications & Tasks * Using multiple LOB applications to provide task and notification support

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


Figure 3a The Direct Integration pattern using Web services


Figure 3b The Direct Integration pattern using HTML

Mediated Integration Pattern

The Mediated Integration pattern is 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. 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.
  • 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 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 is 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 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 is 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. Figure 6 illustrates the Embedded LOB Information pattern.


Figure 6 The Embedded LOB Information pattern

Intelligent Documents: Embedded LOB Template Pattern

The Intelligent Documents: Embedded LOB Template pattern is where a template is used to combine metadata from an 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 Embedded LOB Template pattern

Intelligent Documents: LOB Information Recognizer Pattern

The Intelligent Documents: LOB Information Recognizer pattern is where metadata and document markup, such as content controls, XML schemas, bookmarks, 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.

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 that 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 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 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 that users 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 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, 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 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 order status in an enterprise resource planning (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 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, which is 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. 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

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 an LOB Process

The action links can initiate an LOB operation, such as starting a workflow or performing a process on a document, as illustrated in Figure 9.


Figure 9 Launching an 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 later need to use 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 need to support notifications and tasks use Outlook as a primary UI 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 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 & Notification Delivery pattern, where 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, where 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 an LOB workflow.
  • Mediated Task Synchronization pattern is 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 & 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 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 & Notifications pattern is a variant of the Intelligent Tasks & Notification pattern, where the e-mail message contains an attached InfoPath form pre-populated 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.

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 single- sign-on so that users access the client applications and the back-end functionality using their current logon credentials, or credentials validated through a federated service such as the Microsoft Active Directory® directory service or SharePoint.
  • Consider encrypting messages that pass outside of your secure network where possible.
  • Consider using channel encryption 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.
  • 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 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.

Pattern Map

Key patterns are organized by the key categories detailed in the following table. Consider using these patterns when making design decisions for each category.

Table 2 Pattern map

Category Relevant patterns
Extended Reach Channel * Direct Integration
  • Mediated Integration
Document Integration * Application Generated Documents
  • Embedded LOB Information
  • Embedded LOB Template
  • LOB Information Recognizer
Document Workflow * LOB Initiated Document Workflow
  • Cooperating Document Workflow
Composite UI * Context Driven Composite User Interface
  • Mesh Composite View
  • RSS and Web Services Composition
  • Analytics
Data Consolidation * Discovery Navigation
Collaboration * Collaboration
Tasks & Notifications * Simple Task & Notification Delivery
  • Direct Task Synchronization
  • Mediated Task Synchronization
  • Intelligent Tasks & Notifications
  • Form-based Tasks & Notifications


Pattern Descriptions

  • Analytics. A specialized version of the Mesh Composite View pattern that presents a data analysis dashboard to the end user.
  • Application Generated Documents. The LOB system merges business data with an Office document using batch-oriented server-side processing.
  • Collaboration. Use unstructured human collaboration to augment structured business processes.
  • Context Driven Composite User Interface. Use contextual information to determine the composition of the UI.
  • Cooperating Document Workflow. A series of interactions between documents and LOB systems that must follow certain rules or prevent certain actions.
  • Direct Integration. Access to LOB interfaces is projected directly into an Office client, or is extended to an existing behavior such as calendaring.
  • Direct Task Synchronization. The LOB system sends tasks to users via Exchange or Outlook as a synchronized bidirectional flow of information.
  • Discovery Navigation. Allow users to discover data by searching across multiple LOB applications, and then act on the results.
  • Embedded LOB Information. 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.
  • Embedded LOB Template. A template combines metadata from an LOB system with document markup, such as content controls, XML schemas, bookmarks, named ranges, and smart tags.
  • Form-based Tasks & Notifications. A variant of the Intelligent Tasks & Notification pattern, where the e-mail message contains an attached InfoPath Form pre-populated by the LOB system.
  • Intelligent Tasks & Notifications. Action links located in the Outlook Custom Task Pane (CTP) allow users to initiate specific actions based on the tasks or notifications sent by the LOB system.
  • LOB Information Recognizer. Metadata and document markup—such as content controls, XML schemas, bookmarks, named ranges, or smart tags—contain data recognized by the LOB system.
  • LOB Initiated Document Workflow. 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.
  • Mediated Integration. 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.
  • Mediated Task Synchronization. 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.
  • Mesh Composite View. Use components in the UI, such as ASP.NET Web Parts or MOSS components, which cooperatively interact to expose data from the same or different LOB systems.
  • RSS and Web Services Composition. A specialized version of the Mesh Composite View pattern that combines data published as RSS feeds or through Web services.
  • Simple Task & Notification Delivery. The LOB system delivers tasks and notifications to users as Outlook tasks and e-mail messages in a one-way flow of information.

Additional Resources

For more information, see the following resources: