Share via

Chapter 28: Designing SharePoint LOB Applications

  • Article

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

Contents

  • Overview
  • Key Scenarios and Features
  • General Design Considerations
  • Specific Design Issues
  • Technology Considerations
  • Deployment Considerations
  • Relevant Design Patterns
  • Additional Resources

Overview

In this chapter, you will learn about the architecture for a typical SharePoint line-of-business (LOB) application, and the components it contains. You will see the key scenarios and the important design considerations for SharePoint LOB applications. You will also learn about deployment, key patterns, and the technology considerations for designing SharePoint LOB applications.

Microsoft Windows Server® is the core operating system on which SharePoint LOB applications run. SharePoint integrates tightly with the broader Microsoft platform, using Internet Information Services (IIS) as a front-end Web server to host Web sites, and SQL Server as the networked store for site definitions, content type definitions, published content, and configuration data. SharePoint LOB applications can be configured to publish Internet-facing content through Web sites that can scale out with Web farm deployment to service large numbers of users, and integrate with ASP.NET to provide LOB data presentation for these sites. They can use ASP.NET Web Parts, styles, themes, templates, server controls, and user controls for the UI. Figure 1 shows the key features and layers of a SharePoint LOB application.

Ee658091.006ac2a7-5c20-4f6d-831a-04eb06f87915(en-us,PandP.10).png

Figure 1

Key features of a SharePoint LOB application

Office Business Applications (OBAs), described in Chapter 27, can also integrate LOB processes to provide 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).

Logical Layers of a SharePoint LOB Application

The following list describes each of the layers of a SharePoint LOB application:

  • Presentation layer. This is the UI of the application. Users connect through a Web browser to the SharePoint Server Portal, which is composed of Web pages. These Web pages can be assembled by 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. 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 layer also implements features for creating and publishing reports, in the form of either SharePoint lists or Excel spreadsheets. It can also generate output in the form of a dashboard composed of information drawn from multiple services. In addition, as described in previous chapter, Office client applications can be used for information processing and collaboration.
  • Application services layer. This is a reusable layer within the application that exposes services used by the productivity and presentation layers. It includes Excel Services for reporting, workflows that use Windows Workflow Foundation (WF) to implement business processes or document life-cycle management, and other business Web services. Additionally, clients can access data using the Business Data Catalog (BDC).
  • Data layer. This layer encapsulates the mechanisms for storing and accessing all of 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.

Physical Tier Deployment

The previous section describes the logical grouping of components or functionality of a SharePoint LOB application into separate layers. You must also understand the physical distribution of components on separate servers of your infrastructure. The following list describes the common scenarios and guidelines:

  • Deploy the databases for SharePoint on a separate database server or database cluster for maximum reliability and performance.
  • In a nondistributed scenario, deploy the presentation, productivity, and application services layers on the same Web server or a Web farm.
  • In a distributed scenario, you can deploy the components of the presentation layer (portals, sites, pages, and Web Parts) on a Web server or a Web farm, and the remaining layers and components on a separate application server or application farm.
  • For maximum performance under severe load, you might decide to deploy the components for the application services layer on a separate application server or application farm.

Key Scenarios and Features

SharePoint LOB applications are designed to interoperate using open standards, standard file formats, and Web services. The metadata definitions of SharePoint LOB solution objects are based on XML schemas. All Office System products are service enabled at all levels, and use interoperable OpenXML file formats as the default schemas for business documents they create.

MOSS assists in providing content management features and implementing business processes in SharePoint LOB applications. SharePoint sites support specific content publishing, content management, records management, and business intelligence requirements. You can also conduct effective searches for people, documents, and data; participate in forms-driven business processes; and access and analyze large volumes of business data. The following list describes the features of SharePoint LOB applications:

  • 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, SQL Server Analysis Services cubes, and a variety of other sources. Because this data is hosted within 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 allow users to interact with LOB data using familiar interfaces.
  • OpenXML file format. Adoption of the OpenXML file format across the Office System applications facilitates rich server-side document manipulation.

General Design Considerations

While SharePoint provides many of the basic features you will use when interfacing with a LOB application, there are several key design issues that you must consider. These include user experience and the choice of client interface, as well as operational and maintenance issues. Consider the following guidelines when designing a SharePoint LOB application:

  • Enable a user experience tailored to the user’s role. Provide different UI options based on the user’s role. SharePoint contains functionality that allows you to automatically tailor the display based on user roles and groups. Utilize security groups or audience targeting to provide only the relevant options to users.
  • Integrate LOB systems with Office client applications. Choose patterns, such as the Direct Access pattern or Mediated pattern, to integrate LOB systems with Office client applications that are specific to the solution and the functional requirements. Consider ADO.NET or Web services for the Direct Access pattern. Consider using MOSS as a middle-tier application server for the Mediated pattern. For details of these patterns, see Chapter 27 "Designing Office Business Applications."
  • Avoid tight coupling between layers. Use Web services to resolve dependencies and avoid tight coupling between the layers.
  • Consider remote data synchronization requirements. All 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.
  • Expose back-end LOB data through services for use in SharePoint and OBAs. Exposing your networked data system via services allows SharePoint and OBA extensions to request, manipulate, and reformat data for the user. In this way, SharePoint can be used to extend networked system behavior without extensive code development.

Specific Design Issues

There are several common issues that you must consider as you develop your design. These issues can be categorized into specific areas of the design. The following sections contain guidelines to help you resolve the common issues in each area:

  • Business Data Catalog
  • Document and Content Storage
  • Excel Services
  • InfoPath Form Services
  • SharePoint Object Model
  • Web Parts
  • Workflow

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. Consider the following guidelines when developing BDC-based applications:

  • Review the structure of data sources to ensure that they are suitable for direct consumption by the BDC, and determine how the data will be used; for example, search, user profiles, or simple display. Ensure that you define an appropriate search scope to avoid over exposing data. Also, check that you are using the most recent data access drivers for the data sources to maximize performance.
  • Ensure that you authenticate users, and authenticate processes when connecting to data sources. Consider using the enterprise single sign on (SSO) features provided by SharePoint to authenticate to networked data sources.
  • Consider using the BDC Definition Editor from the Office Server SDK to minimize errors when creating the Application Definition File (ADF). If you manually edit the ADF, consider loading the BDCMedata.xsd schema into Visual Studio to minimize errors.
  • Consider using the BDC Security Trimmer for custom security trimming of entity instances, if required.
  • Avoid overloading the staging area.

Document and Content Storage

Office documents, such as Excel spreadsheets, are stored in document libraries. You can use Office desktop applications to consolidate diverse content from multiple data sources. Consider the following guidelines when storing content in SharePoint:

  • When storing documents in document libraries, use content types and their inheritance capabilities to define additional centralized metadata for each document type. Content types created at root sites can be used in child sites automatically. In addition, new content types can be derived and extended, starting from existing content types. Rather than manage each content type individually, use this behavior to simplify the maintenance of content types.
  • Identify and plan the content types you will need, and define unique metadata field names and their associations, document templates, and custom forms with the content types. Create the content type at the site level if it must be available on any child site. Create the content type at the list level only if it must be available to just that list.
  • Consider customizing the Document Information Panel to collect content type metadata in order to track and edit metadata for documents. You can add business logic or data validation to the Document Information Panel.
  • Consider storing user-configurable reference data or nontransient data in lists. However, do not treat SharePoint Lists as database tables. Use a database to store transient or transactional data. Consider caching the contents of a list in a DataTable or DataSet if the list will be queried multiple times in your application.
  • Do not replace file systems with SharePoint document libraries, or attempt to use SharePoint document libraries as a source code control mechanism or as a platform for development team members to collaborate on source code. Use a document library only to store documents that require collaboration and management.
  • Consider the restriction of a maximum of 2000 items per list container in document libraries and lists. Consider writing your own UI to retrieve items in lists when the list container exceeds 2000 items.
  • Consider organizing documents into folders as opposed to using filtered views. This can provide faster retrieval.

Excel Services

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

  • Ensure that you authenticate all users, and secure your Open Data Connection files. Consider configuring Kerberos authentication or SSO for Excel Services to authenticate to SQL Server databases located on other servers.
  • Configure the trusted file locations and trusted data connection libraries before publishing workbooks, and publish only the information that is required.
  • Ensure that the Excel workbooks are saved to the trusted file locations before publishing, and ensure that Office Data Connection files are uploaded to the trusted data connection libraries before publishing workbooks.

InfoPath Form Services

InfoPath Form Services provides users with the capability to use browser-based forms built on templates stored in SharePoint and exposed to the user through InfoPath. When deployed to a server running InfoPath Form Services, forms based on browser-compatible 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. Consider the following guidelines when designing to use InfoPath Forms for Form Services:

  • Consider creating symmetrical forms, which look and operate exactly the same way whether they are displayed in the SharePoint Server Web interface, or within an Office system client application such as Word, Excel, or PowerPoint.
  • Use the Design Checker task pane of InfoPath to check for compatibility issues in browser forms. Also, consider selecting the "Enable browser-compatible features only" option when designing forms for the browser in order to hide unsupported controls.
  • Consider using multiple views, instead of a single view with hidden content, to improve the performance and responsiveness of your forms. However, do not rely on the apparent security obtained by hiding information using views.
  • Consider enabling protection to preserve the integrity of form templates and to prevent users from making changes to the form template. When exposing forms to public sites, ensure that form templates cannot be accessed by scripts or automated processes in order to prevent Denial of Service (DoS) attacks. Also, ensure that public forms do not include sensitive information such as authentication information, or server and database names.
  • Do not use InfoPath Form Services when designing reporting solutions that require a large volume of data.
  • Consider submitting the form data to a database when reporting is required, and store any sensitive information that is collected by the forms in a database.
  • Consider using Universal Data Connection (UDC) files for flexible management of data connections and reusability.
  • Consider using Form View when configuring session state for InfoPath Forms Services.

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. Consider the following guidelines when writing custom code using the SharePoint object model:

  • Dispose of the SharePoint objects that you have created after use to release unmanaged resources. Also, ensure that you dispose of the SharePoint objects appropriately in exception handlers.
  • Choose an appropriate caching approach, and avoid caching sensitive or volatile data. Consider loading the data from SharePoint objects into a DataSet or DataTable if caching is required. However, you must consider thread synchronization and thread safety if you do cache SharePoint objects.
  • When elevating privileges, note that only new SharePoint objects created after elevation will use the elevated privileges.

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. You can use Web Parts to interact with networked LOB applications or Web services, and to create composite customizable interfaces that support personalization in your SharePoint LOB applications. If you must provide extra permissions for your Web Parts over and above the permissions available to ASP.NET, consider creating a custom code access security policy. Consider the following guidelines when developing Web Parts:

  • Identify suitable functionality that you would like to implement in Web Parts, and identify any data sources with which the Web Parts will interact. Consider using Web Part verbs to allow users to perform discrete actions, and categorize your properties to distinguish them from Web Part properties.
  • Design Web Parts using layering guidelines to partition your presentation, business, and data logic in order to improve maintainability. Design each Web Part to perform only a single function in order to improve reuse, and design them to be configurable or customizable by users where this is appropriate.
  • Implement suitable security measures in Web Parts. Only deploy Web Parts to the global assembly cache where individual user security is not required.
  • Use Web Part Zones to host Web Parts that users can manage themselves at run time. If you are using an ASP.NET Master Page, include a Web Part Manager in master pages that Web Part pages will use. Avoid specifying style attributes directly on controls contained within Web Parts.
  • Properly dispose any SharePoint objects and unmanaged resources that you create in your Web Parts.

Workflow

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. Consider the following guidelines when designing workflows:

  • Be clear on what business process or part of a business process is being automated. Ensure that existing business processes are accurate and documented before physically implementing the workflows, and consider consulting a subject matter expert or business analyst to review existing business processes.
  • Choose the appropriate workflow technology to meet the business requirements. For example, use out of the box SharePoint workflows if business requirements are simple; such as document approval. Consider using the SharePoint Designer to create workflows when out of the box workflows cannot fulfill business requirements.
  • Consider using Visual Studio to develop custom workflows when business requirements require complex workflows or integration with LOB systems, or to create workflow activities that can be registered with SharePoint Designer in order to empower information workers.
  • When developing custom workflows, choose the workflow type that is appropriate for your scenario. Consider state-based and sequential models. Also, consider implementing comprehensive instrumentation within your code to aid debugging.
  • When debugging custom workflows, consider setting the logging level to verbose.
  • Consider versioning your workflow assemblies and changing the solution Globally Unique Identifier (GUID) when upgrading your old workflows. Also, 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 in order to improve manageability. Assigning a workflow to a type means that you can use the workflow in many different content libraries, but you need to maintain it in only one place (this functionality is available for out of the box and Visual Studio workflows, but not for SharePoint Designer workflows). Bear in mind that there can only be one running workflow instance of the same type per list item; and that workflow instances will only start on list items, and not the list itself.

Technology Considerations

The following guidelines will help you to choose an appropriate implementation technology for your SharePoint workflow, and provide guidance on creating Web Parts for custom SharePoint interfaces:

  • If you require workflows that automatically support secure, reliable, transacted data exchange, a broad choice of transport and encoding options, and that provide built-in persistence and activity tracking, consider using WF.
  • If you require workflows that implement complex orchestrations and support reliable store and forward messaging capabilities, consider using BizTalk Server.
  • If you must interact with non-Microsoft systems, perform electronic data interchange (EDI) operations, or implement Enterprise Service Bus (ESB) patterns, consider using the Microsoft BizTalk ESB Toolkit.
  • If your business layer is confined to a single SharePoint site and does not require access to information in other sites, consider using MOSS. MOSS is not suitable for multiple-site scenarios.
  • If you create ASP.NET Web Parts for your application, consider inheriting from the class System.Web.UI.WebControls.WebParts.WebPart unless you require backward compatibility with SharePoint 2003. If you must support SharePoint 2003, consider inheriting from the class Microsoft.SharePoint.WebPartPages.WebPart.

Deployment Considerations

SharePoint LOB applications rely on SharePoint itself to provide much of the functionality. However, you must deploy the additional artifacts, such as components, in such a way that SharePoint can access and use them. Consider the following guidelines when designing a deployment strategy for your SharePoint LOB applications:

  • 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 in order to take advantage of the low level code access security mechanism.
  • Test your solution after deployment using a nonadministrator account.

Relevant Design Patterns

Key patterns are shown in the following table. Consider using these patterns when making design decisions for your SharePoint LOB applications.

Category

Relevant patterns

Workflows

Data-driven workflow. A workflow that contains tasks whose sequence is determined by the values of data in the workflow or the system.

Human workflow. A workflow that involves tasks performed manually by humans.

Sequential workflow. A workflow that contains tasks that follow a sequence, where one task is initiated after completion of the preceding task.

State-driven workflow. A workflow that contains tasks whose sequence is determined by the state of the system.

For more information on the Data-Driven Workflow, Human Workflow, Sequential Workflow, and State-Driven Workflow patterns, see:

Additional Resources

For more information about using MOSS and WSS to build SharePoint LOB applications, see the following resources: