05 July, 2010

SAP/Microsoft interoperability and the composition challenge

The best of both worlds approach is appealing. Leveraging SAP as the transactional backbone and surfacing business data in the Microsoft collaboration and productivity tools that everyone is so familiar with. So why isn't everyone doing it? Because, it is not that straight forward. There is one particular challenge that always needs to be addressed and here I will explain what the fundamental problem is.

When SAP opened up for a more service-oriented approach, they basically just took the lid off the box exposing a rather complicated mess of wires, called RFCs and BAPIs. You can achieve almost anything connecting to these wires but it takes a specialised SAP professional to do so. To overcome this challenge, these wires need to be combined into understandable and reusable sockets which outsiders, such as .NET developers or increasingly business users with the right tools, can easily plug in to.

In other words, connecting directly to RFCs and BAPIs will not get you far if you require anything but the simplest of read-only integration. So, has SAP overcomplicated it by making the API so granular? Not really. Because SAP is one large generic product built to work in pretty much any conceivable industry, it has to be this way. At least when considering the core product.

We have all heard users expressing their frustration with the standard SAP GUI. A lot of that frustration is a consequence of a generic user interface that is not targeted at that particular user's role or industry. It is exactly this same frustration developers experience when connecting directly to the SAP services. The issues users are having with the SAP GUI are reflected in the integration layer when developers are facing the underlying API. Granularity is the culprit in both instances.

There are many tools and technologies which can be employed in the services tier or even to help with point-to-point integration. However, regardless of whether you are using SAP Enterprise Services, SAP Connector for .NET, SAP PI, Microsoft BizTalk, your own custom interoperability components or any combination of the above, you will still encounter the same challenge: Composing easy consumable services from the granular SAP API.

The good news is that this is a problem that can be solved. And it can be solved elegantly. The less positive news, however, is that the reality dictates a wide range of solutions depending on many factors that are specific to your requirements, circumstances and environment. But hopefully this post has helped you focus on where you need to concentrate your effort, particularly when you design your architecture or evaluate various third-party tools and technologies. Always ask the question, "how is this going to make service composition easier?"

Thanks for reading and please do share your thoughts below. Many people out there are eager to hear your professional view on this.

6 comments:

Shaun Oosthuizen said...

Hi Kristian,

Thanks for an interesting article.

I agree that hooking into SAP is not as simple as consuming the standard web services (ESR Content) that SAP ships. I also agree that the problem here is that different businesses have their own unique requirements and ways of doing things. To cater for this most of the clients I worked with wrap the standard SAP API functions (BAPIs) in a custom built function module which then in turn gets exposed as a web service directly or even easier - it gets called in an ABAP proxy by SAP PI.

Again, I think it is important to stress that the technology is not the problem. There is however, in most cases, always going to be a requirement for both technical and functional SAP resources to tweak the exposing of these granular business functions to exactly suite the customer's needs. I don’t see this as a show stopper though. One must remember that most big companies that own these multi-million dollar SAP systems already have the resources available, either as permanent staff or contractually.

The deciding factor would be whether the time, effort and cost spent on a project like this would weigh up against the benefit. It may be at this point where many decide to ditch the effort involved and go with one of the ever improving UIs offered by SAP.

Cheers,
Shaun

Kristian Kalsing said...

Thanks for your comment, Shaun. You hit the nail on the head when saying that the technology is not the problem. In the vast majority of SAP customers I have been involved with, there are organisational and political barriers to overcome. I've got a white paper in the pipe on this topic. Stay tuned.

Shaun Oosthuizen said...

Looking forward to it (:

Pim said...

Hi Kristian,

totally agree with your post to put thing is perspective and focus on business case relevant instead of technical possible. I'm currently engaging with two multinationals who are standardized on both SAP and MS to define a interoperability study focusing on building guidelines based on governance and TCO instead of technology. Since both are also rampup customer DUET enterprise these guidelines are crucial element to successfully bridge the two worlds. Would love to share experiences here. cheers Pim

Kristian Kalsing said...

Pim, shoot me an email on kristian at kalsing dot com

Leena Roy said...

your work is wonderfull please check my post:)


sap services & sap fiori partner & sap for small business