Event-Driven Site Creation

Context

There are business events in your organization that require collaboration between employees and/or customers. However, there is no central location for having discussions or storing documents. Activities that occur in the informal processes are unrelated to the LOB processes. When the event is resolved, the relevant information is scattered throughout the organization. You might have instituted a manual process for creating sites where people can collaborate on these incidents, but the sites are not standardized and there is no way to enforce business rules.

Objectives

• You want to automatically create collaboration sites that will help your company to efficiently resolve events.
• You want to allow users to request collaboration sites, but you must control when and where the sites are created.
• You want the information that people have gathered to be centrally organized and accessible.
• You want the ability to add, remove, and change tasks.

The next section describes how to achieve these objectives.

Solution

An implementation of the Event-driven Site Creation pattern creates a site that is appropriate for the particular type of event. For example, there can be one type of site for problems such as faulty equipment and another type of site for problems with orders. The site must be correctly located within the site hierarchy. Finally, the site must be populated with information that connects the incident with the site.

The following diagram summarizes these steps.

Event-driven site creation

An LOB system such as a customer relationship management (CRM) system tracks status and controls the incident management process. It stores and provides information such as the customer identifier, the incident identifier, the nature of the incident and the status of the incident. The collaboration site supplements the CRM system by providing a place to track tasks with the customer, exchange supporting documentation, and have discussions. It also allows the customer to monitor the status of the incident with information retrieved from the incident management system. The following sections discuss in detail the steps that are shown in the diagram.

Mapping a Site

Mapping a site determines two things:

• It determines the location of the site within the site hierarchy. Every collaboration site must be the child of a parent site.
• It determines the type of site to create. Effective collaboration sites are standardized for particular types of events. SharePoint has site templates and site definitions that allow you to create repeatable instances of a type of site. Mapping connects a business event to the appropriate type of site. As different events are identified, developers or business analysts can add new mappings.

After you create a site template or site definition, add a mapping definition that connects it to the event. For example, an event type of "tier 3 incident escalation" might map to the "Incident Site Definition." This type of subsite is created under the /partnersite/incidents location.

Creating a Site and Adding It as a Subsite

After the mappings are defined, the site must be created at the correct place in the site hierarchy. The wire and creation steps use the mapping to do this. For example, if a partner reports a problem with an X-ray machine's power supply, you can create an incident site named "Intermittent Power Delay in X-Ray Machine" that uses the Incident Site Definition and add it as a subsite of the parent site that is located at /partnersite/incidents.

Binding Information

Binding adds information to the site that relates it to the event. You can use this bound information to tie context between the collaboration site and the originator of the business event. There are different ways to bind identifying information. The simplest approach adds the information to the site's property bag. The Partner Portal application does this. Using the property bag is straightforward and works for many situations.

In the Contoso example, an incident identifier for the specific incident instance of "Intermittent Power Delay in X-Ray Machine" is placed in the site's property bag. A Web Part that is on the site uses the incident identifier and uses it to retrieve relevant information that is stored in the CRM system. It displays the results on the site. The partner who reported the incident, in addition to Contoso employees who are collaborating with the partner, can see real-time information about the incident's status.

In more complex scenarios, you could bind information at any location on the site. This can require that you develop a custom binding for the event.

Considerations

The Event-driven Site Creation pattern promotes design flexibility, control over site creation, and configurability in the infrastructure. The cost is increased operational complexity, at least in the short term. In the long term, operational complexity may decrease because the pattern fosters a consistent information architecture. This is because sites are created in a controlled fashion.

Site versioning can be complex. Event types that have multiple versions of the site template or site definition can lead to long-term maintenance issues. Use care when defining new site templates or site definitions. Put a control processes in place to make sure that the new versions are warranted. Neither site definitions nor site templates can be updated after they are deployed, although new capabilities may be added to a site definition through a mechanism named feature stapling. One approach is to wait until any active events that use the earlier version are resolved before you deploy the new version. Because business events are generally resolved within a fixed time frame, this strategy is often acceptable. If you use this approach, be careful not to break the features of the older version when the upgrade occurs.

The Event-driven Site Creation pattern can help create a site hierarchy that has a logical structure. A straightforward architecture is easy to partition, access, and organize. Although it is difficult to make a general rule that fits all situations, a parent/child relationship is a good choice for event-driven sites. For example, you can provide a dashboard for all incidents on the parent site that shows all open incidents to the customer. Another benefit is that customers always know to look under the parent site for information about a particular incident. An unplanned site hierarchy can make locating and organizing information difficult.

Home page on MSDN | Community site