Karsten Grombach’s SharePoint Blog

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.