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

Chapter 23 – SharePoint LOB Applications

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


  • Learn about the key scenarios and design considerations for SharePoint Line of Business (LOB) applications.
  • Learn about the key components and services for SharePoint Line of Business (LOB) applications.
  • Learn about deployment options for SharePoint Line of Business (LOB) applications.


Office Business Applications can integrate Line of Business (LOB) processes with rich user experiences for data access, data analysis, and data manipulation by using role-tailored business portals built on top of Windows SharePoint Services (WSS) and the Microsoft Office SharePoint Server (MOSS). WSS sites can be configured to publish Internet-facing content, and sites can scale out with Web farm deployment to service thousands of users.

WSS integrates tightly with the broader Microsoft platform. Windows Server is the core operating system on which WSS runs. WSS uses Internet Information Services (IIS) as a front-end Web server to host and scale out Web sites. It uses Microsoft SQL Server on the back end to store site definitions, content type definitions, published content, and configuration data.
WSS can also integrate with ASP.NET to provide LOB data presentation for sites. It can use ASP.NET Web Parts, styles, themes, templates, server controls, and user controls for the UI.

The following schematic shows the key features and layers of a SharePoint LOB application.



The following list describes each of the layers shown in the previous schematic:
  • Presentation Layer. This is the user interface of the application. Users connect through a browser to the SharePoint Server Portal, which is composed of Web pages. These Web pages can be assembled using Web Parts, which provide rich composition at the presentation level. Web Parts for Office client applications are also available, and you can build custom Web Parts to implement application-specific functionality.
  • Productivity Layer. The Microsoft Office client applications are used for information processing and collaboration. Office documents, such as Excel spreadsheets, are stored in document libraries. Forms that automate tasks in the Office applications are stored in forms libraries. The productivity tier also implements features for creating and publishing reports, in the form of either SharePoint lists or Excel spreadsheets, by using Excel Services. It may also generate output in the form of a dashboard composed of information drawn from multiple services.
  • Application Services Layer. This is a reusable layer within the application. Office system applications can integrate with a service-oriented architecture. The Office system also supports workflows using Windows Workflow Foundation (WF), which can provide business process or document lifecycle management. The Office system clients can consume service interfaces by invoking the Web services directly, or by using the Business Data Catalog (BDC). Excel Services can also be used to build applications directly within the Office System.
  • Services Layer. This provides a communication infrastructure messages. The MOSS layer will use Windows Communication Foundation (WCF), whereas the integration layer will use BizTalk.
  • Data Layer. This layer encapsulates the mechanisms for storing and accessing all the different types of data required by the application. This includes roles and identities, as well as the operations data and data warehouses that contain the LOB data.

Key Components

  • Workflow. MOSS is integrated with WF, and allows developers to create simple workflows and attach them to the document libraries in SharePoint. Users can also create custom workflows using the SharePoint designer.
  • Business Intelligence. MOSS provides users with interactive Business Intelligence portals that support substantial data manipulation and analysis. Users can create dashboards from multiple data sources without writing code. Key Performance Indicators (KPIs) can be defined from Excel Services, SharePoint Lists, Analysis Server cubes, and a variety of other sources. Because this data is hosted with SharePoint, it can be an active participant in other SharePoint services such as search and workflow.
  • Content Management. Functionality from Microsoft Content Management Server (MCMS) has been rolled into MOSS, allowing it to take advantage of comprehensive Web content management features available directly from the SharePoint platform.
  • Search. Enterprise search in MOSS is a shared service that provides extensive and extensible content gathering, indexing and querying facilities, and supports full-text and keyword searches.
  • Business Data Catalog. The BDC allows enterprise data to be exposed to Web Parts, InfoPath Forms Server, and search functions. Developers can use the BDC to build applications that allows users to interact with LOB data using familiar interfaces.
  • Open XML File Format. Adoption of the Open XML file format across the Office System applications facilitates rich server-side document manipulation.

Key Scenarios

SharePoint LOB applications 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 SharePoint LOB 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.

Design Considerations

When designing a SharePoint LOB application, consider the following guidelines:
  • Enable a user experience tailored to the user's role.
  • Introduce appropriate levels of structure when accessing and manipulating LOB data.
  • Choose the patterns to integrate LOB systems with Office client applications that are specific to the solution and the functional requirements. Examples are the Direct Access pattern and the Mediated pattern.
  • Choose either ADO.NET or Web services for the Direct Access pattern.
  • Consider using Microsoft Office SharePoint Server (MOSS) as a middle-tier application server for the Mediated pattern.
  • Use Web services to avoid tight coupling between the layers.
  • Consider remote data synchronization requirements. All documents 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.
  • Design service orientation to expose business applications for use in Office Business Applications (OBAs).

Documents and Content Storage

Office documents, such as Excel spreadsheets, are stored in document libraries.

When storing content in SharePoint, consider the following guidelines:
  • When storing documents in document libraries, use Content Types to define additional metadata.
  • Identify and plan your Content Types.
  • Define unique metadata field names and their associations with the Content Types.
  • Design Content Types to make use of their inheritance capabilities.
  • Consider customizing the Document Information Panel to collect Content Type metadata for Microsoft Office documents.
  • Consider storing user-configurable reference data or non-transient data in Lists.
  • Consider caching the contents of a List to a DataTable or DataSet if the list will be queried multiple times in your application.
  • Do not treat SharePoint Lists as database tables. Use database tables for transient or transactional data.
  • Do not replace file systems with SharePoint Document Libraries. Store only documents that require collaboration and management.
  • Do not use SharePoint Document libraries as source code control or as a platform to collaborate source code amongst development team members. Use Visual Studio Team Foundation Server instead.
  • Consider the restriction of a maximum of 2000 items per list container in Document Libraries and Lists.
  • Consider writing your own user interface to retrieve items in Lists when the list container exceeds 2000 items.
  • Consider organizing documents into Folders as opposed to using filtered views for faster retrieval.

Web Parts

Web Parts allow you to provide rich composition at the presentation level. You can build custom Web Parts to implement application-specific functionality, and use Web Parts provided with SharePoint and other environments such as ASP.NET.

When using Web Parts in your SharePoint LOB applications, consider the following guidelines:
  • Use Web Parts to interact with back-end LOB applications or Web services.
  • Use Web Parts to allow users to create composite customizable interfaces that support personalization.

When developing Web Parts, consider the following guidelines:
  • Identify suitable functionality that you would like to implement in Web Parts.
  • Identify the data sources that the Web Parts will interact with (if any).
  • Design Web Parts using layering guidelines to partition your presentation, business, and data logic to improve maintainability.
  • Design Web Parts to perform only a single function to improve re-use.
  • Design Web Parts to be configurable or customizable by users.
  • Include a Web Part Manager in custom master pages that will be used by Web Part pages.
  • Use Web Part zones to host Web Parts.
  • Create standard ASP.NET Web Parts whenever possible, inheriting from System.Web,UI.WebControls.WebParts.WebPart.
  • Define a unique ID explicitly for your Web Part connections.
  • Consider using Web Part verbs to allow users to perform discrete actions.
  • Avoid specifying style attributes directly on controls contained in Web Parts.
  • Consider categorizing your properties to distinguish them from Web Part properties.
  • Dispose properly any SharePoint objects and unmanaged resources that you create in your Web Parts.


SharePoint allows developers to create simple workflows and attach them to the document libraries in SharePoint. Users can also create custom workflows using the SharePoint designer, or you can create custom workflows using Visual Studio.

When designing Workflows, consider the following guidelines:
  • Identify the business processes to automate.
  • Consult a subject matter expert or business analysts to review existing business processes.
  • Ensure existing business processes are accurate and documented before implementing the workflows electronically.
  • Choose the right workflow technology to meet the business requirements.
  • Use out-of-the-box SharePoint workflows if business requirements are simple, for example Approval.
  • Use SharePoint Designer to create workflows when out-of-the-box workflows cannot fulfill business requirements, but consider the capabilities and limitations of SharePoint Designer workflows.
  • Use Visual Studio to develop custom workflows when business requirements require complex workflows or integration with LOB systems.
  • Consider using Visual Studio to create workflow activities that can be registered with SharePoint Designer to empower information workers.
  • When developing custom workflows, choose the appropriate workflow types.
  • When debugging custom workflows, consider setting the logging level to verbose.
  • When debugging custom workflows, consider implementing comprehensive instrumentation within your code.
  • Consider versioning your workflow assemblies and changing the solution GUID when upgrading your old workflows.
  • Consider the effect on existing workflow instances that are running when deploying newer versions.
  • Consider creating separate workflow history lists and tasks list for workflows created by end-users.
  • Consider assigning workflows to content types to improve portability (not available for SPD workflows).
  • Consider that there can only be one running workflow instance of the same type per List item.
  • Consider that workflow instances will only start on List items, and not the List itself.

Business Data Catalog

The Business Data Catalog (BDC) allows enterprise data to be exposed to Web Parts, InfoPath Forms Server, and search functions. Developers can use the BDC to build applications that allows users to interact with LOB data using familiar interfaces.

When developing BDC applications, consider the following guidelines:
  • Identify the data sources that will be used by the BDC.
  • Review the structure of data sources to ensure that they are suitable to be consumed directly by the BDC.
  • Determine if a staging area is required for loading the data from the data sources for consolidation and cleansing.
  • Determine how the data will be used; for example, search, user profiles, or simple display.
  • Choose the appropriate BDC authentication modes.
  • Consider using the Enterprise Single Sign-On features provided by SharePoint to authenticate to back-end data sources.
  • Consider using the BDC Definition Editor from the OfficeServer SDK to minimize errors when creating the Application Definition File (ADF).
  • Consider loading the BDCMedata.xsd schema into Visual Studio to minimize errors if you are manually editing the ADF.
  • Consider using the most recent data access drivers for the data sources if possible to improve performance.
  • Define an appropriate search scope to avoid over-exposing data.
  • Consider using the BDC Security Trimmer for custom security trimming of entity instances if required.

SharePoint Object Model

SharePoint exposes an object model that allows you to write code that automates processes. For example, you can implement custom versioning for documents, or enforce custom check-in policies.

When writing custom code using the SharePoint Object Model, consider the following guidelines:
  • Dispose the SharePoint objects that you have created after use to release unmanaged resources.
  • Dispose the SharePoint objects appropriately in exception handlers.
  • Consider using the Using statement when creating SharePoint objects if possible.
  • Consider thread synchronization and thread safety when you must cache SharePoint objects.
  • Consider loading the data from SharePoint objects into a DataSet or DataTable if caching is required.
  • When elevating privileges, note that only new SharePoint objects created after elevation will use the elevated privileges.

InfoPath Form Services

InfoPath Forms Services provides users with the capability to use browser-based forms based on form templates stored in SharePoint and exposed to the user through Microsoft Office InfoPath. When deployed to a server running InfoPath Forms Services, forms based on browser-compatible form templates (.xsn) can be opened in a Web browser from computers that do not have Office InfoPath 2007 installed, but they will open in Office InfoPath 2007 when it is installed.

When designing to use InfoPath Forms for Forms Services, consider the following guidelines:
  • Consider using Universal Data Connection (UDC) files for flexible management of data connections and reusability.
  • Use the Design Checker to check for compatibility issues in browser forms.
  • Consider selecting the Enable browser-compatible features only option when designing forms for the browser to hide unsupported controls.
  • Consider submitting the form data to a database when reporting is required.
  • Consider using multiple views, instead of a single view with hidden content, to improve form display performance.
  • Consider using Form View when configuring session state for InfoPath Forms Services.
  • When exposing forms to public sites, ensure that form templates cannot be accessed by scripts or automated processes to prevent Denial of Service (DoS) attacks.
  • When exposing forms to public sites, do not include sensitive information such as authentication information, or server and database names.
  • Consider enabling protection to preserve the integrity of form templates and to prevent users making changes to the form template.
  • Do not use InfoPath Form Services when designing reporting solutions that require a large volume of data.
  • Do not rely on the apparent security obtained by hiding information using views.
  • Consider storing any sensitive information that is collected by the forms in a database.

Excel Services

Excel Services consists of three main components. Excel Calculation Services (ECS) loads the workbook, performs calculations, refreshes external data, and maintains sessions. Excel Web Access (EWA) is a Web Part that displays and enables interaction with the Excel workbook in a browser. Excel Web Services (EWS) is a Web service hosted in SharePoint that provides methods developers can use to build custom applications based on the Excel workbook.

When designing to use Excel Services, consider the following guidelines:
  • Consider configuring Kerberos authentication or Single-Sign-On (SSO) for Excel Services to authenticate to SQL Servers databases located on other servers.
  • Publish only the information that is required.
  • Configure the trusted file locations and trusted data connection libraries before publishing workbooks.
  • Ensure that the Excel workbooks are saved to the trusted file locations before publishing.
  • Ensure that ODC files are uploaded to the trusted data connection libraries before publishing workbooks.

Deployment Considerations

When designing a deployment strategy for your SharePoint Line of Business (LOB) applications, consider the following guidelines:
  • Consider packaging your components into features.
  • Determine the scope for your features, such as Farm, Web Application, Site Collection, or Site.
  • Consider packaging your features into solutions.
  • Consider deploying your assemblies to the BIN folder instead of the Global Assembly Cache.
  • Use Code Access Security instead of running the Web application in medium or full trust mode.
  • Test your solution after deployment using a non-administrator account.

Pattern Map

Category Relevant Patterns
Workflows Data-driven workflow
Human workflow
Sequential workflow
State-driven workflow

Key Patterns

  • Data Driven Workflow. The sequence of the tasks in the workflow is determined by the data of the system data.
  • Human Workflow. The workflow involves tasks to be performed by humans.
  • Sequential Workflow. The tasks in the workflow follow a sequence and one task is initiated after completion of the preceding task.
  • State Driven Workflow. The sequence of the tasks in the workflow is determined by the state of the system.

Technology Considerations

  • Use Windows Workflow to simplify development of workflows that automatically support secure, reliable, transacted data exchange, a broad choice of transport and encoding options, and provide built-in persistence and activity tracking.
  • Use BizTalk Server 2006 if you need to interact with non-Microsoft systems, perform EDI operations, or require very complex orchestrations.
  • Use MOSS only if your business layer is confined to a single SharePoint site and does not require access to information in other sites.

patterns & practices Solution Assets

Additional Resources

For more information about using MOSS and WSS to build SharePoint Line of Business (LOB) applications, see the following resources:

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


No comments yet.