In most custom SharePoint solution projects you will have to create your own Application Pages, Web Part Pages or other ASP.NET pages to fulfill your requirements. If you are coming from the ASP.NET world you are pretty used to building web forms and similar .aspx pages. Your pages will most of the times then be derived from the System.Web.UI.Page class, but when working with SharePoint you should not use this class as a base.
Instead you should always use one of the following base classes provided in the Microsoft SharePoint APIs.
The LayoutsPageBase (in Microsoft.SharePoint.WebControls) class is the most common class to derive application pages from. This is a very basic class but makes your life a whole lot easier in the SharePoint world.
Pages derived from this class should always reside in the _layouts folder. These pages are called Application Pages (or _layouts pages) and are allowed to contain custom code, compared to Content Pages which reside in SharePoint (such as Web Part Pages). These pages cannot contain customizable Web Parts or Web Part Zones. Creating Content Pages is another story.
The advantages with using the LayoutsPageBase as your base class is that you can easily access the current SharePoint Site or Site Collection with the built-in properties and control the security of the application page.
Access the SharePoint objects
With the LayoutsPageBase class you can use the built-in properties for the Site and Web to access the current Site Collection or Site (both these properties are derived from the UnsecuredLayoutsPageBase class, see below) or use the SPContext class to access the current site and web.
Stop long running operations
You have most certainly created some pages that creates reports or similar that may take a long time to generate and consumes server resources. Some times it takes so long that the user shut downs the web browser and go drink a cup of coffee instead. If you have those kind of pages you should use the StopRequestIfClientIsNotValid method. This method ends the request if the client is no longer connected to the page and saves you of some CPU cycles. On the other hand, if you have these kind of pages - think over and use the SPLongOperation class to inform the user that it will take a while.
The page will also automatically call this method in several of the page events, such as OnLoad and Render.
Security in the Application Page
The LayoutsPageBase class contains a virtual property called RightsRequired, this property can be used to programatically set which rights (on the current Site) that are required to use the application page. By default the rights are checked at the end of the OnLoadComplete, but using the RightsCheckModes property you can disable the check or perform it in OnPreInit instead.
There are also a property called RequireSiteAdministrator that can be overridden to make sure that the user is site administrator.
Exit from the Application Page
If you are creating an application page the uses the ButtonSection control template you will have a Cancel button. The target of this Cancel button is controlled using the PageToRedirectOnCancel property. Just override the property and return a string containing the target of your cancel page.
The LayoutsPageBase class derives from the UnsecuredLayoutsPageBase class, which derives from the System.Web.UI.Page. Only derive from this one directly if you need anonymous and non-authenticated users to access your application page. Most of the methods and properties used in the LayoutsPageBase class comes from this class.
For example the Login Page uses this one as a base.
This was a quick post to get you started with creating custom application pages in SharePoint. So what are you waiting for...
The new Office 2010 clients have been released as a Technical Preview and I'm fortunate to get my hands on them and free to talk about them. The new clients are awesome!
Visio is one of the applications from the Office suite that I use on a daily basis to design, model and draw diagrams, workflows and solutions. Visio 2010 has gotten a really nice facelift and a whole new set of features. The Ribbon has been one of the things I really missed in the 2007 release and the SharePoint integration, that can be seen in the Sneak Peak, looks awesome!
Building workflows for SharePoint has mainly been done using either SharePoint Designer 2007 (dull and not reusable) or Visual Studio (complex). SharePoint 2010 will use the new Windows Workflow Foundation (4.0) and rumors say that SharePoint Designer 2010 and Visual Studio 2010 has even better support for building workflows.
Visio 2010 comes with a brand new template; Microsoft SharePoint Workflow. Using this template you can design your workflow and then export it. This exported file can then be imported to SharePoint Designer 2010 or Visual Studio 2010 (just a guess - Visual Studio 2010 with SharePoint 2010 dev tools is not yet publically available). Another guess is that you can export the workflows from SharePoint Designer 2010 and import them into Visio for better visualization or documentation of the workflow.
You can design your SharePoint workflow just as you would design any other workflow using Visio, drag and drop and make a nice layout. This is great when you are making a specification for your SharePoint solution. Far better is that the ones responsible for the actual workflow or processes can design the workflows for you without knowing a bit about SharePoint, just some basic knowledge of Visio.
Once you're done with your workflow you can validate it, so that you have not missed any branches or any mandatory information. Then you save it as a Visio or file or better export it as a Visio Workflow Interchange (.vwi file).
In Visio you can only make the actual design of the workflow, not the configuration which is done in SharePoint Designer 2010.
The .vwi file is a zip compressed file containing the XOML files (XAML files for workflows) and some Visio information. This XOML file can of course be opened in Visual Studio for editing, you just require the SharePoint 2010 dlls :-)
What I have not been able to test yet is the import in SharePoint Designer 2010, since it requires SharePoint 2010.
I will start using it immediately for designing workflows!
Microsoft SharePoint contains functionality for Records Management, which essentially is a storage for documents that you would like to store and manage in a separate records center to meet certain legal or other requirements or just to make backups of certain document revisions. To be able to create a Records Center you need to have Microsoft Office SharePoint Server 2007 (MOSS). On the other hand you only need Windows SharePoint Services 3.0 (WSS) to send documents to the Records Center.
You configure the Records Center connection in the Central Administration. When connecting to the Records Center all you do is specify a Url to a web service and a name. The Url points to a special MOSS web service called OfficialFile.asmx (http://server/_vti_bin/OfficialFile.asmx). Your receiving Records Center server does not have to be in the same farm as from where you send the document (and it should probably not be either). Another thing is that the receiving Records Center does not even have to be a SharePoint server. It's just a web service and we can implement it anywhere we like.
I thought why not implement it using the Windows Azure technologies? This would be a great solution when you do not want to invest in either MOSS or a new MOSS farm, when you really want your important documents to be stored on a completely different physical location etc.
For this exercise I have used Visual Studio 2008, Windows Azure SDK and the Windows Azure Visual Studio plugin. You also need to have access tokens/claims to the Windows Azure beta.
To create our Cloud Records Center we need to create an Azure Web Role, which hosts the Records Management web service and a page to show our documents and some other logic. Our Records Center should also be able to handle some very basic record routing and metadata.
Note: the complete sample code can be downloaded here.
Create the Web Role project
Create the data storage
Without digging to deep into the Windows Azure table and blob storage I just briefly describe how the storage is implemented. This sample has two tables; one for storing the routings and one to store information about the submitted documents. The blob storage is used to store the actual documents. The Windows Azure SDK contains a sample StorageClient which makes it really easy to work with the data, and this sample is used as a reference in the application.
I've created two classes to represent the tables; DocumentEntity and RecordRoutingEntity and a class that handles the actual data services called DataContext. The data classes has a primary key property combination; PartitionKey and RowKey (inherited from TableStorageEntity from the StorageClient sample) - I only use the PartitionKey and RowKey has a static value.
The RecordRoutingEntity is used to store the name and optional description of the record routings and the DocumentEntity contains some information about the documents and a reference (Guid) to the name of the blob.
Take a look at the code for more information.
To be able to add routings the default.aspx was modified and I also added a Setup.aspx page which creates the tables in the Windows Azure storage.
The OfficialFile.asmx web service
To be able to create our own Cloud Records Center we have to implement the same web service as MOSS offers - the OfficialFile.asmx. The .NET Framework SDK contains a great tool, wsdl.exe, for converting a WSDL from a web service into a server side interface. Use the Url to the web service from any of your MOSS servers.
This will generate an IRecordsRepositorySoap.cs file containing the correct interface for the records management web service. So we create a new Web Service in our project, called OfficialFile.asmx, add our generated interface file to the solution and then we let this new web service implement the interface we extracted from the WSDL. The namespace for the web service is also changed into the same namespace as the official OfficialFile.asmx use.
This interface now contains four methods:
- SubmitFile - the method which retrieves the submitted documents
- GetServerInfo - should return info about the implementation
- GetRecordRoutingCollection - returns all record routing types
- GetRecordRouting - returns info about a specified record routing
The three latter are pretty straight forward and the SubmitFile method receives the file, the route to use (the name of the Content Type) and all metadata of the file. First it creates the document entry in the Document table and the uploads the blob. My sample also validates that there is a valid route and otherwise returns an error.
Put it in the cloud
To get it all to work you have to create a new Hosted Service in the Windows Azure Developers Portal and then you have to create a Storage Account. Modify the Service Configuration of your cloud service to match your storage account.
Build the solution and use the Publish function from Visual Studio to publish your application to the cloud and put it in either the Staging or Production environment and wait for it to start (this may take a while).
Swapping between staging and production has been quite troublesome and results in an error or timeout quite often for me the last few days.
Browse to your cloud web application and add a route or two. The name of the route should correspond to the name of your Content Types.
In the image above I have added a new Route called Document.
To be able to send the documents from SharePoint to our cloud records center, all we have to do is go to Central Administration of your SharePoint farm and configure the Records Center Connection, found under Application Management/External Service Connections/Records Center. Enter the Url of your hosted service and append the OfficialFile.asmx path (http://nnnn.cloudapp.net/OfficialFile.asmx) and enter a name for your Records Center connection.
To try it out, just head on over to a Document Library and add a document and the open up the list item menu and choose Send To - Azure Records Center (in my case).
Wait for the file to be uploaded to your Cloud Records Center.
Then head back to your Azure web application and load the default page. You should now be able to see the document there and click on the link to bring it up.
If you upload a document of a content type that is not registered as a route, then you should get an error.
Now you know how to build a simple Records Center utilizing Windows Azure and known .NET techniques. This is in no way limited to Windows Azure, you can host it or similar solutions anywhere on any platform whenever you want.
If you want to have a Records Center and don't want to buy a MOSS license, then this solution can be a good fit.
The provided code is in no way ready for production. It has no good exception handling nor security checks. It is provided as a sample for you to look at if you need to get started with either building a Records Center or just want to learn something about Windows Azure.
Have a nice summer!