Ein ehemaliger Chef stellte mir die Aufgabe, SharePoint in einem Satz zu erklären. Bis heute hatte ich keine wirklich zufriedenstellende Antwort gefunden . Hier ist die , für mich, sinnvolle Erklärung: SharePoint ist eine Ente!

Während meines Studiums an der FH München fiel es mir immer schwer, den Studiengang Wirschaftsingenieurwesen zu erklären.  Sogar Wikipedia fängt nur mit der historischen Entstehung des Studiums an: “Das Studium des Wirtschaftsingenieurwesens wurde in Deutschland erstmals im Jahr 1926 in Berlin angeboten. Die Studienrichtung wurde unter anderem geschaffen, um Nachkommen von Unternehmern eine adäquate Ausbildung anbieten zu können.” Kurzum der Wirtschaftsingenieur hatte häufig Erklärungsnot. Glücklicherweise kam ein genialer Kollege irgendwann auf folgenden Vergleich: Ein Wirtschaftsingenieur ist wie eine Ente.  Eine Ente kann schwimmen, eine Ente kann laufen und sie kann sogar fliegen. Aber sie kann nichts wirklich richtig.

Da dieser Vergleich meiner Meinung nach, hervorragend zu SharePoint passt, habe ich das berüchtigte Tortendiagram von Microsoft, welches ja SharePoint erklärt auf Enten transferiert:

Wie man sieht kommen Enten sowohl in der Luft, auf der Erde als auch im und unter Wasser klar. Nicht immer unbedingt elegant und auch nicht als Klassenbeste in der jeweiligen Disziplin, aber sie schlagen sich gut durch. Und sie können auch Dinge, die man nicht von Ihnen erwartet, wie z.B. Singen.

Genauso so ergeht es einem mit SharePoint. SharePoint kann einem in vielen Szenarien nützliche Dienste erweisen und wird einem immer wieder überraschen. In manchen Szenarien sollte man jedoch sehr vorsichtig sein.

Fangen Enten wirklich Fische?

To explain this, I have go back to my time at university where I studied Industrial Engineering.  We always had difficulties explaining to  other students what  an industrial engineer actually does for a living. This usually lead to long discussions about us being the bridges between commerce and industry because we thought we were capable to unterstand both sides.  But then one day somebody came up with the analogy of industrial engineers being ducks. “A duck?” people would ask. “A duck can do many things. It can walk. It can fly. It can swim. But it annot do any of these things very well.”

To transfer the analogy to the SharePoint world, this is how marketing would sell a duck:

“Sing!?” you say. “A duck can’t sing!”

“Yes it can!”

“You ain’t nothin’ but a rubber duck,
Squeakin’ all the time!”

Have a nice day

Karste Grombach

Ich werde in nächster Zeit immer wieder auf das Thema Wicked Problems, SharePoint und Dialogue Mapping eingehen.

Zunächst was sind Wicked Problems  Die Definition von Wicked Problems geht auf den gebürtigen Berliner Horst Rittel (Bild) zurück. Dieser hat in den 70er Jahren festgestellt, dass ein linearer Lösungsansatz (Wasserfall-Methode) für die komplexen Zusammenhänge bei Stadtplanungen völlig unzureichend ist.  Er leitete daraus Regeln ab, die Wicked Problems kennzeichnen:

Sinngemäß übersetzt:

1. Das Problem ist erst verstanden, wenn eine Lösung gefunden wurde.

2. Wicked Problems haben kein definiertes Ende

3. Es gibt keine richtige oder falsche Lösungen für Wicked Problems, eher bessere, weniger gute oder unzureichende.

4. Jedes Wicked Problem ist einzigartig.

5. Jeder Lösungsversuch kann nur einmal durchgeführt werden.  Danach hat sich das Wicked Problem verändert.

6. Wicked Probleme haben keine definierte, alternative Lösung.

Die bekanntesten Wicked Problems sind Themen wie  globale Erwärmung oder Finanzkrisen.

Nun würde es nicht sehr für das Produkt SharePoint sprechen, wenn alle oben genannten Regeln auf das Produkt zutreffen würden.  Das Wicked Problem in SharePoint Projekten liegt  nicht im Produkt an sich, sondern viel mehr am Umfeld, in dem SharePoint eingesetzt wird.   Wie bei jedem IT Projekt hat man eine schwer zu überblickende Kombination aus Geschäftsanforderungen, Menschen und Technologien.  Was bei SharePoint Projekten erschwerend hinzu kommt, ist die Tatsache, dass viele Projektbeteiligten eine sehr unterschiedliche Vorstellung vom Nutzen von SharePoint haben.  Auf Befragungen erhält man doch sehr unterschiedliche Antworten:

Fachbereich: “SharePoint ist die Wunderwaffe, die meine Fachanwendung in Null-Komma-Nix umsetzt.”

IT Leiter: “Durch Konsolidierung verschiedener Anwendungen, kann ich mit SharePoint mein knappes IT-Budget besser ausnutzen”

Entwickler: “SharePoint ist eine auf .NET basierende Plattform, mit der ich die Anforderungen des Fachbereichs in Code umsetzen kann ”

Admin: “SharePoint ist ein Dokumentenmanagementsystem für den Fachbereich,  das ich neben den anderen Anwendungen betreibe.“

Projektleiter: “Durch Verwendung der SharePoint Standardfunktionen (Out-of-the-Box) müssen wir weniger entwickeln und können  unseren engen Zeitplan einhalten.”

Endanwender: “Kann mir jemand mal dieses SharePoint erklären?”

Kurzum,  SharePoint ist ein geflügeltes Wort unter dem  jeder etwas anderes versteht.  Und genau hier beginnt der Lösungsansatz für Wicked Problems des Herrn Rittel : Wicked Problems werden beherrschbarer, wenn man die menschlichen Beziehungen in den Mittelpunkt stellt und für ein allgemeines Verstehen des Problems sorgt (“Shared Understanding”).

Beiträge in Blogs, Foren, etc. die mir in meinem Projektalltag helfen, sind zum allergrößten Teil auf Englisch. Ich habe diesen Blog deshalb bisher in Englisch geschrieben, da ich der Meinung war, mit meinen Beiträgen, den  Englisch sprechenden Teilnehmern etwas zurückgeben zu können. Michael Greth, in seiner Rolle als Häuptling der SharePointCommunity.de, hat mich jedoch überzeugt, dass es wirklich Sinn macht auf Deutsch zu bloggen: Die meisten meiner Freunde, Kollegen, Kunden und Partner sitzen nun mal in der DACH Region.  Deshalb werden ich in Zukunft die Mehrzahl der Beiträge auf Deutsch schreiben.

Karsten Grombach

Dear SharePoint Community,

I initially started  writing this blog in English with the intention of giving something back to the SharePoint community which has helped me on so many occasions through countless blogs, forums and mails.

In future this blog will mainly be written in German  as  most of my customers, friends, colleagues and partners are German speaking. Please feel free to contact me if you believe that one of my articles might be of help to you .  I will gladly translate it.

Karsten Grombach

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

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

- 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.

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.

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.