By the end of the year, SAP plans to release Duet Enterprise, a product that will enable users to view information...
from the SAP back end in the SharePoint interface. In this column, Excellis Interactive’s Pete Lagana details his advice for deciding whether to keep NetWeaver Portal over SharePoint and for enabling SharePoint/SAP integration now.
Recently, my team discussed integrating SAP NetWeaver Portal and SharePoint with the management team of a large pharmaceutical company. We hit all of the familiar topics: risks, skill sets, licenses, what’s possible and what’s not?
As I listened to the dialogue, I realized that we’ve had so many of these conversations that I’ve lost count. A typical discussion goes something like this:
“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, 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 NetWeaver Portal/Microsoft SharePoint integration question is probably one of the top three questions that IT executives ask when it comes to creating online tools for their companies that own both technologies, or are considering investing in one or the other.
Here are five key considerations I take into account when working with clients that have both technologies:
1. User experience
Most engagements with our clients that involve user experience for SAP/SharePoint integration boil down to two things: aesthetics and functionality.
Aesthetics concerns things like Theme Editor in SAP and SharePoint Designer in SharePoint. When we talk about functionality, it is a discussion around iViews for SAP versus Web Parts for SharePoint.
Theme Editor and SharePoint Designer
Web Dynpro, BSPs, portal frameworks, out-of-the-box applications -- these are all SAP products that are dependent to some degree on the Theme Editor to make them look good. The way SAP handles its maze of style sheets tends to be complicated. Several dozen style sheets are used to drive the look and feel of any one element or page in any of these products. With SharePoint Designer, that process generally is more manageable. If you are used to WYSIWYGs, SharePoint 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 UIs and can dictate to SharePoint’s’ UI products such as info path forms, aspx pages and more.
iViews and WebParts
When you talk about UX functionality for SharePoint and SAP NetWeaver Portal, you are really talking about iViews for SAP and SharePoint Web Parts. These are the foundational building blocks for each portal, which is important because it’s both the functionality that people use and it’s what users see. Once communication and connections between 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.
In a familiar scenario, SAP Portal is 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 our team has worked with have SharePoint set up as their enterprise portal, with SAP content and functionality pumped in as Web parts. In such cases, you’ll likely see SharePoint intranets that offer up HR functionality and, say, SAP HR business package content and iViews to supplement the SharePoint intranet with SAP-specific HR transactional data.
2. Connection and communication
When 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 Business Data Catalog (BDC) connector to SAP that, up until 2010, only offered read functionality. From a custom code perspective, it doesn’t have to be complicated. Typical connection logic, setting up the 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 open to bring SAP into the SharePoint display.
3. Content and collaboration
Apart from application code, when you integrate SharePoint and SAP, you also have to think about structures like databases, repositories and metadata. Many companies that own SAP already own the NetWeaver stack, including NetWeaver Portal, and knowledge management and collaboration (KMC) components.
Companies that have SharePoint are most likely are using it for collaboration and document storage. NetWeaver KMC is a great product with many open APIs to store documents, and it works nicely inside the portal with TrEX. SharePoint has great collaboration tools as part of its native interface and is easy to set up and run 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, a topic that 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. SharePoint also does a good job. The constraint is whether you can manage content that resides in one portal from the other.
4. Single sign-on
Probably the simplest and most straightforward integration point between SAP and SharePoint is single sign-on. It really is about authentication and authorization, which is identity management at a higher level.
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 SharePoint. Typically, however, something like Kerberos will be needed to establish SSO robustly.
5. Unified search
Search typically is not identified as a “want” early on, but it becomes a huge “need” downstream. 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. When integrating search between SharePoint and SAP, it always comes down to the indexes and the 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’s perspective. TrEX generally makes it tough to modify search results and select drill-down sub-searches from the results page. It does offer sponsored links or right-hand-side components. SharePoint search offers drillable category searches to further hone down the search based on key tags or topics.
Pete Lagana is an executive digital experience director at Excellis Interactive.. He is responsible for providing creative and technical leadership to a multi-disciplinary team involved in user research, information architecture, visual design, interaction design and development. Pete has more than a decade of interactive design and development experience across multiple channels (desktop, Web, wireless, broadband) and platforms (SAP, Microsoft SharePoint, IBM WebSphere).