The highest level object in the SharePoint world is the Web application. There is a one-to-one mapping between the Web Application, the Internet Information Services (IIS) Web site, and the SharePoint content database. The next-highest level object is the site collection. It is just what it sounds like — a collection of sites. These can be top-level portals, individual team sites, project workspaces, records centers or publishing sites, just to name a few. Technically speaking, when you create a new site collection you're actually not creating any sites, just the container in which sites can be placed.

A site collection is a useful construct in SharePoint because it allows a group of sites to be treated as a single entity. For example, backing up a site collection makes it simple to backup and restore a set of related sites. Of course you can also back up individual sites if you want.

Sites within a site collection are hierarchically related, meaning that a single top-level portal may have many different child sites, and each of those child sites may have additional child sites of their own, and that list of sites can go on and on. Typically, at the top level you should limit the number of sites to around 125 for SharePoint. For the total number of sites in a site collection, try to limit it to 2000 sites. For whatever reason, 2000 is a magic number in SharePoint because if you start approaching 2000 items in a single SharePoint place — be that sites in a site collection, lists, and libraries in a site, items in a list or library — you risk running into some performance problems. SharePoint scales very well, and many times you will find that you can go beyond these limits quite easily, but keep that number in the back of your head when planning SharePoint site collections. One rule that you can bank on is that if you believe your single Web application database will grow beyond 100GB, try to spin off some of your sites into a new site collection. Break it down by Controlled sites, such as a company's portal structure, and Uncontrolled sites, such as those used for collaboration. Or break it down by regions, or by subsidiaries. Remember, however, that sharing data across site collection boundaries is not easy without a product like K2. For more information about this, see the topic "Plan for software boundaries" on TechNet (http://technet.microsoft.com/en-us/library/cc262787.aspx).

Sites within a site collection can also readily share information, since the content types, permissions, navigation, and security are typically inherited from the parent. You can choose to not inherit the parent's properties when creating new sites. That can be very useful, for example, when building out departmental sites, but the hierarchical relationship will still remain within the site collection. This inheritance of permissions, at least, goes right on down to individual items within a list or library, including folders. Just as when managing permissions on an NTFS file share, you should probably try to manage permissions at the highest level possible (closest to the first folder on the drive, or the first site in the site collection), and use groups and not individual users. But like NTFS, SharePoint allows you to control things on an item-level basis if needed. You can always revert the permissions to inherit from the parent again if you find it getting unmanageable.

Content types are also shared across site collections. They allow you to track metadata and associate workflows and other custom actions with particular pieces of content, as long as you develop those workflows in Visual Studio if you aren't using K2. Everything that you see in SharePoint is associated with a content type, and content types can inherit from each other. If you're familiar with object-oriented programming, content types are very similar in that a content type may inherit a set or properties, or in SharePoint terms "columns," from its parent content type but then extend that content type to include more properties. For example, a Document content type may have a property of Author, while the Chapter content type that is based on the Document content type has Author as well as Title and Page Count.

Content types are used throughout SharePoint to create documents and list items, update properties on content, and to search and locate information based on those properties. The more granular you can make your content types based on your company's core content, the more useful your SharePoint implementation becomes. Keep in mind that content types are shared at the site collection level (but child content types can also be scoped to a lower-level site if required), so if you have multiple site collections you probably don't want to create the same content types multiple times.

A related concept to content type is site column, which can be thought of as the vertical axis to the content type's horizontal axis. It allows you to manage standard data across multiple lists and libraries, on a property-by-property basis. This is useful at times, but plays a secondary role to content types in most implementations. Multiple content types can be associated with a single list or library, meaning that unlike previous versions of SharePoint and the Office Web Server, documents of different types can be stored alongside each other in the same document library but retain their metadata.

From a SharePoint user perspective, lists, and libraries are the main areas of work in SharePoint. A list tracks information and a library is a place to put documents. Under the covers they are actually the same thing with a slightly different display. Items are added to a list and files are added to a library. Each can have multiple properties based on the type of data being tracked, but basically a document is a type of list item that has a file type associated with it.

In previous versions of SharePoint, before the concept of a content type was introduced, the only way to track data associated with a document or list item was to add them as columns to the library itself. You can still do this with WSS 3.0 and MOSS, but using content types based on your company's information architecture is much more scalable and useful. However, it does take some pre-planning or SharePoint rework if you already have SharePoint running wild in your environment.

WSS 3.0 and MOSS 2007 are built in a modular fashion so that functionality can be added or removed from a particular site or site collection in a very simple and elegant way. This is enabled by two infrastructure features called Solutions and Features. That may sound confusing to call Features a feature of SharePoint, but that's essentially what it is because a SharePoint Feature allows you to package up a set of SharePoint items, such as a library template, a document, a menu item, and a workflow definition, and deploy that as a single package to a SharePoint site. You can also remove that set of items as a group, making the extension of SharePoint much easier to manage.

A SharePoint Solution is a deployable, reusable package that can contain a set of Features, site definitions, and assemblies to apply to sites, and that you can enable or disable individually.

So that is SharePoint at a glance. These are the most important aspects to understand about SharePoint when it comes to deploying and managing it, and for understanding where the K2 integration comes in. Everything else in SharePoint is just a riff on these core concepts.

SharePoint is actually two products, Microsoft Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server (MOSS) 2007, whose differences are often unknown, underestimated, and most often misunderstood.

WSS is the free, entry-level Web-based solution that allows information sharing and collaboration services. MOSS extends the features and services offered by WSS, bringing an enterprise-ready feature set to the collaboration foundation provided by WSS.

WSS provides site provisioning and content management, including features for document storage and document management like metadata, versioning, check-in/check-out, mobile device support, and the Recycle Bin, as well as other collaboration features such as alerts, blogs, and wikis. WSS also includes definitions for a number of different sites, including the Team Site, Document Workspace, Blank Site, Blog, Wiki, and Meeting Workspaces.

MOSS Standard includes the following additional features:

There are a number of features in MOSS, which are known as Enterprise features because they are included in the Enterprise client access license:

Knowing which features are part of WSS and MOSS is necessary for a better understanding of the integration between SharePoint and K2 blackpearl. Many K2 features and wizards work with WSS, but there are a few that work only with MOSS.

The K2 blackpearl installer detects which version of SharePoint you have and installs either the K2 for SharePoint (MOSS) or the K2 for SharePoint (WSS) component. The WSS component includes the following features:

The MOSS component includes the following features:

We will not cover every integration point in detail. The SharePoint wizards available in the K2 Designer for Visual Studio and the K2 Designer for Visio will be covered at a high level in Chapter 13. The K2 Help files provide extensive information about the SharePoint integration, including in-depth information about each wizard, what they do, and how to use them, as well as how to configure and manage the K2 SharePoint integration.

When the K2 for SharePoint component is installed and configured, a new tab called K2 for SharePoint appears in the SharePoint Central Administration site, as shown in Figure 12-1. This page is deployed as a SharePoint feature, much the same way that most of the K2 integration features for SharePoint are deployed.

Figure 12.1. Figure 12-1

From this page you can manage the K2 integration features for content site collections. Content sites are simply site collections that contain SharePoint sites, such as portals, team sites, meeting workspaces and the like, and are unlike sites that are used for Central Administration and the Shared Service Providers. Note that it is not possible to deploy K2 integration features to a particular site in a site collection. You can turn off some of the features individually on the site collection, but that will turn off the features for the entire site collection.

You may be asking "So what do the K2 Integration features provide?" Here is the full list:

When you deploy a K2 SharePoint Workflow Integration process to a SharePoint site, it will also show up as a feature in the Site collection features page and in the K2 Workflow Integration page, both of which can be found in the Site Collection Administration section of the Site Settings page. There are other K2 features that are displayed in the Site collection features page, but be careful not to deactivate these features here, but rather use the K2 Workflow Integration page for managing workflows. Note that it would be a good practice to name your process in a standard way in order to make managing them easier, especially as the K2 Workflow Integration list grows. In the Site Administration section, you are able to manage K2-integrated SharePoint Events. This integration allows processes to start when an item is added to, updated, or deleted from a SharePoint list or library. The additional links in the Site Settings page allow you to manage workflows and features as needed.

The K2 Worklist Web part is managed as a solution instead of a feature, and is displayed on the Solution Management page of SharePoint Central Administration. Browse to this page by clicking the Operations tab, then the Solution management link in the Global Configuration section of the Operations page. This solution allows you to deploy the K2 Worklist Web part to any SharePoint site collection, even the site collection that hosts My Sites so that users can see their K2 Worklist on their personal My Site.

The K2 features that work with SharePoint communicate with the K2 Server through Web services that are hosted on the same IIS server where the K2 Workspace is installed. Under the RuntimeServices folder, there are two Web services in particular that are used in SharePoint scenarios. The first one, SharePointService, allows the K2 features to pass information between SharePoint and the K2 server. For example, the K2 SharePoint Integrated Workflows maintain tasks in the K2 Worklist as well as in the SharePoint task list. Information about the task is written to SharePoint through the K2 SharePoint Web service. This integration is provided so that SharePoint users do not have to browse to a different location to view their tasks, and it is the same way in which the out-of-the-box SharePoint workflow tasks are maintained. However, users can manage their tasks with either the K2 Worklist in Workspace, the K2 Worklist Web part (in SharePoint), or the SharePoint task list.

Other Web services that come into play when working with SharePoint are InfoPathService and OpenInfoPathTask. The first service allows InfoPath forms, either client-based or browser-based, to communicate with the K2 server to retrieve available actions, SmartObject data, and to submit a task form, among other things. The second one allows an InfoPath task to be opened.

The remaining section on the K2 for SharePoint page in Central Administration allows you to create a BDC definition for SmartObject data, which is covered in Chapter 13.

The example scenario is a hypothetical approval process for creating a brochure of products and services offered by a fictitious company.

Everything starts from the Work document library, a storage place for all textual and graphical elements that will be part of the brochure. Every element is going to need approval by the Marketing department.

The workflow manages approval of each element. Once approved, these elements are moved into a second document library containing every approved asset. From this point they are sent to artists and art directors who actually create the brochure, and they must be informed when new assets are ready. In the meantime, if the Marketing and Communication department refuses an item, the workflow sends a notification to the author informing him that the item he submitted was not approved. This scenario is shown in Figure 12-4.

Figure 12.4. Figure 12-4

The first steps set up the environment for the workflow:

These tasks are typically done before you start designing the actual workflow. Now, you can turn to actually designing the workflow:

The design canvas shows the workflow, including the activity you just added and the outcome lines leading from the activity to blank boxes. This allows you to drag two more activities in the two Approved and Declined boxes.

Because of the business logic previously defined, when a document is approved it will be moved into the approved assets library. At the same time, artists and art directors are informed that new assets are available.

Once again, in the design canvas, you will see a new line and blank box leading from the Approved activity.

Figure 12.7. Figure 12-7

To add the e-mail notification feature:

To complete the process, you need to define what should happen if the proposed assets are declined. Following the initial analysis, the originator should be notified by e-mail.

The final step of the workflow is defining who will approve the assets:

During the process deployment operation, the K2 Web Designer Build Process Wizard checks if the workflow is complete and warns you about issues or omissions. You should remember that the framework on which SharePoint is based requires at least a Tasks list in the site where the process will be executed as well as a Workflow History list. Both are required by the workflow.

When you design your workflow, you specify how the process will start. While it could be started automatically, we chose to start this particular workflow manually due to the manner in which the assets are created.

To manually execute a workflow associated to a list or a document library, choose Workflows from the item or the document context menu (as shown in Figure 12-11). On the next page you see a list of available workflows; click the workflow you want to start. Note that if every workflow associated with the list or library is an automatically invoked workflow (for example, the manual option is not specified), the Workflows context menu will not appear. However, once the workflow is running, it will be displayed to the right of the item in the main view of the list or library.

Figure 12.11. Figure 12-11

The Workflows page, which is a standard SharePoint page, allows you to start a new instance of a workflow by choosing among the available ones. You can also check if other workflows are currently running and see further details about the workflow.

The Workflows page, as shown in Figure 12-12, allows you to perform the following actions:

After choosing the workflow you want to start, you can set specific workflow template options. For example, you can set the destination users if the option Users Can Be Specified During Runtime was checked during the workflow creation.

After starting the workflow, remember that you can use the status in the document library for the current status of the workflow, the Workflows page in SharePoint, or the View Flow page in K2 Workspace for a more graphical and real-time view of the current process.

Integration between K2 and SharePoint is not limited to the K2 Web Designer for SharePoint. There are several other K2 Designers that allow SharePoint integration, including the K2 Designer for Visual Studio, the K2 Designer for Microsoft Visio 2007, and the soon-to-be-released K2 Studio. These designers share the common wizard interface, which includes many SharePoint-specific wizards. The wizards are divided into four different types for easier understanding.

These wizards and tools are described in Chapter 9, but in the next chapter, Chapter 13, we will describe each wizard in more detail and give you some ideas on how and when you might want to use them.

Installing the K2 Worklist Web part is managed in the same way as installing any SharePoint solution:

The K2 Worklist Web part is like any other SharePoint Web part. It can be added to any part of a page that supports Web parts, which is just about every page in SharePoint sites. To add the K2 Worklist Web part to a page (if you have the necessary permissions):

SharePoint does not really have any native processes that allow users to request a new site. There are some products that allow this very scenario, but with a handful of the administration-focused K2 SharePoint wizards that are available with K2 blackpearl, namely the Sites and Workspaces, User Permissions, and Lists and Libraries, you can create a process to manage and control this common request. You could extend this process further to retire a site via a process once it has lived beyond its intended timeframe.

Even though SharePoint has a Send To menu option on which you can add the Records Center of a site collection, it requires users to send individual files to the Records Center. Using K2 blackpearl, you could perform a search for files that match a current status, even filtering those records based on the metadata of the content, and send that entire batch of documents to the Records Center in an automated manner. You could also create and delete records Holds in an automated fashion, allowing you to respond to legal or audit requests in a traceable, timely manner.

Using the content management features of SharePoint, you could setup a process that aggregates related content from disparate LOB systems, including SharePoint, and publish that information to a SharePoint publishing page. This could be set up to run on a schedule, as part of a process that is initiated by an action that a user must first take, or by the creation of a new item in a SharePoint list or library. You could also use process-based publishing to move pages to different environments, such as from Staging to Production, and update external data connections in the process.

Having deep integration with InfoPath 2007 and the option to publish forms that will work in the browser means that starting processes and actioning them doesn't require custom forms to be created every time. The flexibility offered with InfoPath forms and InfoPath Forms Services means that business users that are slightly technical can manage their own process forms.

One example of using SharePoint to manage business data is using a SharePoint list. The list contains Project Manager contact information for every customer in your organization. Even if your customer data is stored in a separate, line-of-business system (perhaps because project management duties change on a frequent basis), you don't want to update that dedicated field in the LOB system. Keeping it separate and in SharePoint allows the group manager to regularly review and update the information. With the SmartObject feature in SharePoint, you can build a SmartObject containing the customer project manager information and expose that to any .NET application in your organization. This would be a simple implementation, but perhaps you need to incorporate multiple fields from the LOB database into that SmartObject. You would develop a custom service or use one of the out-of-the-box services, depending on the LOB system, for communicating with the LOB system. Adding those SmartObject methods to the SharePoint SmartObject in order to return data from both SharePoint and the LOB system in a single composite SmartObject would allow data from SharePoint and another LOB system to be exposed, managed, and updated through a single interface.

By default, you don't get much in the way of process versioning when deploying new SharePoint workflows using SharePoint Designer or Visual Studio beyond what you do as a developer to version your assemblies. With K2 blackpearl, each time you deploy a process, the version is updated and every new instance will use the new version. However, already running instances will continue to use the older version of the process until they are completed.

With the upcoming release of Process Portals, you can manage security, see running instances, troubleshoot errors, and even get a graphical representation in real-time of the process in SharePoint. This series of Web parts allows all of the process-based administration that you would normally find in K2 Workspace but through the familiar SharePoint interface.

Although SharePoint offers workflow history logs (usually by using the standard Workflow History list), they are not very useful — not even when viewed using Excel pivot tables. K2 adds two key features related to reporting that greatly improve this scenario. First, workflow reporting SmartObjects can be created for every process deployed to a K2 server, including those that integrate with SharePoint. Second, the K2 Report Designer tool in K2 Workspace is a rich environment for creating standard RDL-compliant reports, so the integration between K2, SQL Server Reporting Services, and SharePoint becomes that much easier. And with the option to export these reports to SQL Reporting Services, combined with the SharePoint and SQL Reporting Services integration, enterprise-class reports can be made available within SharePoint for tracking every process in an organization. This is similar to Process Portals but also allows any amount of customization that is required by the business for making better business decisions and optimizing processes based on real-time information.

Using the K2 Worklist Web part, SharePoint can be used as the central place where users can see a list of their tasks. It is a great improvement over the simple task lists that SharePoint typically uses to assign tasks. While these task lists can be spread over main sites in SharePoint farm, the K2 Worklist consolidates all K2 blackpearl tasks in one place, offering much more information and context to the user as well as the ability to batch action related tasks with a few clicks, greatly improving user productivity.

Although Microsoft is making improvements to the Business Data Catalog, it is not easy to integrate data in SharePoint from LOB systems. Using K2 SmartObjects, creating the BDC definitions does not require any code or manipulation of long XML files to surface this information in SharePoint.