Monday, June 15, 2015

An online course on SAP debugging

I think debugging is one of the most important skills to do advanced work on SAP. At least from my experience, when things get hard it is either the debugger or data analysis that will help find the solution. As far as I know there are not many resources to learn and improve the practice of debugging. So, as an attempt to improve this, I worked on assembling a mini course on SAP Debugging, following the patterns of the modern MOOCs.

I think it turned out quite OK and it was fun, probably I will be doing more of these. You can find the debugging course here.

The course is for beginners, but it also includes some advanced topics that can be interesting to experienced people. And it has some assignments that should not take much time and (hopefully) will be fun.

Looking forward to see you in the class!

Monday, May 18, 2015

SAP Unit Tests actually exist, report of a sighting

One of most impressive things in SAP, and impressive in a bad way, is the huge effort of people executing tests to validate the software after upgrades or some larger developments. It should not be like this. We now look back and we think it is funny a room full of people performing calculations like in this picture from the 40s.

But almost 100 years later this is more or less how a SAP upgrade is tested.

The reason is historic. The "old" SAP code is large, monolithic and highly integrated (a nicer way to describe a crazy web of dependencies). Not surprisingly this older code comes without automated tests, these would be hard to implement in such architecture. But not all SAP is coded the same way. Components developed in the last 10-15 years follow the typical object-oriented modular software best practices. And SAP also includes a complete framework for unit tests. My expectation was that SAP would start shipping more and more unit tests, and this would help reduce the need of manual testing and reduce the risk of regressions when installing SAP updates.

So for many years I asked myself: Where are the SAP unit tests???

Many times I tried the option to see the unit tests in SAP objects, just to find out ... there was none.

Anyone remembers something similar? This documentation option in functions. At least the experience is consistent, it almost never shows any documentation.

It actually shows a message to make you feel there could be something in other language. But, of course, there was nothing.

But now I finally saw some unit tests in SAP code. It was in /SAPAPO/CL_ALL_LOCK_DELTA class (in SAP SCM software).

So unit tests exists, it is worth searching for them. Looking at the unit tests is also a good way to understand how to use that part of the code.

And now I have some SAP example to show when trying to bring unit testing best practices to the custom developments world. SAP recommends using unit tests. You know those words can take you a long way.

Sunday, February 08, 2015

SAP S/4

Last week SAP released S/4, the evolution of their most important product the R/3.

I think this is a good occasion to talk about what makes SAP a successful software. Does S/4 have the magic ingredient that made R/3 so successful? So why was R/3 a success?

When I started working with R/3 I was very impressed with the development environment, the tools in SAPGUI to develop the code running in the server, and how easy it was to start debugging a running program. At that time I thought SAP was great because it was based on this flexible development platform.

But of course some time later I realized it was not the platform. The ABAP language is a pain and lacks in many areas, for example it is quite bad for numerical algorithms. Concurrency is not very efficient, the web layer is slow and the many web frameworks are obsolete even before having some real adoption. Forget it, it was not the platform.

What is really cool in SAP is the applications, having so many applications, for so many areas, industries and processes. But usability is bad, performance also not so good, and there are so many custom applications in SAP projects that something must be wrong with what comes out-of-the-box.

The applications helped a lot, but something else was very important in R/3, the expensive price tag. I'm not joking here, a very expensive price is a powerful feature. When a software costs 1k either it works or it will be scrapped, no client will pay 10k or more in consulting time to adjust and integrate the software. But if the software costs 1000k then 100k in consulting is very reasonable. And if out-of-the-box things don't fit well, after 100k of consulting a lot can be done to make the client happy.

Will S/4 will have the R/3 magic? Yes I think we can trust it will be quite expensive ;-)

Monday, October 06, 2014

SAP code base

Hasso Plattner, founder of SAP, is also a teacher in an open online course about in-memory databases. In one of the lessons he mentions experiments done by SAP, that by moving some logic to database stored procedures (math logic as he calls it) it was possible to reduce as much as 80% of the code size in the application server. This is of course one more chapter in the SAP HANA is great story. But I cannot help but comment this from the other point of view. SAP was able to become world leader in enterprise software with up to 80% bloated code base. One more case where "good enough" was the best decision.

Friday, December 06, 2013

More values in SAP domains

Some many years working with the SAP server and it was just recently that I learned it was possible to add more values to standard domains that have a fixed list of values. It is not a big secret, it is just an option in the menu and then it is like append structures in tables.

This was useful to add the missing APO store location 1040 to the CRM domain used in the configuration of location/business partner mapping.