Integrating SharePoint with other portals and applications
As more and more companies get past the pilot stage with their SharePoint 2007 deployments and start broad roll-outs in early 2008, there will likely be a significant increase in the need to integrate SharePoint with other portals and applications. We've already seen an increase of integration and interoperability related inquiries and escalations from our customer teams in the field. I was just about to draft a blog entry, outlining the various integration options provided by SharePoint, when a few people pointed out to me that there was already an excellent post by Jose Barreto, who was an Enterprise Systems Architect prior to taking his current role as Technical Evangelist for the Microsoft Storage Partners Team. Although you can find some fairly useful content by doing a search for "sharepoint integration" or visiting our Interoperability Center for MOSS 2007, I like the way that Jose has laid out all of the integration options in a logical and succinct fashion in his blog entry, which he has given me permission to repost in its entirety below.
<Lawrence />
Introduction
Maybe you’re lucky enough to work for a company that has standardized on SharePoint portals and ASP.NET applications across the board. In that case, you do not need to integrate different types of portals and web applications. For most large corporations, though, there will be many portals and different technologies behind those portals. I am currently working with one of those large enterprises that use non-Microsoft portals (from Linux/Apache/PHP sites all to the way to WebSphere) that need to integrate with Microsoft Office SharePoint Server (MOSS) 2007.
The question on how to integrate those with SharePoint is asked quite often. Sometimes there is a need to leverage content stored in SharePoint sites. In some cases SharePoint must consume data hosted in the other portals. There are many options to integrate SharePoint in those cases, so I compiled a list of different technologies you can leverage. Please note that I do not include in the list any of the WSS/MOSS SDK facilities to integrate with other ASP.NET applications, focusing on options applicable when working with a portal not hosted in a Microsoft-centric environment. I included ideas on how to integrate by producing and consuming links, e-mails, RSS feeds, IFrames, WSRP portlets, Web Services and Search.
1. Links
One simple way to integrate two web applications is simply providing links from one to the other. If you maintain a similar User Interface in both, users might not even notice the transitions.
1a. Links – Producer
SharePoint is fundamentally an ASP.NET application and you can link to any WSS or MOSS site, list, library or item directly. There are also ways to link directly to specific views or actions associated with items. It would be possible, for instance, to have a URL pointing directly to the page that adds an item to a list.
1b. Links – Consumer
SharePoint also provides rich support for hosting external links. You can use the built-in navigation facilities to link to items hosted outside MOSS. For instance, you can add a top navigation link or a quick launch link directly to a URL outside MOSS. You also have the choice to open the link in a new window or not. You also have a specific list type to store links and you can add external sites in other areas like the Site Directory. There are also many other out-of-the-box web parts where you can link to something living outside SharePoint.
Reference: How to customize navigation: http://office.microsoft.com/en-us/sharepointtechnology/HA101191001033.aspx
2. E-mail
E-mail via the SMTP protocol is something that we have used reliably for a long time. You can get data in and out of SharePoint using it and you’ll likely find some level of support in many other portals.
2a. E-mail – Producer
You can get e-mail alerts from any SharePoint list and it should not be hard to use that information to populate information in another portal. You can also associate a custom workflow to any list to send an e-mail to an external address every time a list item is added or updated, with the ability to format the body of the e-mail with properties of the item. Although those alerts and workflow-generated e-mails are typically sent to humans, they could be useful in an integration scenario, especially if your target can parse the mail message to isolate the individual properties.
2b. E-mail – Consumer
You can configure any SharePoint list to be mail-enabled. With that, you can send e-mails directly to a SharePoint discussion list, add a blog entry or post a document attached to a message to a document library. A workflow or event handler could be use to further process items received that way to perform specific actions as these items are added.
Reference: How to add content to sites using e-mails: http://office.microsoft.com/en-us/sharepointtechnology/HA100867301033.aspx
3. RSS
RSS stands for Really Simple Syndication and it’s a simple format to describe digital content. RSS is increasingly used on the Internet to provide information about frequently updated information like news feeds and blog posts.
3a. RSS – Producer
You can enable any SharePoint list (including document libraries, calendars, task lists, blogs and wiki libraries) to provide an RSS feed. You have options to select which columns are provided in the feed (like title, date and author) and you can set a limit for the number of items and how old the items can be. Each RSS feed for a specific list has a URL and it comes to the client as an XML document.
References: How to manage RSS feeds: http://office.microsoft.com/en-us/sharepointtechnology/HA100214251033.aspx
3b. RSS – Consumer
SharePoint provides an out-of-the-box web part called “RSS Viewer”, which allows you to place an RSS feed in any WSS page. You have a number of configuration options including obviously the URL where the feed comes from, how many items should be displayed and multiple options on how each one is shown.
4. IFrame
IFrames are HTML elements that let you display an HTML page inside another one. Most modern browsers will let you place this <iframe> HTML markup within a page, specifying the URL to the other page and the dimensions of the frame, among other options.
Reference: IFrame: http://www.w3.org/TR/html4/present/frames.html
4a. IFrame – Producer
You obviously can include any SharePoint page into a page in another portal using an IFrame. The main issue there is the fact that you will get the MOSS navigation in that IFrame, which typically is not desired. To overcome that, you can create a special MOSS page that hides all those elements and show just the element you want to expose. To accomplish that, you can create a “minimal” master page and a simple layout with a single web part zone.
Reference: How to create a minimal master page: http://msdn2.microsoft.com/en-us/library/aa660698.aspx
4b. IFrame – Consumer
SharePoint provides an out-of-the-box web part called “Page Viewer”, which allows you to display any other page as an IFrame.
5. WSRP
Web Services for Remote Portlets (WSRP) aims to standardize interactions between portals using a special set of markups to make it easy to consume a portion of the overall user portal without having to write unique code.
Reference: WSRP 1.0 specification from OASIS: http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
5a. WSRP – Producer
Microsoft does not provide an out-of-the-box WSRP producer. However, you can leverage a third party solution like NetUnity Software to provide that functionality.
Reference: Blog about WSRP in SharePoint: http://blogs.msdn.com/mikefitz/archive/2006/02/06/525536.aspx
Reference: NetUnity Software web site: http://www.netunitysoftware.com
5b. WSRP – Consumer
SharePoint provides an out-of-the-box web part called “WSRP Consumer Web Part”, which allows you to display a WSRP portlet in a MOSS page.
Reference: How to use the WSRP Consumer Web Part: http://www.wssdemo.com/blog/Lists/Posts/Post.aspx?List=d5813c18%2D934f%2D4fd6%2D9068%2D5cdd59ce56ba&ID=234
6. Web Services
Web Services (as defined by the W3C) are a series of standards to allow computers to communicate using XML messages and SOAP, describing their operations via WSDL. If a system exposes their functionality that way, any client supporting those standards can interact with it.
Reference: http://www.w3.org/2002/ws
6a. Web Services – Producer
SharePoint exposes a lot of its functionality using Web Services over HTTP. This can be used, for instance, to get a list of libraries on a site, to add an item to a list, to get information about users, etc. SharePoint web services are implemented using the .NET Framework and they use SOAP, XML and HTTP, also providing a WSDL. The SharePoint SDK includes a complete reference of all the web services available and the list includes: Administration, Alerts, Authentication, Copy, Document Workspace, Forms, Imaging, List Data Retrieval, Lists, Meetings, People, Permissions, SharePoint Directory Management, Site Data, Sites, Search, Users and Groups, Versions, Views, Web Part Pages, and Webs.
Reference: List of Web Services in WSS/MOSS: http://msdn2.microsoft.com/en-us/library/ms445760.aspx
6b. Web Services – Consumer
SharePoint can leverage web services exposed by other applications using the Business Data Catalog (BDC). This is done using an XML-based definition of what is exposed by that application and usually involves describing entities, properties and actions that are exposed by that application. Once the BDC definition is in place, you can expose those via the BDC-related web parts. You can also integrate the BDC data as a content source for Search. Another option is to write a custom web part that consumes the external web service and provides a user interface to interact with it.
Reference: Business Data Catalog Overview: http://msdn2.microsoft.com/en-us/library/ms551230.aspx
P.S.: Also, as suggested by Ian Morrish, the Data Form Web Part (known as Data View Web Part in the previous version) can render Web Services and XML using XSL. For details around this, check http://www.sharepointblogs.com/ssa/archive/2007/02/24/showing-web-service-data-in-a-data-view-web-part.aspx
7. Search
Search is usually a main component of a portal. When two portals are interacting, they will typically need to search or be searched by each other.
7a. Search – Producer
SharePoint exposes all its data via HTTP and you can configure any search engine to crawl it. The search engine would start with a site directory and for each site it will use the “View All Site Content” link on the quick launch to discover all lists and libraries on the site. SharePoint also has a crawl web service that could be leveraged to enumerate all site collections even if you don’t have a site directory.
Reference: How the MOSS crawl works: http://blogs.technet.com/josebda/archive/2007/03/19/crawling-sharepoint-sites-using-the-sps3-protocol-handler.aspx
7b. Search – Consumer
SharePoint can index several types of content sources beyond SharePoint sites. That includes any HTTP-based web site, file shares using SMB and anything you are consuming via the BDC. You basically need to define a content source in the Search SSP to describe how and when your crawl should run. You can also develop your own protocol handler to address custom scenarios.
Reference: How SharePoint crawls content: http://technet2.microsoft.com/Office/en-us/library/f32cb02e-e396-46c5-a65a-e1b045152b6b1033.mspx
8. WebDav
Although not really an integration technology, WebDAV provides a way to download and upload files hosted in SharePoint. This is what clients leverage for the explorer view and there are many clients that can interact that way.
9. AJAX
AJAX is not a specific technology but a set of technologies, mostly related to using client-side javascript to asynchronously do post backs and partial page refreshes. If you are using AJAX, you can leverage some of the other technologies mentioned here to interact with SharePoint. There is no out-of-the-box web part to host AJAX code, but there’s already many discussions detailing how to support this scenario and leverage it inside a web part.
Reference: Information about ASP.NET-based AJAX: http://ajax.asp.net
Reference: Building a web part that uses AJAX: http://www.capdes.com/2007/02/microsoft_office_sharepoint_se.html
Reference: Building a web part that uses AJAX: http://sharethispoint.com/archive/2007/02/28/Using-a-SPGridView-inside-an-ASP.net-Ajax-UpdatePanel.aspx
Conclusion
I hope that helps you sort out the multiple different integration points and will allow you to choose the best technology for your specific case. There are certainly a lot of details to account for, like whether you are planning to write custom code to help with the integration (and if you are, on what side you will be hosting that code) and how the authentication between the two systems will work (Kerberos is your friend and so is MOSS 2007 SSO).
I find the RSS feeds option quite interesting, since it is easy to implement, provides much more functionality than simple links, allows for some level of customization and could even work well with an AJAX-type solution. If you can get away with that one, you will certainly have a lot less to worry about.
