When Microsoft released version 2003 of their SharePoint technologies, something unusual happened. Customers called their vendors, asking what they can do with SharePoint. Often, they had heard about SharePoint but did not know how to take full advantage of its new features. Many people do not understand what SharePoint is or realise that there is no single "SharePoint" product. Hence, various users talk about SharePoint as a content management system, document management system, or consider it to be new portal software. How does Microsoft categorise SharePoint? They call it "collaboration software".
The primary idea of SharePoint is to give people a common workplace where they can share documents, contacts, lists and much more via a web-based interface. Imagine a long running sales project where three or four salespersons are involved. They can use SharePoint to store all the proposals at a single workplace, share the client contact information and perhaps manage a to-do list for themselves. As you can see, SharePoint functions as the glue between Office applications of individual users and the overall project.
There is also pre-existing integration with SharePoint in several Office products. For instance, in Excel, a SharePoint to-do list can be opened and managed in a worksheet. However, my favourite integration example is Outlook. When you create a new meeting request in Outlook, you will invite all participants, specify a meeting subject and maybe add an attachment containing the agenda. This invitation process forwards an email to all participants with the attached agenda. What happens when people wish to add comments to the agenda? They will store the attachment on a local disk, add comments and send an email back with the agenda attached.
On the other hand, if SharePoint extensions are added to your Office installation, you will find a new button in the meeting request dialog – "Meeting Workspace". With two or three clicks, you create a new workplace in SharePoint. Only the participants have access to this workplace (web page), and the attached agenda will automatically be stored in a document library within the created workplace. Participants will receive an email with a hyperlink to the workspace. They can navigate to the page, check out the agenda, make amendments, or add their comments. Whenever an amendment is made to the agenda, others will be notified automatically, assuming notification is enabled.
Infrastructure and Architecture
As mentioned earlier, there is no single SharePoint product. Instead, you will find the Windows SharePoint Services (WSS) and SharePoint Portal Server (SPS). While Windows SharePoint Services is a cost-free download for Windows 2003 Servers, SharePoint Portal Server is a commercial product which is built on top of the SharePoint Services and must be purchased separately. WSS brings the SharePoint infrastructure for building team sites as discussed previously – handling of lists and contacts, document libraries and discussion boards. Even the Web Part infrastructure is part of WSS (See Web Parts). Team sites are organised in site collections, for example, a "projects" site collection contains project relevant sites, while a "R&D" site collection holds research relevant information pages. One impressive feature of WSS is the search engine, which allows you to perform a search over several sites in a collection. You can search list items and contacts, as well as all documents inside a document library in full text.
Web Parts
Web Parts are playing a central role in the concept of SharePoint 2003. They are the building blocks of a team site. Users are able to drag-and-drop a Web Part from the Web Part Collection onto the web page (e.g. a ‘To-do’ list Web Part or ‘Discussion Board’ Web Part). A Web Part is like a black box, it is a closed system. But, it can publish interfaces for exchanging data with other Web Parts. Hence, a Calendar Web Part can publish the selected date, while an Order list Web Part can consume dates to filter its list. The key feature is that users can connect Web Parts themselves such as the linking of Calendar with the Order list at runtime.
While a default set of Web Parts are shipped with SharePoint (WSS and SPS), third-party vendors such as Siebel and SAP also offer their own “blackboxes“. In addition, Microsoft has also started to integrate their applications and published Web Parts for SQL Server 2000 Reporting Services.
This means, you can search for the text within a Word or PowerPoint document that is stored in the document library. While WSS concentrates primarily on single site collections, SharePoint Portal Server comes with additional features, which enhances the handling of multiple site collections. Of course, this is only a brief description of their differences. There are other features such as single sign-on and Exchange Web Parts that are only available in SharePoint Portal Server. In my opinion, the improved handling of multiple site collections, or a large set of (distributed) team sites is what makes SPS attractive. With SPS, you can conduct searches over several site collections. Moreover, team sites can be organised for specific audiences, and users are able to browse by topic through all sites.
From a technical perspective, SharePoint 2003 is a dramatic improvement over the preceding version 2001. The SharePoint team has reengineered a huge portion of the software, especially the web interface which is now based on ASP.NET technologies. However, in most cases, the backend code still remains the same as version 2001’s, as we shall see later. SharePoint 2003 uses SQL Server 2000 as the database engine. Windows SharePoint Services comes with the free Windows Microsoft SQL Server 2000 Desktop Engine (WMSDE), which has no size restrictions of 2 GB, unlike MSDE.
Furthermore, it is also not limited to five concurrent users. But, there are other limitations. For instance, existing database schema is signed and therefore cannot be amended. Hence, you cannot create a custom database for WMSDE. In addition, full-text indexing is also not available with WMSDE. If you require full-text search capability, you will need the SQL Server 2000 Standard or Enterprise Edition. The full-text search is extensible by "IFilter" add-ons. While Office filters are included by default, others like the PDF filter must be installed manually. You can register any available IFilter in SharePoint to include new file types. However, before discussing what data WMSDE (SQL Server 2000) exactly stores, let us review how team sites are organised first.
Team site is a set of pages, where every page is divided into "Zones" that define the page layout. Web Parts, a key concept of building team sites, are placed in these zones. When creating a new team site in SharePoint, you choose a template which generates a set of pre-configured pages with zones and Web Parts. A "discussion template", for example, generates an entry page with a document library Web Part for storing documents and a discussion board Web Part. Additionally, the template creates an edit page for the document library where items can get checked in and out. Every site collection is stored in a "virtual server" in the Internet Information Server (IIS), which carries its own, unique URL that can be opened in a web browser.
Now, let us return to the data storage question. In fact, nearly everything in SharePoint is a list, and a site is only a set of lists. Document libraries, users, calendars, and surveys are all lists. Even the instancing of Web Parts on specific pages in a site is effectively a list. So, how can lists be best stored? Of course, the answer is in database tables. That is what SharePoint does, all data is stored in the database, including even the web pages. Moreover, most data is stored in a single table.
While a purist may think that this is a very bad database design, from a pragmatic, functionality perspective, it is extremely efficient, fast and scalable. However, while you will find ASP.NET pages in SharePoint's directory trees, if you are going to edit them (via FrontPage 2003), the copy will be stored in the database as binary blob and not in the file system. Pages are rendered automatically out of the database during runtime while caching mechanisms ensure good performance. Hence, you do not have to devote additional time or resources to this issue.
In truth, SharePoint scales extremely well – from a single server installation for small- and medium-sized installations up to a server farm for large organisations and heavy usage. In a server farm installation, you can add multiple front-end web servers behind a group of backend servers with WMSDE (or SQL Server). A server farm is assigned to one configuration database, while each virtual server has its own set of content databases.
To enhance performance, the content for the top-level website and any subsites within a site collection is stored in the same database. This concept allows increased performance and capacity by adding additional servers running Windows SharePoint Services and SQL Server. Scaling is achieved by including more front-end web servers to increase throughput for the existing content, as well as adding top-level websites and subsites to support more content. Towards this end, SharePoint offers tools to move from a single server installation to large server farm.
After learning the SharePoint technical fundaments, I shall now introduce two main usage scenarios. First, using SharePoint out-of-the-box with some customisations; and next, using SharePoint’s backend technology for custom win/web-form applications and developing custom Web Parts. Both scenarios are totally independent of what you are using, be it SharePoint Portal Server or the Windows SharePoint Services.
Out of the Box
With SharePoint, you can create amazing custom applications. Technicians tend to forget that SharePoint is ready to run out-of-the-box. You only have to install the software. Hence, let us take some time to go through some built-in features for creating sophisticated collaboration workplaces. Every team site is based on a template which is specified in one step of the site creation wizard. Once the initial team site is set up, it can be opened in the web browser. In many cases, you will find a template which complies to your needs. If not, you are able to amend the created site. Pages of the team site can be modified in two different ways: through the web interface and FrontPage 2003.
Fig. 1: FrontPage 2003 is the ideal customisation tool for SharePoint because of their seamless integration.
The new FrontPage 2003 is rather different from the previous versions, as it provides support for SharePoint 2003. It opens a team site with a URL, and changes made to the pages will be stored automatically, behind the scenes via FrontPage RPC (FPRPC), back to the SharePoint database.
On the other hand, most modifications can also be made to a page through the web-based edit mode, which is available for all users who have edit permissions. You can amend existing pages by adding, removing, or rearranging existing Web Parts. While most SharePoint Web Parts generally represent data (e.g. "Contacts", "Events", "Discussions" or "News"), others such as "Page Viewer" are independent of concrete data. Only specifics like its meta data, URL of the page to display etc., will be stored in the SharePoint database.
As team sites often require more than one contact or to-do list, new, template-based content containers can also be created. After completing the wizard, SharePoint automatically adds a Web Part to the Web Part collection that represents (and is able to display) the new data container. There are many templates available, including Document Library, Form Library (to store XML-based business forms like Infopath forms), Picture Library, Links, Announcements, Contacts, Events, Tasks, Issues, Discussion Board and Survey.
Moreover, custom lists are also possible. In a custom list, the wizard allows you to specify every column of the list by yourself. SharePoint Portal Server has several additional Web Parts and templates for organising a set of site collections. SPS also comes with a set of Exchange Web Parts, which will be interesting for personal sites. In SharePoint, every user can create his/her own personal site. Like every site in SharePoint, it comes with public and private views. Private view is assigned to the user only, while the public view is for everyone visible. In private views, users can build their personal document libraries, to-do lists or links to relevant, related content. For example, by adding the Exchange Inbox Web Part, users are able to browse and read emails inside SharePoint. Inbox Web Part is only one of several such Exchange Web Parts that are shipped with SPS.
Apart from manipulating existing pages, adding new pages (perhaps for displaying the discussion board on a separate page) to a team site is also possible. A Basic Page lets you display simple content items like text, pictures and tables. Create a Web Part Page if you want to add a page that contains one or more Web Parts. If you need a separate workspace under your team site, you can create a whole new subsite derived from a different site template.
Imagine a team site for a software development project. This site should be the first address for all team members – project leaders, requirement engineers, software architects, software engineers and the testing team. We will name this site the "Great Software Project" and its URL is http://teamsites.corp/projects/GreatSoftwareProject. "teamsites.corp" is the URL to the local SharePoint, "projects" is a site collection, and "GreatSoftwareProjects" is our team site inside the site collection. Since the project leader does not want to have a discussion board and his work is more document library oriented than picture library oriented, he needs a different workplace than the software architects. In this case, a new workplace or subsite could provide the solution: http://teamsites.corp/projects/GreatSoftwareProject/ProjectMgmt. This subsite is stored in the site collection of the GreatSoftwareProject site.
Fig. 2: SharePoint enables users to create their own pages and data containers based on several templates.
Until now, we have talked about creating team sites by including content containers, putting Web Parts together and adding new pages to a team site. However, all pages are based on one of the existing design templates as chosen in the create site wizard. With FrontPage 2003, the page design can be modified individually by setting new fonts and colours, or adding a company logo to the page in a WYSIWIG designer. But, these changes are usually set per page only. If you want to create a common design for your entire team site, you should create your own design template. While this article does drill down to details, SharePoint’s out-of-the-box functionality and content creation wizards allows even users with no technical background to manage this process. For those more technically inclined, MSDN contains many step-by-step articles that explain the details of creating templates.
The Collaboration Engine
However, SharePoint’s greatest power is packed in its engine, not the web interface. You can benefit from that in either one of two ways: create your own Web Parts and a custom window or a web form application on top of the engine. If you are familiar with ASP.NET custom control development, it is only a short path to your first Web Part. In brief, Web Part is a custom control that is derived from a special Web Part class.
Instead of overwriting the Render() method, RenderWebPart() must be overwritten. Microsoft publishes templates for Visual Studio on MSDN, containing templates for standard and connected Web Parts. If your Web Part needs a public property which the user sets at runtime, you simply add a public property (get/set) to the Web Part class, and define some attributes in front ([Browsable(..), WebPartStorage(..), …]).
The good news is that you do not have to implement data serialisation and deserialisation yourself. The Web Part infrastructure will handle that. While a simple "Hello World!" is done within minutes, developing connected Web Parts requires more preparation. Though not rocket science, a good understanding of basic concepts and interfaces that must be implemented is still handy. With custom Web Parts, you can add any extra functionality your SharePoint sites may require. Here are some examples: RSS Reader Web Part, Order Entry Web Part (for an existing application), Issue Tracking Web Part, or a simple Vacation Request Web Part.
Many Web Parts I have encountered require access to document libraries and lists. In this case, developers can make use of the SharePoint object model. There are basically three different ways to the object model: by FrontPage RPC (FPRPC), web services, or .NET assemblies. FPRPC is an HTTP-based protocol used by FrontPage 2003 to communicate with SharePoint. It was also available in SharePoint 2001. Even if FPRPC can be used for your own project, it should be your last resort. While FPRPC may be powerful and preferred for some tasks, with respect to performance issues (especially for file transfer), it is much harder to learn than web services and the assembly APIs.
Besides FPRPC, web services are the second way to access the SharePoint engine from a remote machine. Using the assemblies to access the object model is only possible if the application runs on the same machine as SharePoint. Therefore, the assemblies are preferred for Web Parts, which require access to lists and documents. Let us push back the FPRPC interface and concentrate on web services and the assemblies.
SharePoint offers a wide array of web services for common structures such as documents, lists, permissions etc. The development team has made an interesting design decision. To access a list in the site "GreatSoftwareProject", you do not need to set a parameter to the web service call to specify the path. However, you will address the web service under your site path, for example, http://teamsites.corp/projects/GreatSoftwareProjects/_vti_bin/DspSts.asmx.
Unfortunately, some operations are not available in today's web service implementation. Retrieving documents is a prominent example. In this case, performance issues for transferring large files could be the reason that SharePoint’s development team did not add such a call. However, with the web service API, you are able to create a custom win- or web form application which uses the collaboration functionality of SharePoint. Seeing only the front end, users may never know that your application uses the SharePoint document retrieval engine.
Several months ago, I was involved in a SharePoint project for a hospital in Germany. They decided to store patients’ files digitally in SharePoint. Our team prepared a site with a custom set of design templates. In addition to the online interface, we also created a win form-based application. This application was able to scan documents before storing them with a set of keywords to SharePoint. However, we did two things: first, we made use of the Web Service API; second, we created our own web services.
To do this, we made use of the Web Service API to add to our own web service. SharePoint allows you to add your own .asmx files if they are registered in the Web.config file. However, as the custom web service runs on a SharePoint machine, we could use the .NET assemblies to access the object model. In this way, we implemented missing document handling.
In contrast to the SharePoint Web Service API, the .NET assemblies support nearly all features of SharePoint, including document handling operations. Consequently, we just wrote a simple web service wrapper for functions, which are available in the .NET assemblies but not in SharePoint’s Web Service API. However, there was one hitch – several parts of the SharePoint engine base are still based on the previous 2001 edition. Hence, SharePoint’s native naming conventions are the old ones carried over from the previous version. Technically, it should be possible to change the naming conventions for the .NET assemblies but the SharePoint team decided to keep the old definitions. Therefore, for this implementation, a "site" is called "web" and a "site collection" is a "site". Despite this awkward naming convention, the interface has a very good design and most operations are very intuitive. Refer to the code below:
// import namespaces first
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.Administration;
// …
// retrieve a web object by the current context
SPWeb web = SPControl.GetContextWeb(Context);
// get reference to „Task“ list
SPList tasks = web.Lists["Tasks"];
// itereate through all items and write them to a output stream
SPListItemCollection items = tasks.Items;
foreach(SPListItem item in items) {
output.Write(item["Title"].ToString() + item["Status"].ToString() + "
");
}
Where to Start?
As we have seen, SharePoint is a very powerful collaboration engine that is both scalable and highly customisable. The big question is: “Where to start?” I recommend you start with the Windows SharePoint Services. Download and install it to create your first team site. Play around with all the existing templates and Web Parts, learn the "SharePoint words" such as "library", "site", "collection" and so on. If you are an information worker, go on and try to create a site for an existing process in your company. How about a team site for your current project? Why not! If you are a software developer, visit MSDN and browse through the SharePoint content for developers. Download the Visual Studio templates for Web Parts, follow a step-by-step guide and create your own custom Web Part. Find out just how SharePoint can enhance your business.
For Sebastian Weber, software development is one of the most thrilling, colourful and challenging tasks of our time. After 10 years as software architect and engineer, this noted conference speaker and author of industry articles is a Developer Evangelist for the Microsoft Developer Platform & Strategy Group and supports partners at realising their visions.
Links & Literature
• WSS-Download: http://www.microsoft.com/windowsserver2003/techinfo/sharepoint/wss.mspx
• Product information: http://microsoft.com/SharePoint
• Developer resources: http://msdn.microsoft.com/SharePoint
• Customisation resources: http://sharepointcustomization.com
|
