Being an interactive shop, we always are looking to produce the best user experience possible for our clients. And because we do a lot of SAP projects, it's inevitable that those customers also run some version of the SAP Netweaver Portal.
What has been increasingly evident over the last year, is that most of those same clients ALSO run some manner of Microsoft SharePoint. Some companies will use SharePoint extensively, while others barely use it even for document management. So, this is typically the backdrop of conversations that start out something like this: " We have the SAP NetWeaver Portal - but we also have Microsoft SharePoint Portal. Which one should we use, should they be standalone, or merged?".
That question seems to always come up for clients who have both SAP and SharePoint. And it's not slowing down.
The answer to that question really can get quite complicated, and can go in many different directions. For now, though, I thought it would be helpful to list the things that we talk about with clients when consulting on SAP / SharePoint integration:
1. User Experience. From a UX perspective, the SAP up a few ways to deliver UIs through SAP Netweaver Portal - all the familiar names such as BSPs, WebDynpros, JSPDynPages, etc. These are controlled through a massive array of style sheets, and can be accessed directly from the server or via the Theme Editor. With SharePoint, styles are controlled through SharePoint Designer. So if you are familiar with your typical WYSIWYGs, then you will be in good shape. Be sure to start out with a clean masterpage, though, or it could get messy.
Advantage? SharePoint. Because SPX (SharePoint Designer) allows you to adjust the master page layout which controls all of their UIs (ASPX pages, InfoPath forms), you can start with minimal css layouts, and keep it clean. For the Netweaver Portal, there is a lot of style sheets there to sort through, and going through the theme editor is much more limiting than SPX. You can produce great user experiences in both NW Portal, and SharePoint, but experience and know-how are generally the secret sauce to make it look great.
2. Connection and Communication. This really boils down to which platform is easier to integrate to, in other words - which is more open. Connection and communication could come in the form of pre-built connectors, using applications like Duet, or writing custom code. Here we are really talking about APIs, Web Services, and/or SOA. Having done a bunch of projects for both NW Portal and SP Portal, its usually custom code that best enables integration. Also worth mentioning here is connection and communication via the Federated Portal Network. FPN provides a way for SP Portal and NW Portal to recognize and trust each other. Throug set up and system configuration, FPN does present an alternative to APIs, Web Services and SOA. We've set up a few FPNs at clients with this hybrid scenario, and it has worked well, especially in situations where iViews need to be surfaced in SP Portal, or WebParts need to be surfaced in NW Portal. FPN provides soem interoperability in these cases.
Advantage? Even. Both are about the same to integrate to. Just different code, different syntax, different configurations.
3. Content and Collaboration. SAP does a good joob with the KMC product, and we've built some great solutions utilizing the KM API's (http://www.pfizerpro.com/products). Can be pretty light and fast. But document management and collaboration within the sharepoint platform is probably more robust. The ability to administrate freely, the lightness of the layout, and the ability to scale horizontally make it easy to work with.
Advantage? SharePoint Given the extensibiity of the collaboration tools, and the horizontal scalability.
4. Single Sign On. SAP Logon tickets rule. Let me just say that right now. I can't tell you how many times we've integrated SSO to an SAP portal, and most of the solution has come from manipulating the logon tickets. With SharePoint, there are some close equivalents, but you'll generally need Kerberos to integrate fully. Here again, FPN, once set up correctly, can allow simple sign-sign between systems, once trust has been established.
Advantage? SAP. Logon tickets push the advantage SAP's way.
5. Unified Search. Search is an important factor with both platforms. SAP Portal touts the TrEX search engine, and integrates to SAP Enterprise Search. MS SharePoint has its own unified search, that also allows drill down by meta and quick sub searches.
Advantage? SharePoint. Reason - open APIs for the indexes and repositories, and easy manipulation of the search results layout.
Final Thoughts for now - both platforms have their advantages and disadvantages. SharePoint tends to be the UI Portal that sits on top for most clients we've seen, and SAP content is pumped in as iViews. However, we've implemented it the other way around too, and that's been pretty successful as well. I think the ramp-up of Gateway will help influence this topic significantly over the next year, and I'll be writing about that in another post. But for now, SAP Netweaver and Microsoft SharePoint are two major factors in the enterprise ux market. I tend to think, based on experience, that they can most certainly co-exist quite nicely. The business case is certainly there for that.
