10 December, 2008

Using the SharePoint BDC to access SAP data

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.

4 comments:

Anonymous said...

Hi Kristian,
The podcast #12 you reference isn't available on their site (I've asked them to check the link).

Can you explain a little more about the "required format" the SAP Web Service must follow in order to work with the BDC(Finder, SpecificFinder, IDEnumerator)? I've not seen this information posted anywhere else.

I'm writing a requirements spec to hand off to our SAP developers, and I want to make sure they have everything they need. The BDC will consume the Web Service to pull in user-profile information for use with the SharePoint User Profile Import.
Thanks!

Kristian Kalsing said...

The podcast reference still works fine for me.

In regards to the format of the web services, your best reference is MSDN at http://msdn.microsoft.com/en-au/library/bb861805.aspx

There's also another sample you can walk through at http://msdn.microsoft.com/en-us/library/bb737887.aspx

Although you can author your application definition file directly against standard BAPIs, it's a lot easier if you can get purpose-built ABAP web services providing a similar interface to the web services in the sample above. The standard BAPIs are not very granular and very generic, making them hard to work with.

Anonymous said...

Thank you VERY MUCH for the MSDN references, I now have working BDC connections!

(and the podcast is now working too)

Priyatamil said...

Great and really helpful article! Adding to the conversation, providing more information, or expressing a new point of view...Nice information and updates. Really i like it and everyday am visiting your site..
SAP Training in Chennai | SAP ABAP Training in Chennai