Some time back, I wrote about Opportunities for SAP Innovation. At the time, I wasn’t really expecting a lot, and I likely did not have much influence. However, I do find it coincidental that many of the suggestions I offered have been adopted. Some of them, such as the switched framework to improve order management processing, are included in ECC 6.0 EhP4.
One issue that I have been contemplating for a long time is how to dramatically improve ABAP development and overall application enhancements. My own requirements were to find a way to make ABAP coding simpler, improve code quality, provide better overall system performance, and provide easier troubleshooting. Tall order, yes. Impossible? No!
Welcome to the “Big Data Revolution.”
This post is more about a technical issue that SAP can easily address, which would completely revolutionize its own internal development as well as external customer development.
The New SAP Development Revolution
I am not an SAP ABAP coder, but over the years I have had enough exposure to see some of its great tools, resources, and improvements. This development effort has been mostly on the usage side of the existing syntax.
- What if there was a way to revolutionize the way ABAP is coded that is completely compatible with current syntax?
- What if it dramatically improved coding quality and solution development?
- What if it improved the performance and consistency of customized ABAP solutions?
- What if it simplified the entire coding process and made troubleshooting easier?
- What if it opened up a whole new world for coders to develop dramatically improved solutions?
Not only is this improvement possible– it would propel SAP’s place in the entire business application space to new levels.
Where Did This Crazy Idea Come From? And What Is It?
After many years working in SD (along with other modules), I had a client who needed help creating a new “smart” trade promotion execution solution. The solution needed to do several things that no standard SAP process handles. It needed to dynamically determine complex offers with discounts, free goods, limits, caps, and quotas; perform dynamic best price processing; provide loyalty points; etc.– all while dynamically evaluating the customer segment and strata for offer eligibility. The solution had to be done across a large population of order items, with multiple promotions based on the mix of products and the number of discounts or promotions that had already been given to a customer over time. The mix of products or offers could bundle multiple free goods, multiple offer discounts, or other special items, in a many-to-many relationship, based on the customer purchase and purchase history. Additionally, performance needed to be good because of the huge order volume.
The client had been asking for someone to deliver this solution for some time. A previous system integrator who did their upgrade couldn’t do it. I ended up spending six months working on a new custom-coded ABAP “mini-module” in SAP that allowed them to achieve their goals by using mostly master data.
That process taught me more about ABAP programming and SAP coding than I ever anticipated. As I went through this process, I was amazed at one simple thing that was completely lacking from all of this coding effort: the amount of virtual SQL syntax for internal data processing in the form of loop, sort, read table (with key), append, move, move corresponding, index, etc.
Why not develop the syntax to handle all of this in the background through virtual select statements? Why not create a new “iSelect” syntax which performs all of these functions that can be exploded?
SAP already uses internal tables in memory for processing data during the transaction stream. By creating a new “iSelect” syntax, much of this coding, looping, moving, etc., could be masked by fairly common SQL type commands. Since this would be compiled syntax, the performance would likely be better, and the quality would be far better while needing fewer lines of code to accomplish the same thing. For simplicity, I will call it “internal SQL” or, iSQL.
This would be the perfect complement to SAP’s HANA in memory processing, and would help with reporting extractor and programming development of all kinds.
This type of iSQL could be developed to allow inner or outer joins on internal tables, external tables, or any combination of them. The normal SQL statements such as Select Sum, Select Distinct, etc., could be employed throughout the entire ABAP processing stream. Still more interesting would be the ability to “explode the code” underneath this new iSQL syntax. When finer detailed control, processing, or calculations are needed, within or across joins, the underlying loop, sort, append, etc., could be exploded out and adjusted to fit the specific need. This would speed up development efforts by quickly creating a rough data processing framework and then exploding the code to make more detailed adjustments.
By focusing on syntax for the internal loops, sorts, reads, sums, append to table, move, etc., the coding complexity is reduced while also providing more flexibility and options. SAP would have greater control over the development of the internal/external table processing standards, and programming knowledge around actual data processing would improve. This would be the perfect complement to SAP’s HANA in memory processing.
This system would allow for faster, more reliable coding efforts with a higher performance result. Small performance tweaks or changes to the underlying compiled iSQL statements, along with that ability to explode the underlying code, would more quickly and consistently deliver SAP solutions.
Most importantly, this could be rolled out piecemeal and stay completely backward compatible with no negative downstream effects. As new iSQL syntax is developed, the original coding standards could remain in place without change. It would just add an additional set of power processing options. Think about all of the areas this would radically affect: custom coding, data conversion, SOA development, report development, function module creation, you name it. This could create huge customer benefits for outstanding development.
