NetWeaver Portal and SharePoint Server are both technology platforms with an impressive breadth of capability. With a large overlap in the respective feature sets, they are often considered to be competing products between which companies must make a clear choice. However, for large organisations a dual portal strategy is certainly a viable option, leveraging the best of both worlds.
More than two years ago, SAP and Microsoft released a joint white paper outlining all the different scenarios where SharePoint and NetWeaver can work together from a technical interoperability perspective. But one thing is theory, another thing is what is truly worth doing. Over the last couple of years, I have been speaking to a large number of customers about how SharePoint and NetWeaver can co-exist, so I thought it would be worth sharing what companies are actually doing out there. Below are the two most common scenarios I have encountered where some level of integration between NetWeaver and SharePoint has been implemented.
Publishing SharePoint content to NetWeaver
In this case, the organisation has a significant investment in NetWeaver Portal and it is clearly their portal of choice. However, despite the clear strategic focus on NetWeaver Portal, SharePoint still manages to creep its way into the business. This is typically to facilitate collaboration in cross-functional teams which is an area where SharePoint is very strong. In this regard, the tight integration with the Office desktop applications is quite compelling too. It therefore makes sense to allow the business to collaborate on content in SharePoint workspaces and then have the finalised and approved content published to the corporate-wide intranet based on the NetWeaver Portal.
Technically, this can be achieved through custom developed interfaces or by using a third-party product such as the MOSS Integrator from btexx. Depending on the SharePoint functionality required in this scenario, it is often adequate to be running Windows SharePoint Services (the "free" version of SharePoint which is included in the Windows Server licensing). Also note, that SAP is working on including some SharePoint integration functionality in future versions of NetWeaver Portal which is likely to support this scenario.
Rendering NetWeaver iViews in SharePoint
This scenario is often seen in organisations that have a clear focus on making SharePoint the portal or portals. Typically the business employs a large number of information workers that spend the majority of their day in the Microsoft productivity tools, such a Outlook, Excel and Word. However, the company still wants to take advantage of the many business packages of standard SAP functionality that can be deployed to NetWeaver Portal with little or no development effort required (ESS is a good example of this). With a strategy of making SharePoint the one-stop-shop for the broader user base, it is obvious to explore the path of exposing this functionality through SharePoint.
For power users, this is merely a case of providing simple links on SharePoint than sends them off to the NetWeaver environment which natively delivers the required functionality. For the more casual users, it can be beneficial to bring the functionality to them rather than the other way around. By rendering the SAP iViews within SharePoint, the casual user can access basic SAP functionality without loosing the navigational context of the SharePoint intranet. Note, that this will only work for simple iViews that do not require the context of NetWeaver Portal to work properly. For example, the Universal Worklist (UWL) depends on object-based navigation and will not work outside of the NetWeaver Portal. Also note, that the SAP iView Web Part provided with SharePoint 2007 has issues but Microsoft has released a workaround. In SharePoint 2010 this scenario will be supported through iFrame integration of iViews, BSPs and Web Dynpro applications.