Karsten Grombach’s SharePoint Blog

Over the past weeks I spent quite some time researching the possibilities of automating the test process with SharePoint. Visual Studio Test Edition (or Team Suite) already goes a long way. It offers the following tests types all in one location: Unit testing, Load testing, Performance testing, Stress testing, Web testing and Generic testing (used to wrap external testing tools). Additionally you get tools to manage and maintain you tests all in one location. E.g. Test lists, work items, reports

The following list of links and resources should be useful to complete your testing needs:

Utilise the capabilities of Visual Studios testing features:

First of all learn what team system has to offer: Loads of videos at www.asp.net : Getting Started with Team System

http://www.asp.net/learn/vsts-videos/

Testing SharePoint specialities

Testing SharePoint Alerts in a Test Environment

Free Utility for Testing SharePoint/MOSS 2007 Email Sending in a Development Environment.

http://blogs.officezealot.com/legault/archive/2006/02/02/9143.aspx

Testing SharePoint Search

This article nicely demonstrates how to use visual studios web tests to test SharePoint search:

http://www.helloitsliam.com/archive/2008/04/14/moss2007-–-visual-studio-2008-testing-search.aspx

Testing document upload

Apart from giving a good intro on how to use visual studio tests this article shows what is needed to upload documents in web tests, which really is not trivial.

http://www.helloitsliam.com/archive/2008/06/23/moss2007-testing-with-vs-2008-response-to-comments.aspx

SharePoint load testing & test data creation

http://blogs.msdn.com/edglas/archive/2007/02/17/sharepoint-load-tests.aspx

http://blogs.msdn.com/edglas/archive/2007/02/17/performance-testing-guidance.aspx

Unit Testing

Unit testing SharePoint code quickly becomes a challenge when your code uses the SharePoint context object. This usually involves some kind of mockup code. The following article describes the necessary steps to achieve this. (Actually the article is written for SharePoint 2003/WSS 2.0, but the pattern remains the same.)

http://blog.chapmanconsulting.ca/2006/02/15/Creating+An+NUnit+Base+Test+Class+For+SharePoint+Applications+Part+2.aspx

Layout / Web Testing

IE Tester

IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE8 beta 2, IE7 IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process:

http://www.my-debugbar.com/wiki/IETester/HomePage

Browsershots

“Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here.”
If you don’t like publishing your confidential designs to the internet, the you can either rent your own CPU time or set up your own instance.

http://v03.browsershots.org/

Alternative web testing method

If you can’t use visual studios testing features for some reason then have a look at WSSTester:

http://www.sharethispoint.com/archive/2008/01/22/Automated-Testing-in-SharePoint-with-WSSTester.aspx

Windows SharePoint Services are often marketed as free. But as we all know, there is no such thing as a free lunch: Just because you have an W2k3 license, does not mean you have sufficient client access licenses (CALs) for your customers and partners. And what about the CALs for your SQL Server?

Dan Holme tries to shed some light in the complexity of licensing SharePoint in Extranet scenarios in this article: http://www.officesharepointpro.com/content/1925/licensing-windows-sharepoint-services-.aspx

With more and more SharePoint Farms running as extranet and intranet applications the importance of designing secure applications cannot be stressed enough. This article by Reza Alirezaei is a must read for all serious developers, architects and admins, who wish to thoroughly understand the security relevant aspects of the following topics in SharePoint:

- Identity and Principal Objects

- Web.config

- Web Parts and Custom Application Pages

- Event Handlers

- Timer Jobs

- Workflows

- Elevation of Privilege in Your Code

The article is a bit lengthy to read but definitely worthwhile.

As SharePoint’s popularity keeps on growing, more and more companies which where formerly concentrating on non-Microsoft products, are seeing the need to integrate their existing investments with SharePoint.

I recently had the opportunity to work with some colleagues from IBM on a Proof of Concept (PoC) which should show that Microsoft’s SharePoint (WSS) and IBM’S WebSphere Process Server (WPS) can be integrated within an acceptable amount of effort.

The main goal for the PoC, was to show that content could be created and manipulated securely:

 

The only really feasible way to communicate with SharePoint from Process Server is to call web services hosted on the SharePoint machine. There are two “types” of web services which come into mind, which each have their pros and cons. Calling a web service from Process Service is straightforward. Things start to get interesting, when you start to talk about the authentication method.  In the following I will first discuss the two types of web services and afterwards the available authentication methods.

 

SharePoint offers a whole load of web services which can be used to accomplish a big variety of tasks. (See http://msdn.microsoft.com/en-us/library/ms479390.aspx).

An alternative way is to create you own custom web service facade.  (See http://msdn.microsoft.com/en-us/library/ms464040.aspx).

Use SharePoint default web services:

Pro:

- No coding needed

- Little SharePoint know-how required

Con:

- Not all functionality available (e.g. for security reasons no upload document web service has been implemented)

- Multiple web service calls might be needed to complete one task (e.g. create list item &  set permissions)

- Schema of the return values is “unique” and will be needed to be transformed on the WPS server

- The error messages which SharePoint web services returns, are text only and often don’t indicate the cause of the error (e.g. “Unauthorized error”). Subsequently, debugging can be a real pain.

Create your own web service facade

Pro

- Highest flexibility, as the full power of .NET and SharePoint API is available. An upload document web service can actually be implemented quite easily.

- Specialised web services with typed parameters, which bundle complex functionality, can be created.

- Error handling can be implemented

Con

- Requires .NET / SP development know-how

- Requires deployment/installation

 

The three authentication methods which SharePoint supports are:

- Basic Authentication

- NTLM Authentication

- Kerberos Authentication

Basic Authentication is the easiest to implement. All you have to do is select a check box in IIS.  The Process Server method call only needs to pass a valid set of credentials. The downside is, that when using basic authentication you will be required to use HTTPS only, as the passwords would otherwise be sent in clear text over the network. Most intranet installations I have seen only use the http protocols. Changing such installations to https will not always be possible.

NTLM Authentication is the most commonly used SharePoint authentication method. The key requirement for NTLM to work, is that participating servers are members of the same or trusted domains. In our PoC setup SP and WPS were in different and not trusted domains, so using NTLM was not possible. In real life, this setup will be the case quite often, so using NTLM usually won’t be an option.

Kerberos Authentication is currently seen as the most secure authentication method, and was designed for communication over a non-secure network. Using Kerberos Authentication will require some effort setting it up properly, but is definitely recommended way in the long run.

Technical user or logged-on user?

During the PoC the question arose which user account(s) should be used to call the web services. This question becomes clearer when you ask yourself what you want to see in SharePoint: If a document was uploaded from Process Server into a SharePoint document library, which user account should be set in the created by property of the document: the user who initiated the process from Process Server or a technical user? In our case we decided we’d want a technical user, so that the SharePoint user could see that the document was automatically uploaded/manipulated by some process.

Summary

When integrating Process Server with SharePoint the two key decisions you will have to make are:

- What type of SharePoint web service are you going to use ? (Default or web service facade)

- Which authentication method suits my needs and works in our infrastructure?

The actual implementation then is fairly easy and straightforward.

 

Please feel free to send your comments and feedback.

Not long ago I decided to leave the warmth of my well paid, but somewhat life-consuming consultant job and earn my living on a freelance basis.  I quickly realized that I would be needing my own blog, something colleagues and friends had already encouraged me to do in the past.

This is a report on how I decided which technology to use for my new blog. I had defined the following requirements:

- Ease of use: I want to use Word / Live Writer to write the posts

- I don’t want to learn new technology

- I don’t want to code

- I don’t want to start photoshoping to make my blog look pretty (I have a colour deficiency, so when I photoshop, I’m usually the only one who thinks it’s pretty)

- big community  (Extensibility, Support etc.)

Using SharePoint would have been obvious, but I quickly gave up on that:  50€ /month for having a SharePoint site on some strange domain, which you are not allowed to customize is just to expensive.  My intention was to use Community Kit for SharePoint, as it contains acceptable blogging features, but unfortunately the lower priced hosting providers don’t support the installation of WSPs etc.

So the next candidate was to look a DotNetNuke which has blog module for quite some time now. Since I’ve used DotNetNuke on a few projects and have always liked the concept, I thought it would be  a good idea to work  with something else for a change.
Unfortunately I was put of quite quickly by the performance of DotNetNuke. All DotNetNuke based sites I browsed through, while gathering the bits and pieces (documentation, themes ..) all had this strange lag: The initial response for the page was  quick but it took another 1-3 seconds till the page was fully displayed. What put me off finally, was the fact that DNNs blog module does not support tagging of posts and that you had to install another module to enable Live Writer posting.
[To be fair: At time of writing the performance of the DotNetNuke sites seems to be very good. Maybe they were experiencing high traffic at the time.]

After googling I decided to try out Umbraco, another open-source .net based CMS. The first impression was very good: Very fast, excellent documentation to get you started and very good installer. I had a test site up and running in less than an hour. But when I realized that I would require some tweaking, bit of coding and some desiging to get a blog running,  my enthusiasm dropped rapidly.  To be fair again: I believe that Umbraco team is doing a great job and that you can build flexible and powerful cms solutions using their framework. I’ll definitely have Umbraco in mind when designing future applications.

In sum I had spent nearly two days trying to find something which would suite my needs and still had no blog. As a (nearly) last resort I gave WordPress a try. This is where my dilemma started: WordPress uses PHP and MySQL, technologies a serious SharePoint and .NET developer can only frown at. What convinced me was that it took me less than an hour to set it up and start typing away with live writer: Zero hassle.

I don’t think SharePoint would have been that powerful, even with all the extensions etc. available, but it would’ve gotten the job done. SharePoint is designed to deliver great performance in enterprise scenarios where multiple servers serve on farm. In my situation it would have been overkill.