I was listening to the SharePoint Pod Show Episode 12 about the SharePoint BDC. It’s a great discussion which gives you an excellent introduction to the BDC, but it also includes some valuable insight into some of the more advanced things you can do and at the end they share common issues that people out there are encountering. Very interesting.
The podcast also references a survey about the proliferation of the BDC. It caught my attention that not many are actually using the BDC for connecting to SAP. I presume, this is first of all because the majority of companies running SAP is typically committed to SAP Enterprise Portal more than MOSS. A second reason is the relative complexity of it which I will elaborate on in this post.
As I indicated in a previous post, even in very SAP-centric organisations the proliferation of SharePoint is inevitable. This is usually driven by people in the business asking IT to provide SharePoint’s collaboration functionality. SharePoint is also a front-end for an increasing number of Microsoft's other server products (Project Server, PerformancePoint Server, Team Foundation Server, etc.), so it tends to emerge one way or another.
If you run SAP as your back-end and you have SharePoint widely deployed, it’s a natural progression to consider bringing SAP data into SharePoint using the BDC. The main driver for this is to increase productivity of casual users by allowing easy access to SAP data in an environment they are comfortable in and thereby minimise their reliance SAP power users.
So, if you do want to use the BDC for bringing SAP data into SharePoint, what are the challenges you’ll be facing? Well, here are a few based on my experiences:
- Developing BDC-friendly web services.
As mentioned in the podcast above, the BDC requires the web services representing your LOB system to be structured in a certain way. Unfortunately, that certain way is not anywhere close to what the SAP web services look like in a standard SAP environment. They return results through inout parameters rather than out parameters and there’s a separate WSDL for each method whereas the BDC requires all methods for all entities in a LOB system to be accessible from the same URL.
If you’re coming from a .NET background, it is tempting to address this by developing your own custom .NET web services layer on top of the SAP web services. Although this can be useful in order to create a quick and dirty conceptual proof-of-concept, it’s not something that’s recommended in a production scenario. You obviously end up with poor performance having the data serialised and deserialised twice and you will face serious challenges getting the users authenticated all the way through.
The right thing to do is developing custom ABAP web services on the SAP side, designed specifically for the BDC. Give the ABAP developer the guidance required to develop web methods that are fit for purpose (Finder, Specific Finder, Id Enumerator, etc.). Also, it’s preferable to have the ABAP developer extract field names from the SAP system saving you from having to do any manual mapping of names in the BDC application definition file.
- Finding the right skill sets.
As with any solution that spans across multiple technology stacks you will need to find and coordinate people with different skill sets. You will need a good ABAP developer to build the web services on the SAP side and that developer will need to work closely with a SharePoint technical resource that knows the BDC well. And they will have to put aside any religious technology arguments for another day and subscribe to the idea of leveraging the best of both worlds.
- Getting security right.
When you talk to organisations about bringing SAP data to a broader user base, concern number one is always security. Configuring authorisation hierarchies in SAP is often an expensive exercise and a lot of time and effort has gone into it. You want to leverage that investment. In reality that means you’ll have to get Single Sign-On working, so the users are authenticating through and access levels are managed in SAP.
There are a couple of ways you can go about that. You can either architect your infrastructure to implement SSO (refer to the white paper Unleash the Power of Single Sign-On with Microsoft and SAP) or you can take advantage of SharePoint’s SSO service (guidelines available in the white paper Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Technologies).
- Focusing on the right use cases.
SharePoint is a great environment for deploying functionality to casual users of other applications. That includes access to SAP data. But you’re not trying to pull SAP power users away from the SAP GUI. You’re aiming at occasional users of SAP. Users that only sporadically need to look up some information in SAP. It’s great for scenarios where users are currently having to go through SAP power users to acquire the information they need. And it’s typically to support collaboration-oriented activities rather than transaction-oriented activities.