Integration with SharePoint Products and Technologies

If you have existing investments, you should use them. From an infrastructure standpoint it’s always ideal to have one uber repository, one uber solution that solves all your problems. However, that’s not always practical. Migration of content takes time, effort and money. Also, the learning curve for learning new technologies and changing the corporate culture is another challenge. What this means, specifically when looking at new portal technologies, is that it’s important to choose a set of technologies that are flexible and that can integrate with your existing systems.

As part of the Portals team at Microsoft, of course, I’m biased. 🙂 But putting that aside, I can assure you that SharePoint Products and Technologies (WSS and SPS) have been developed with flexibility in mind. The older versions of the technologies weren’t as flexible. But in 2003, we invested a lot of time and R&D to make sure we built it right; that we architected it right.

So, let’s get right to it. How can you leverage/integrate with existing systems with SPS and/or WSS? Here are some things to think about.

1. Web Parts and .NET Framework. Web Parts are .NET Server Controls and you can leverage everything the .NET Framework has to offer. This means, ADO.NET, being able to consume web services (there’s a whitepaper on the topic on MSDN). This also means that if your existing systems expose managed APIs, you can call them just like you would with any other server control. Recently, we released a WSRP sample that shows you how you can consume content from other portals; we also released samples for SAP. Check out for more information. Similary, several partners have built web parts to integrate with different system. What does this mean – you don’t have to build everything by yourself. Also, we provide you with out of the box web parts that can expose content/information from other portals – for example, the Page Viewer Web Part is a quick way to expose a web page that lives somewhere else.

2. XML Web Services. Out of the box, with WSS and SPS, we ship with well-tested XML Web Services. This means that other line of business applications and portals can consume and publish content to and from WSS/SPS. As mentioned in part 1), you can also call/consume XML Web Services easily.

3. Document Event Handlers. As I mentioned in another posting, this version is very flexible as you can implement document event handlers. What does this mean? Let’s say you are using WSS or SPS for collaboration but have another portal where you want the content to be published. In that case, you could implement some custom code to move the content on a certain action.

4. Search. As a corporation, your content is going to exist everywhere. SPS Search is very flexible in its architecture allowing you to search different repositories as well as content types. There’s documentation on developing IFilters and Search Protocol Handlers available on MSDN. Several companies have developed IFilters (for example Adobe’s PDF IFilter) that you can leverage. Net/net: it doesn’t matter where your content lives. SPS Search can crawl and index different repositories and content types so that, as far as the end user is concerned, the content is coming from the portal. This is very powerful and a great way to provide a unified view.

5. SharePoint API. The WSS and SPS API are extensive. This means you can very easily integrate other applications with WSS/SPS. For more information, take a look at the SDKs.

6. Single-Sign On Component. SPS comes with an SSO component. This allows you to expose data, content and logic that is specific to a particular user or group without the user having to sign in multiple times. For more information, take a look at the Single Sign On whitepaper.

7. 3rd party authentication providers. Recently, RSA and Netegrity announced integration of Cleartrust and Siteminder respectively with WSS and SPS for authentication. I encourage you to visit their websites for more information on the specifics.

8. BizTalk Server – BizTalk Server comes with hundreds of adapters. If you already use BizTalk, you can use this to integrate with other data sources.

9. Integration with Office. This is out-of-the-box and one of the values provided by WSS and SPS.

10. Integration with some other MSFT Products. There are several accelerators and guidance that you should explore. These are free of charge.

11. Partner solutions. Companies like Vorsite, workflow partners, and several other partners allow you to very easily integrate with other systems with minimal code.

In short, WSS and/or SPS is very flexible. I’m sure I left out a few points here, but the point is that we really did architect and build this product to integrate with other systems. Many customers use many of the points above to integrate with their systems.


Comments (10)

  1. Mike Walsh Helsinki says:

    It’s an interesting piece, but it’s long overdue that an IFilter for Acrobat (and an icon for .pdf files) comes in-the-box.

    There’s no logic in forcing every administrator to install the Adobe IFilter and add an icon to the site and the correct file before declaring a WSS (/SPS 2003) site open for business.

    IFilters for less common things: OK, let third-party suppliers make them available, but Acrobat files are everywhere.

  2. JOPX says:

    I actually wrote a blogposting about it as well, but yours is definitely more elaborate …

    <a href="">Integrating SharePoint and SAP</a>

  3. I was in Paris, France, this week. I had the opportunity to meet consultants from MCS Europe, customers,…