Skip to Content
Author's profile photo Martin Fischer

Back from SAP TechEd: Back on the dark side?!

After enjoying SAP TechEd in Barcelona last week, I’m back in reality now. I really enjoyed TechEd. I would call myself some kind of a geek and I really like to get insides on new stuff which appears on the horizon even if it might be years ahead of my daily business or if it might never become my daily business. I have to emphasize that I really like to see that SAP continues to go the way they started to go with HANA years ago. Since I’m working in the SAP Eco System (that’s almost 15 years by now) that’s the first time that they follow the same strategy for such a long time. The technologies and products seem to become more mature and stable. Of course, there is often place for improvement but in general I like what I see. Especially the fact that SAP gets more and more open as you can see in several areas: openSAP, contribution in standardization (e.g. OData) and contribution to open source software … That’s definitely a big move and I really like that!

But now I’m coming to the point why I’m writing this blog post. I’m back at work, back in my daily business and somehow I want to call it back on the dark side. The story is about the experience I made with a specific BAPI and the SAP support.

Before I start to tell my story, some general remarks on the BAPI concept:

I regard the concept of having BAPIs very good. At the time when it was introduced it was a really innovative idea to have encapsulated business logic which you can call from another system. But one issue I have with many of the existing BAPIs is the way they are designed. In many cases there is only one BAPI which is supposed to do all the changes on a business object. This “one fits all approach” makes it almost impossible to define all the test cases you should have in place to test the whole functionality, which leads to an open door for side effects. Furthermore, the signatures of some BAPIs consist of more than 20 tables and structures. There are fields in this signatures which should never be filled, but you can fill them. As BAPIs are also an interface to the non-SAP world, the way they are designed led to the reputation of SAP being complicated and not easy to understand among .net , Java developers and any others who had to use them. In my opinion, the fact that they are that complex is also the reason SAP does not dare to re-write them (they got wrapped within the SOAP services and now they are often wrapped as an OData service, I’m wondering what will happen with S4HANA). But still, I’m very happy that they exist and as I said, at the time when they got introduced they were state of the art.

Now I want to tell a true story about the last almost 18 months and the “fun” I had with SAP support. To make it clear: I don’t want to blame anybody personally. I assume all the people involved do their job in the way they are told to do it.

The story is about a BAPI which exists since 2005. It’s in the area of material master data. A quick search on Service Marketplace reveals that SAP released more than 50 SAP Notes within those 18 months. I’m not that proud about the fact, the at least five got created after one of our tickets which already sum up to nine by now. Already this facts shows that this BAPI kept me quite busy. We are using this BAPI for a master data interface which is quite critical to our application. So all this issues got even management attention. Each developer knows that it doesn’t make problem solving easier when management guys attempt to solve your software issues 🙂

Ok, one could say, if SAP released more than 50 SAP Notes, they realized the quality issues and installed some quality management processes. I don’t know if they did, but at least I don’t think so.  After the first tickets we created and after having endless discussions with SAP Support about declaring it as a bug or not, we ended up in debugging the SAP code and pointing them to the place where we identified the bug. Even in that cases it took weeks to get a fix. Now, we do a deep dive into the SAP coding before we open a ticket. This is a painful work but not as painful as those discussions. But even if we tell them, “look here, this must be a bug” they sometimes just ignored our hints for weeks. Finally, in the SAP Note they ship, they changed surprisingly the mentioned part of code.

One of my colleagues already suggested we should just go and re-implement that BAPI on our own. I’m still convinced that this would be the completely wrong solution (always use SAP function modules to change data in SAP tables, there are very good reasons for doing so!). But looking to the effort we invested, it would have been possible to develop a BAPI for our needs.

SAP gets good money for the support from their customers. Their customers need a good support because they run very often mission critical systems for their business. But as a customer you should really worry if the support teams of your software supplier acts as we experienced it:

  • All our tickets which made it to the development support were processed by the same person. I don’t know exact numbers of SAP customers which use SAP MM but it must be thousands for sure. It’s clear that this person must be more than busy!
  • You as a customer need skilled ABAP developers even if you are only using SAP with the code SAP shipped (I would be surprised if there is any customer without any custom code on a SAP system) because otherwise you will end up spending years in convincing SAP Support that you found a bug
  • After agreeing on having a bug it takes up to ten weeks to get a fix even if you tell them that you will have a go-live in between
  • SAP Support is asking you providing simple test cases on your system to test the fix because they are not able to produce a similar test case on their system
  • Not to mention the annoying game “I just ask another stupid question to the customer. I already know it makes no sense at all. But it will improve my KPIs when I change the status as fast as possible.”
  • SAP Support doesn’t answer question why they do not respect their own architecture and coding guidelines
  • Even if you got a ticket with priority “very high” you do not get 24/7 support because there is only one development team taking care for your issue

For me it looks like, that the existing ERP Suite, which is running at the vast majority of the customer’s systems became just legacy. There are support teams responsible for coding which is almost not commented and if commented, in a language they do not speak. I can only guess about the documentation they have.

All this experience really worries me!

Are all my experiences just an individual case or did you make similar experience?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Christian Drumm
      Christian Drumm

      Hi Martin,

      nice blog! There are quite a few interesting topic mentioned in it; BAPIs, software quality, support. I'll try to summarize some of my experience in this areas. First, however, I like the title. Back to the dark side. It's a feeling I almost have daily. There is all the new stuff I read about on SCN, Twitter etc. And than there are the projects we are currently implementing....

      Anyway. Regarding the BAPIs. I agree that having a stable API to the SAP modules is in general a very good idea. However, BAPIs never achieved this goal. The ones I know of are nearly wrappers around existing "one size fits all" function modules. Also wrapping them into a SOAP interface doesn't make this any better. For most use cases the BAPIs are simply not usable Due to their "one size fits all" approach. I had the implression that SAP understood these problems and wasn't going to repeat them with the new OData services. However, if BAPIs are now wrapped into OData services I'm not to sure about this anymore. I really hope that there will be a focus on external APIs in the future. IMHO these are important design and software artifacts which should be taken serious. Not simple wrappers around some internal function modules.

      In some aras of the business suite I had rally bad experiences with respect to software quality. Probably the worst part was the SEPA functionality. When we implemente SEPA two years ago there were about 10 notes each week. In summary I guess there were several hundred notes in total. For a functionality that consisted of 2-3 packages, a few tables as well as the integration into existing modules and some APIs. For me it seemed that this whole part was basi untested. If I think about ransons for this I allways come up with two  possibilities. When I'm in a positive mood I think that large parts of the business suite is quit old and basically not suitable for automatic tests (therefore we get the test seams in 7.50). Therefore, the functionality migth have only been tested (very roughly) manually. When I'm in a bad mood I think that for certain aras wher there are no more opportunities for SAP to sell license simply nobody cares.

      Finally support. I had both extrems. Very slow and bad quality responses as well as immediate great support. During a recent go live we had a problem during the initial load of a CRM system where the support reacted on a Saturday evening at 6pm within 45 minutes, analised the problem, handed it over to an other time zone and came back with a solution on Sunday morning. I was really impressed by this performance back then.  And this was no very large project with special attention or something like that.

      What I usually do when I debug an issues to the very code line, sometimes even with the suggested fix, and the support is taking to long is to implement the fix using implicit enhancements. This enables us to proceed with a project or a test without the need to wait for a fix. Once the fix is released by SAP I remove the implicit enhancement, implement the note and everything is fine. If SAP support needs to test in the enhanced system it's very easy to temporarily disable the enhancement and go back to the standard implementation.


      Author's profile photo Martin Fischer
      Martin Fischer
      Blog Post Author

      Hi Christian,

      I fully agree with you about the BAPIs. Just wrapping the BAPIs and exposing them as SOAP WebServices is one reason why, in my opinion, the SAP SOA story failed.

      But I still believe, that SAP will not re-implement all the business logic for S4. The reason for that: they can't! It's too complex, lacking architecture and I guess they are also missing documentation on some parts. I base my assumptions one the experience I made with SAP Support this year. I didn't have the feeling that they exactly know what happens inside the code they are maintaining.

      Regarding testing by SAP: I have the same impression. Often the testing is done on customer's site. About the "nobody cares" areas: I fully agree and have the same impression.

      I also do implicit enhancements to fix bug from time to time. That's the pragmatic way of reducing pressure to the project team. But that cannot be the usual approach. There are license fees customers are paying for the support.

      Cheers Martin

      Author's profile photo Martin Fischer
      Martin Fischer
      Blog Post Author

      As I see, quite some people already viewed this blog post. I'm very interested in getting more feedback. Is this only a very specific experience I had with SAP Support or is it in a way a general problem?