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