SAP and Sharepoint: Coincidence or Collision?
November 7, 2011
I was talking about integrating SAP and SharePoint with the management team of a large pharma company last week – discussing all the familiar topics such as risks, skill sets, licenses, what’s possible, what’s not, “can we get it to look this way?” and “what do our users want?”. As I listened to all the dialogue, I realized that A – we have been in so many of these conversations that we’ve lost count, and that B, it’s time to share some of the dialogue occurring around this topic.
We always hear a lot of comments like:
My company has a SharePoint intranet and we’ve turned it on across the enterprise. We use it to store our documents and we have some intranet websites also built on the SharePoint platform. We also own SAP, and run the SAP Netweaver Portal to get to some of our SAP data and functionality. It seems that everything leads back to SAP at some point in time, so most of our applications are built in Web Dynpro, but we also like the flexibility and user experience offered through SharePoint. Should we have both? Should we just use one? How do we make the right decision?
The SAP / SharePoint integration question is probably one of the top 3 questions that IT executives ask when it comes to creating online solutions for their companies who own both technologies, or those who are considering making an investment in one or the other.
We’ve put together some important things to think about if you or your company is trying to decide if your investments in SAP and SharePoint will coincide or collide.
INTEGRATION – THINGS TO THINK ABOUT
For starters, let’s talk about integration. Pure and simply read “what are the things I need to consider to make SAP and SharePoint play nicely. ”
Here’s a list of five key things that we consider when working with clients that have both SAP and SharePoint:
Probably the most important thing to think about with an SAP / SharePoint co-existence strategy is the user experience. This particular topic, like all the others in this list, deserves a deeper dive. But, here though, we’ll cover the high level points.
Most engagements with our clients that involve user experience for SAP / SharePoint integration boils down to two things: Aesthetics and Functionality.
Aesthetics really is a discussion around things like Theme Editor in SAP and SharePoint Designer in SharePoint. When we talk about functionality, it is a discussion around iViews and WebParts, iViews for SAP and WebParts for SharePoint.
Theme Editor vs. SP Designer
Web Dynpro, BSPs, Portal Framework, Out of the box Apps, Business Packages – these are all SAP products that are dependent to some degree on the Theme Editor to make them look good. The problem is easy to understand, but often complex to fix. The way that SAP handles its maze of style sheets tends to be complicated, with several dozen style sheets being utilized to drive the look and feel of any one element or page in any of these products. We’ve spent many a client engagement perfecting the art of SAP style sheets for its software, and we have the battle scars to show it. The good news is with the know-how, the look and feel of SAP can be absolutely awesome. So we can get to the place we need to be, it just might be more like taking a flight from Philly to NYC with a layover in LA.
With SP Designer, the process can also get complicated really quickly, but generally is more manageable. If you are used to WYSIWYGs like Dreamweaver, SP Designer does the trick. Here you start with the concept of a master page, that if kept clean from the get go, can produce more manageable UI’s, that can dictate to SharePoint’s’ UI products like info path forms, aspx pages and more.
In the end, either platform can produce great User Interfaces, it’s generally though the right experience in doing this specific work which is the secret sauce to making it happen.
iViews and WebParts
When you talk about UX functionality for SharePoint and SAP, you are really talking about iViews and WebParts. These are the foundational building blocks for each portal – iViews for SAP, and WebParts for SharePoint. This is important because this is both the functionality that people use, and it’s also what users see. Once communication and connections between the SAP and SharePoint have been established the building blocks can be interchanged to help build applications. Some clients run the SAP portal as their primary enterprise portal, and then pump in .NET iViews as content or application functionality into the SAP Portal interface. Scenarios here may be where SAP Portal is being used as a strong transactional portal with some static content, and .NET apps are needed to supplement the SAP or NON-SAP transactions, into the SAP Portal. Other clients we’ve worked with have SharePoint set up as their enterprise portal, with SAP content and functionality being pumped in as web parts. Scenarios you may see here are for instance SharePoint intranets that offer up HR functionality, and say SAP HR business package content and iViews are needed to supplement the SharePoint intranet with SAP Specific HR transactional data.
Connection and Communication
When considering bringing these two worlds together, success often depends on any or all of the following: implementing pre-built connectors, using applications like Duet, or writing custom code. Here we are really talking about APIs, Web Services, and/or SOA. There are more SharePoint to SAP connectors popping up these days, and more will come as we move along, but to get it truly right, custom code is king. SharePoint does offer a standard BDC (Business Data Catalogue) connector to SAP, that up until 2010, only really offered read functionality. From a custom code perspective, it doesn’t have to be complicated. Typical connection logic, setting up ability to read and write data back and forth from SAP into SharePoint, and closing those connections are typically the core of the work. Once these core pieces are set up, the door is now opened to bring SAP into the SharePoint display.
Content and Collaboration
Apart from application code, when you integrate SharePoint and SAP, you also have to think about structures like dbs, repositories and meta data. Many companies that own SAP already own the Netweaver stack, and already own NetWeaver portal and KMC (knowledge management and collaboration). But for companies that also have SharePoint, they most likely are using SP for collaboration and document storage. Netweaver KMC is a great product with many open APIs to store documents, and works nicely inside the portal with TrEX as well. SharePoint has great collaboration tools as part of its native SharePoint interface, and is easy to set up and have running quickly. The trick is allowing SharePoint meta and repositories to be open and exposed to each other, so that in KMC, SharePoint collaboration repositories and meta can be viewed, and in SharePoint, KMC meta and repositories can be read.
Also, what comes up a lot in consulting with clients on SAP / SharePoint integration, is the content management / authoring concept. SAP Netweaver Portal does a good job with authoring and is very robust, specifically with Web Page Composer. SP also does a good job. The constraint is can you manage content that resides in one portal from the other?
Single Sign On
This is probably the simplest and most straightforward integration point between SAP and SharePoint. This may also be one of the most important because SSO is really more than just users not having to sign in again once the app jumps domains to the other. It really is about authentication and authorization, which really is about Identity Management at a higher level. The IDM topic is broad and deep, and not really the focus of this write-up, so more on that in another post. From an SSO standpoint though, SAP has done wonders with the SAP Logon Tickets it uses with its portal product, and to some extent this can be used to integrate with MS SharePoint. Typically though, something like Kerberos will ultimately need to be used to establish SSO robustly.
Working with clients who own both MS and SAP products like Netweaver and SharePoint always brings up hot topics. Sometimes those topics are clearly stated as wants in the beginning of an engagement, sometimes not. Search typically is not identified as a “want” early on, but becomes a huge “need” that appears downstream. Why, because besides the user experience, search is the next most visible and utilized touch point to end -users. Getting search right is often a make or break scenario. With integrating search between SharePoint and SAP, it always comes down to the indexes, and ability to crawl from either side. TrEX tends to be more closed, often not exposing its meta or repositories outside the NetWeaver walls. SharePoint search, especially in 2010, does a good job of allowing other engines to access it, but it also offers up its own repositories more easily. Also, search results carry a lot of weight from an end user importance perspective. TrEX generally makes it tough to modify search results, and select drill-down sub searches from the results page. It does offer the concept of sponsored links or right-hand side components. SharePoint search offers drillable category searches, to further hone the search down based on key tags or topics. Search is another deep topic worth its own post, which we will dig into later.
Final Thoughts (for now)
So given the backdrop of what to think about when integrating these two technologies, some of this might hit home for your scenario. Trust, me, you are not alone. SharePoint is the fastest growing Microsoft Product of all-time, and they’ve gone to great lengths to extend its enterprise benefits and use cases. SAP is certainly the software that runs the business of many of the biggest and best companies out there. So this really is a situation where two worlds can collide, but it doesn’t have to be that way. We’ve found that they both have their pros and cons, and if you can learn the nuances of the points above, it makes for a great co-existence strategy, or at the very least, the business case for one.