Application patterns describe general solutions to commonly occurring business problems in enterprise-scale architectures. Application patterns are one layer above design patterns. The Partner Portal application implements the following application patterns:
- Event-Driven Site Creation. This pattern describes a model for creating a site in response to an event.
- Application Instance Resolution. This pattern describes a model that automatically directs users to the appropriate area for information partitioned across site collections.
- Business Event Coordination. This pattern describes a model for coordinating events between external systems and SharePoint.
Business Event Collaboration Overview
A business event is a representation of something that happens while a line-of-business (LOB) system executes a business process. The event is usually a standard occurrence that requires no intervention, such as when a product is shipped to a customer. However, some events represent exceptions to the standard process and require more action. An example is a shipping delay that occurs because a truck breaks down. Although events of this type still involve some computational processing, they also often require human intervention to resolve them.
The shipping delay illustrates how a business's structured processes can be intertwined with informal processes. (Informal processes are the actions employees take to solve problems.) Typically, coordination between the two is missing in businesses today.
LOB systems support complex processes that are comprised of a series of procedural steps. For example, fulfilling an order can require integrated processes to build the product, package it, ship it, invoice for it, and receive payment. Companies use Enterprise Resource Planning (ERP), Material Requirements Planning (MRP), and logistical systems to manage these processes.
However, when a problem occurs, employees must often resolve the issue. They use telephone calls, send e-mail messages and documents, exchange opinions, and make decisions. For a delayed shipment, a customer representative may resolve the logistical issues and identify ways to compensate the customer for the late delivery. These decisions are later recorded in the LOB systems.
In some cases, informal interactions are part of the normal business process. A good example is a response to a proposal in a sales process, which can involve many people and conversations. The LOB system is the repository for the result that the informal but complex process produces.
The following illustration represents a simplified view of interactions that occur between formal and informal processes when a Contoso partner has a problem that escalates to the critical level of a tier three incident.
Interactions of processes
The area labeled 1 represents a typical informal process. Employees manage problems with phone calls, e-mail messages, and status updates that are relayed to the internal incident management system. Much of this activity is invisible to the customer.
The area labeled 2 represents a different approach. SharePoint automatically creates a collaboration space when the incident escalates to tier 3 based on an event from the incident management system. It displays data that is stored in the LOB system and centralizes the information from both the formal and informal processes. The following diagram illustrates the process of collaborating on a business event.
Collaborating on a business event
The diagram shows that either business rules within the LOB system or human action can trigger the collaboration. SharePoint creates a Web site where Contoso employees can work with the partner to resolve the problem. At some point, the incident is completed or closed. This action can happen in either the LOB system or on the collaboration system, depending on how the company structures its processes. For example, one company might decide that an incident closed is always closed in the LOB system because there is a set of policies that must be met and that are enforced by the system. Another company might decide that it always wants the customer to determine whether an incident is resolved. In this case, the incident is closed in the collaboration space. The end result is that either the LOB system or SharePoint must close the incident and inform the other system that it can do the same.
The following diagram shows how the Event-drive Site Creation pattern and the Business Exception Collaboration pattern satisfy the collaboration scenario. It illustrates a more complex case than what was described earlier. In this scenario, which is implemented in the Partner Portal application, the event can apply to one of several partners.
Patterns for collaboration
The combination of the Event-Driven Site Creation pattern and the Business Exception Collaboration pattern helps businesses solve the problem of integrating formal and informal processes. An additional pattern, the Multi-Site Resolution pattern, enhances the solution when multiple customers are involved in partitioned collaboration spaces.
The following sections describe each of these application patterns: