Application Architecture Guide - Chapter 21 - SharePoint Line-Of-Business (LOB) Applications

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 21: SharePoint LOB Applications

Objectives

  • Define a SharePoint line-of-business (LOB) application.
  • Learn the key scenarios and design considerations for LOB applications.
  • Learn the key components and services for SharePoint LOB applications.
  • Learn deployment options for SharePoint LOB applications.

Overview

Microsoft® Office Business Applications (OBAs) can integrate LOB processes with rich user experiences for data access, data analysis, and data manipulation by using role-tailored business portals built on top of Microsoft 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 large numbers of users.

WSS integrates tightly with the broader Microsoft platform. Microsoft 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 user interface UI).

Figure 1 shows the key features and layers of a SharePoint LOB application.

AppArchGuide - App Types - SharePoint LOB.png

Figure 1 Key features of a SharePoint LOB application

Layers

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 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. The Microsoft Office client applications are used for information processing and collaboration. Office documents, such as Microsoft Office 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, by using Excel Services. It can 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. Microsoft Office System applications can integrate with a service-oriented architecture (SOA). The Office system also supports workflows using Windows Workflow Foundation (WF), which can provide business process or document life-cycle 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.
  • 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.

Tiers

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 non-distributed 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 want to deploy the components for the application services layer on a separate application server or application farm.

Key Components

MOSS assists in providing content-management features and implementing business processes. SharePoint sites support specific content publishing, content-management, records-management, and business-intelligence needs. You can also conduct effective searches for people, documents, and data, participate in forms-driven business processes, and access and analyze large amounts of business data.

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

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

Design Considerations

While SharePoint provides many of the basic features you will use when interfacing with an 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 the 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.
  • Avoid tight coupling between layers. Use Web services to 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 back-end 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 back-end system behavior without extensive code development.

SharePoint LOB Frame

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 table lists the common issues for each category where mistakes are most often made.

Table 1 SharePoint LOB frame Category Key issues Documents and Content Storage * Storing transient or transactional data in lists

  • Using the document library as source code control

Web Parts * Not securing Web Parts

  • Deploying Web Parts in GAC when security is required
  • Combining multiple functionalities in a Web Part
  • Adding styles to controls in Web Parts

Workflow * Failing to choose an appropriate workflow technology

  • Failing to consider workflow update scenarios

Business Data Catalog * Overloading the staging area

  • Over-exposing data to users
  • No authentication while connecting to data sources

SharePoint Object Model * Not releasing objects after use

  • Failing to choose an appropriate caching technology
  • Caching volatile data
  • Caching sensitive data

InfoPath Form Services * External scripts accessing forms

  • Revealing sensitive information to the end user

Excel Services * Data stores not authenticating the users

  • Not securing Open Data Connection files
Category Key issues
Documents and Content Storage * Storing transient or transactional data in lists
  • Using the document library as source code control
Web Parts * Not securing Web Parts
  • Deploying Web Parts in GAC when security is required
  • Combining multiple functionalities in a Web Part
  • Adding styles to controls in Web Parts
Workflow * Failing to choose an appropriate workflow technology
  • Failing to consider workflow update scenarios
Business Data Catalog * Overloading the staging area
  • Over-exposing data to users
  • No authentication while connecting to data sources
SharePoint Object Model * Not releasing objects after use
  • Failing to choose an appropriate caching technology
  • Caching volatile data
  • Caching sensitive data
InfoPath Form Services * External scripts accessing forms
  • Revealing sensitive information to the end user
Excel Services * Data stores not authenticating the users
  • Not securing Open Data Connection files

Documents and Content Storage

Office documents, such as Excel spreadsheets, are stored in document libraries. You can use the Microsoft Office 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 to define additional metadata of the document in a centralized way.
  • Identify and plan your content types. Create the content type at the site level if it needs to be available on any child site. Create the content type at the list level if it needs to be available only to the list.
  • Define unique metadata field names and their associations, document templates, and custom forms with the content types.
  • Design content types to make use of their inheritance capabilities. Content types created at root sites can be automatically used in child sites. 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
  • 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 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. Use a document library to store only the documents that require collaboration and management.
  • Do not use SharePoint document libraries as source code control or as a platform for development team members to collaborate on source code. Use Microsoft 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 UI 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.

Consider the following guidelines when using Web Parts in your SharePoint LOB applications:

  • 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.
  • Consider creating a custom code access security policy to increase the permissions of your Web Parts.

Consider the following guidelines when developing Web Parts:

  • 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 in order to improve maintainability.
  • Design Web Parts to perform only a single function in order to improve reuse.
  • 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 on Web Part Pages by users at run time.
  • 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 of 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. Consult a subject matter expert or business analyst to review existing business processes.
  • Ensure that 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.
  • 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.
  • Consider using Visual Studio 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.
  • 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 Globally Unique Identifier (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 in order to improve manageability. Assigning a workflow to a type implies that you can use a workflow in many different content libraries, but only have to maintain it in one place. Note that this functionality is available for out-of-the-box and Visual Studio workflows, but not for SharePoint Designer 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 by using familiar interfaces.

Consider the following guidelines when developing BDC applications:

  • Review the structure of data sources to ensure that they are suitable to be consumed directly by the BDC.
  • Determine how the data will be used; for example, search, user profiles, or simple display.
  • 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 Office Server 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 in order 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.

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.
  • Dispose of the SharePoint objects appropriately in exception handlers.
  • 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 Form 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 Form 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.

Consider the following guidelines when designing to use InfoPath Forms for Form Services:

  • Consider using Universal Data Connection (UDC) files for flexible management of data connections and reusability.
  • Consider creating symmetrical forms—which look and operate exactly the same way whether they are displayed in the Office SharePoint Server Web interface, or within an Office system client application, such as Microsoft Office Word, Microsoft Office Excel, or Microsoft Office PowerPoint®.
  • Use the Design Checker task pane of Office InfoPath 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 the performance and responsiveness of your forms.
  • 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 in order 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 from 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 that developers can use to build custom applications based on the Excel workbook.

Consider the following guidelines when designing to use Excel Services:

  • Consider configuring Kerberos authentication or single sign-on (SSO) for Excel Services to authenticate to SQL Server 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 Office Data Connection files are uploaded to the trusted data connection libraries before publishing workbooks.

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 non-administrator account.

Pattern Map

Key patterns for workflows are listed in the following table. Consider using these patterns when making design decisions for workflows.

Table 2 Pattern Map Category Relevant patterns Workflows * Data-Driven Workflow

  • Human Workflow
  • Sequential Workflow
  • State-Driven Workflow
Category Relevant patterns
Workflows * Data-Driven Workflow
  • Human Workflow
  • Sequential Workflow
  • State-Driven Workflow


For more information on the Data-Driven workflow, Human Workflow, Sequential Workflow, and State-Driven Workflow patterns, see “Windows Workflow Foundation Overview” at http://msdn.microsoft.com/en-us/library/ms734631.aspx and “Workflow Patterns” at http://www.workflowpatterns.com/

Pattern Descriptions

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

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 Windows Workflow (WF).
  • If you require workflows that implement complex orchestrations and support reliable store-and-forward messaging capabilities, consider using Microsoft 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 ESB Guidance for BizTalk Server.
  • 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.

Additional Resources

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

Retrieved from "http://guidanceshare.com/index.php?title=Application_Architecture_Guide_-_Chapter_21_-_SharePoint_Line-Of-Business_(LOB)_Applications&oldid=7192"