1 6 7 8 9 10 65 Previous Next

ABAP Development

969 Posts

There is a MONSTER in my pocket!


Writing a Book for SAP Press – Part Five

Table of Contents


Business Object Processing Framework


Exception Handling

To Be Continued


This is the latest in my series of blogs about writing a book about monsters for SAP Press. They insisted it should be all about monsters and I had to fight tooth and nail to get some mentions of the latest features in ABAP inserted here and there. The last such blog was as follows:-




As might be imagined it is becoming more and more difficult to find blog headings with “monster” in the title, but hopefully I am going to run out of chapters before I run out of monster headings. I’m half way through already should I should be OK.


As mentioned in earlier blogs SCN does not much like people doing big adverts for their own book e.g. just saying “look at this” and then listing the table of contents. So I have been focusing more on the actual process of writing a book i.e. deciding what to add and what to leave out, and putting in material that was cut from the actual book due to lack of space. My original manuscript stretched to the moon, and so had to be edited down a bit.


In earlier blogs I talked about the reasoning behind the chapters in the first section – developer tools. Now we move to filling up the next section which is all about business logic.


MMMBOPF, Ba Duba Dop

When writing a list of exciting new SAP tools from the last few years, the “Business Object Processing Framework” (BOPF) sprang straight to the top of the list. The interesting thing about the BOPF is that it arrives via a support stack as opposed to by an upgrade. Where I work we have a 7.02 system and the BOPF arrived last week, as a side effect of upgrading the support stack level of the “business suite foundation”.


This cannot be stressed too much – support stacks now add extra functionality, which was not previously the case.


Anyway the problem I had was that the series of blogs by James Wood about the BOPF were so amazingly good,.



How could I write anything on the same topic without looking like the biggest plagiarist in the universe? He seemed to have covered everything.


Buddy, Can you Spare a DYNPRO?

Since I had to take a radically different approach I thought I would compare the BOPF to traditional DYNPRO programming as opposed to the OO way of looking at it. This is the sort of approach which could get me tarred and feathered – you will hear the six guns sound, as they drive me out of town.


What’s so good about BOPF anyway?

I like to start any discussion of a new tool not with the the “how to” but the (to me) more important “why” as in “why is this framework better than the twenty million frameworks that came before it?” The clue is in the fact that there have been so many attempts previously.


The History of SAP Business Objects

For the sake of argument let us say I have a new custom object type – a monster – that I want to set up in SAP. There are a wide variety of ways in which I could go about this. Let us examine them briefly one at a time, starting with the oldest.


In every case the idea is the same – this is the “model” in our “model – view – controller” framework, a model contains the business logic as to how a particular real world object behaves and what attributes it has.


Let us look at the “Famous Five” frameworks that preceded BOPF, try and work out which one of them is Timmy the Dog ( he’s so licky ) and then see that BOPF is proud to be the sixth in the series.


SWO1 Business Objects

I am a big fan of SAP Business Workflow (which was laughingly renamed “webflow” briefly during the dot com boom) and that works using business objects defined and maintained using transaction SWO1.


This is the earliest example of an object orientated framework in SAP with attributes and methods and events, and even inheritance as you can “delegate” the standard SAP business object like a purchase order to your custom version and programs that call the standard object start using the custom one without knowing.


Nobody could argue this approach was perfection itself but it did a really good job especially considering how long ago this was created.



If you call transaction BAPI you will see a tree where you have a wide variety of business objects, each one either represented by an SWO1 business object or by a BAPI set of function modules.


Business Application Programming Interfaces (BAPIs) were created with an external view in mind i.e. an external system wants to created / read / update / delete sales orders in SAP and needs an interface (signature) so that it can provide the needed instructions in the correct format.


The problem here was that the signatures were amazingly complicated (in order to try and give as much functionality as possible) and were (with a few exceptions) very poorly documented, the naming conventions were all over the place, and they still did not deliver all the functionality you could get by doing a BDC on the standard transaction (to be fair replication all online functionality was probably impossible for sales orders).


Nonetheless this was a still usually a step up from BDCs for performance reasons (no need to render the screen in the background) and 99% of the time they did not break during an upgrade (I had some grief with the purchase order BAPI moving from 4.5 to 4.7).



The day dawned when the tasks in workflow had two options for picking which objects you wanted to use – traditional SWO1 objects or custom classes you define yourself using SE24. Your custom class had to implement a few interfaces and the workflow system could then talk to it.


Apart from the perceived absurdity of having two frameworks that looked almost identical doing the same thing, there were still some gaps in that the new Z classes could not do everything an SWO1 object could within the workflow system.


This led to crazy situations, like the time that, because of one such gap, I created an SWO1 object and then delegated every method to an equivalent SE24 class.


In addition a lot of people have wondered why SAP did not create a series of classes to represent the same objects that SWO1 covered – sales orders, purchase orders, leave requests and so on.


Instead you get the result than ten thousand different programmers create a ZCL_SALES_ORDER class (I know I have) in their own system, all different to a smaller or greater degree.


This has led to “Project Objectify” an open source project on SCN which was first postulated by Matthew Billingham and then taken up by Bruno Esperança to try and unify all these disparate efforts to a uniform set of classes for business objects.




This is not actually at odds with the BOPF, as we (I would like to get involved in that project) want to develop a set of business object classes that can be used with any SAP business object framework – past, present or future.


Persistent Objects

The SAP database model was not really designed with OO programming in mind. To address this gap SAP came up with the idea of “persistent objects” which was a framework that provided a uniform way to handle transaction processing for classes that represented real world objects – locking, database updates, queries and the like. This was also known as “object services”.


You will see in SE24 there is a flag to enable a class to be persistent (instances can be saved in the database) which makes the class implement IF_OS_STATE and generates some “co-classes” to enable your new class to work with this framework.


A whole SAP Press book has been written on this subject, but this concept does not seem to have caught on as well as SAP would have liked. Many people perceive this framework to be over-complicated and crawling with limitations e.g. at one point data structures had to have their fields be in alphabetical order for some reason.


CRM Business Object Layer (in ERP)

Not everybody has the SAP Customer Relationship Management (CRM) system implemented, but if you have an ECC 6.0 system you may be surprised to know that the CRM “Business Object Layer” (BOL) has found its way into the core ERP system.


If you go into transaction SE80 and look for package CRM_BOL you will see the whole framework sitting there quietly, with most programmers blissfully unaware of its existence.


In contrast to the persistent object framework I have never heard any programmer say anything bad about the BOL. If anything programmers who have worked on this in a CRM system wax eloquent about how this is the greatest thing since sliced bread.


Again it is pointless to go into detail here except to bring to your notice that this exists, and to stress just how many ways there are in SAP of achieving the same thing,



The Business Object Framework came in with ECC 6.0 EHP5 “Business Suite Foundation” Support Stack 11, SS5 in EHP6 and as standard in EHP7. It is also used in the SAP product “business by design”.


This has the same aim as all the previously mentioned business object frameworks generally and in particular the persistent object framework / object services – to not only provide a representation of a real word object within SAP but to also provide a uniform way to handle things like authorizations, transaction management, locking and so on.


In summary the main benefits of BOPF are to automate certain areas which you would usually have to code yourself whilst writing programs, and to give you a clear place to put each piece of functionality, separated in such a way as to make your program more “anti-fragile” i.e. resistant to change.


I would also like to briefly touch on two of the benefits not related to coding a transaction – integration with the persistency layer (shared memory) and UI layer (Floorplan Manager).


Use of Shared Memory

I would guess that 99% of the time you would want a business object to be persisted in the database, but it is also possible to have BOPF objects that live only in shared memory.


I have yet to see many practical uses for this, but as always it is good to be aware of the possibility.


Integration with the Floorplan Manager

Do you remember the song “I Spy for the FBI”? In this case FBI stands for “Floorplan Manager Business Object Integration” i.e. it should really be FMBOI but that would take all the fun out the acronym.


This lets you create a Web Dynpro application for creating and maintaining instances of your BOPF business objects with dramatically less coding.

SAP also claim that their “target architecture” for the future involves something similar to the FBI which will integrate BOBPF with UI5 in the same way



When I worked in Heidelberg at lunchtimes I used to go to the beer garden round the corner, and whilst eating my chicken wings (or Flammkuchen) I would be reading the book by Carsten Ziegler about BRFPlus, the Business Rules Engine., which promises to replace the IMG, the condition mechanism for pricing and output, and the internal combustion engine, all whilst giving “the business” greater ownership of their own business rules.


Probably because Heidelberg is just up the road from Waldorf, none of the middle aged guys who were eating their lunch at that drinking establishment seemed to think it odd I was reading a book with a big SAP logo on the front.


Whilst I was gone our Australian subsidiary upgraded to ECC 6.0, so as soon as I got back I was bursting to find a problem worthy of the attention of BRFPlus. None of my colleagues had even heard of the thing, and had no idea it was sitting there in the system, ready to use.


I did in fact find lots of valid business uses for this, so it had to go in the book, although BRFPlus has been available since version 7.02 of ABAP so it some sense it is not “new”. Nonetheless it is evolving at a breakneck pace, my understanding is that at any given time there is a huge backlog of features to be added which a team of SAP developers are working on.


In case I completely stuffed everything up (i.e. everything I wrote turned out to be wrong) I sent my draft chapter to Carsten Ziegler himself, and he was kind enough to not only review the chapter but also arrange a screen share session so I could look at the development system in Germany and have a sneaky peek at the future of BRFPlus.


He also put my mind to rest on the two areas of BRFPlus I was worried about – namely performance of the tool in general, and ease of data entry.

BRFPlus lives inside the ABAP system but the front end is Web Dynpro which makes it look a lot different to the IMG or similar SM30 type transactions where you are used to entering data for business rules. I had horrible performance problems using BRFPlus at first, staring at a big whirling circle for minutes on end whist entering data. It turns out that most of that is a one off hit the first time a screen gets called up, the same way you get the “compiling XXXX in a different session” message when you start doing SAP GUI transactions after a support pack installation.


The remaining performance problems are constantly under investigation and get addressed in the huge bunch of OSS notes that come with every support stack. The runtime of BRFPlus is never going to be an issue, the rules get compiled into ABAP code when first accessed and thereafter involve no database access at all.


My other concern was the ease of data entry – filling out a decision tree, or a line in a decision table seemed to take an awful lot of button clicks and drop downs compared to the IMG/SM30 equivalent. If BRFPlus is going to take off it has to be just as easy or easier to use as the thing it is replacing – just like OO programming is easier to use than procedural programming (tee hee hee)! Once again, the team at SAP are on the case, investigating an easier way to enter data.


A lot of people have squawked like a duck because in its natural form you cannot change business rules directly in production, whereas in the past with Z tables the developer has the choice to enforce changes being made in development and transported through the landscape, or to have the table able to be directly maintained in production.


SAP might say to us customers - “why in the world would you want to change data directly in production”. A lot of customers would answer “because we do” which in the end is the only answer that counts. If someone has the ability to do something they want right now, and you are trying to convince them to take on a new tool which can’t do the thing they want, you are not going to get very far.


I will give a concrete example – in my company we have a table which controls which plants have certain interfaces active. If the device at the plant breaks down you need to switch the interface off right there and then, to enable manual entry at the plant of the information which was coming from the device. Waiting a day for a transport just will not cut the mustard. So we have a Z table controlled by the helpdesk which can switch an interface off directly in production.


It’s the same with a table which says what raw materials come from which quarry. If we have a huge cyclone like we did the other day, the power at the quarry goes out along with the phones, and we may wish to change the table to another source of supply right there and then. If we had to wait for a transport, by the time it went through the rain would be over, and the quarry back on line again, and then we would have to do another transport to reverse the change. In the meantime any plant relying on that material would be stuffed.


The other day a blog came out explaining one way to maintain such rules in production:-




You can see in the comments at the bottom that another way is to use the separately licenced product “Decision Services Management” which lets you do a remote simulation of the effect the change will have before it hits production, approval etc. Lovely, but it costs extra.


At my company we built our own application to do this (simulation / workflow approval) because it was deemed cheaper than buying the DSM licence. I am sure Carsten would be amazed that we did this. Mind you the programming bar at my organisation is very high – much as I like to blow my own trumpet I am not even the best programmer, there is another guy ten times better than me. Not every organisation is in that position.


Regardless, I think BRFPlus is the future of IMG type rules, and my chapter on the subject was probably the one I was most satisfied with in the whole book.


To Be Continued

To end with the same paragraph as the prior blogs on book writing, in subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.

Cheersy Cheers




PS I think the “Timmy the Dog” award should go to Persistent Objects.


Hi Guys,


I would like to share my knowledge on technical which will be helpful to the Functional consultant to prepare the Functional specifications and hope will help full to the Technical developer on designing the Structure or Transparent Table and finding the data type and length in simple way.

Before going to detailed explanation, we have to understand - Why Functional consultant need technical knowledge:

  1. Prepare the Functional specifications
  2. Understood requirement from client in detail and can map into Technical words.
  3. Helping to Technical developer on difficulty developments.
  4. To discuss with Client on possibility and non-possibilities of logic and impact on report performance.
  5. Discussion with Technical developer will be more flexible if you have knowledge on Technical.

I would like to explain knowledge on How to differentiate the tables and How to find Table name with reference to field and description and etc...

And also will discuss about the logics which will be frequently used in Developments of smart forms and in new customized Reports developments.

  • How to find Configuration table name with reference of master data table – field name.

Generally we know lot of configuration data will be used in Master data’s. But we will be used only code to create the master data’s. While saving table also we know only code will be save in master data’s table or in transaction data tables and corresponding code description will not get update in master data tables.

While developing the report or smart form development mostly user need only description in the output development. For this again we will be search in configuration level what was table name finding through F1 or some other ways.

Here explaining some fields configuration table can find from Master data table- field name.

Example : If Material Group code will be enter in Material master but if you need to find description of Material group then you have to go in OMSF and need to find the table name or description. But below table which will be help full to find the Configuration table name.

Table Name: DD03M or DD03L

DD03M – Generated Table for view

Enter table and field name:

Assume MARA table and field name MATKL and language “EN”.




And execute the table.

Check “Check table - filed (CHECKTABLE) in DD03M or DD03L




See the table name T023 and pass this into se16n




It will help full Not only for functional consultant but also for technical developers to develop the reports and smart forms and in data extraction these table will be help full lot.

Not only configuration table, we can find data type, ABAP type, data element (in DD03L) and length of field and position number in se11 and number of character  and table category from  DD03VT and  DD03M and DD03L table.


  • From Table  How to find where used list of programmes

Too much difficult to remember the program every time which was developed for each developer and functional consultant. Developer Sometimes they will create maintenance table for pick the user values. In this case Z table remembering is little bit easy to compare to remembering the table.

The following way we can find the program name from table.

Table: D010TAB

D010TAB: Table for Use Report<->Tables

Pass table name in this D010TAB table,

Assume ZMM_TABLE which is developed for STO auto creation.

I need to find the program which I was used this table ---

So I have passed this table into D010TAB table.






Check in Se38








This is one way can find program name from tables..


As of now we are discussed How to find Configuration table and from table how to find where used list of programs. Now will discuss How to find the Transaction code for the Program

  • From Program how to find the Transaction code

Using below table we can find Transaction code:Table name: TSTC   Program name: ZBDC_XX_PO1.PNGExecute the Program 2.PNGHere you can get details of Transaction code of the Program.Now we will discuss on list of tables used in one program

  • Find List of tables used in One program

Some programs developer need to create lot of customized tables. It is difficult to remember what are the tables used in the Program. The below simple way we can find the list of tables and structures used in Program.

Go to Se16n,


Enter table D010B

Enter Program name





You will get all tables and structures used in Program ..

Preamble -

Consider a scenario where a standard costing (S) is used for raw material pricing.

Purchase Orders are generated for raw materials and the standard cost of raw material is captured in condition type ZI01 as per PO pricing procedure.

The freight related to procurement is captured in condition type ZCFR which is also available in the PO pricing procedure.

The freight cost is calculated as a percentage of the standard cost condition ZI01 and captured in the PO pricing procedure.


Issue description -

The issue faced here relates to changes in the standard cost and the effects of that in the freight calculation.

Currently, once the PO is created, the freight cost (condition type ZCFR) gets calculated on raw material standard cost (condition type Z101).


Material master Accounting View for Material 41.



In ME23N, standard price is 120 USD.



Post creation of PO, if material standard cost is changed through standard cost estimation cycle (yearly / half yearly), it does not automatically update the condition type Z101 & hence during GRN freight cost( condition type ZCFR) gets calculated on old material standard cost.



Before GR (MIGO) , Using the TCODE MR21, standard price of the material 41 is changed from 120 USD to 150 USD.




After pressing Save, same price of 150 USD is available in Material master.



Now, all the pricing calculation should occur with respect to this latest price of 150 USD. However, this recently changed price is not updated in PO. It still shows old price i.e. 120 USD which is incorrect.


Solution -

To overcome this, the new standard cost that has been released for a material should be updated in all open PO for that material (condition type ZI01) so that during GRN the new standard cost (condition type ZI01) and freight (condition type ZCFR) will be posted at latest cost.

The requirement is also to ensure that the changes for new standard cost need not be done manually by the business user and a solution which would dynamically update the standard cost of an existing PO.



While doing good’s receipt using MIGO, In order to update latest Statistical price (MBEW-STPRS) to PO line items, BADI ‘MB_MIGO_BADI’ will be implemented. Method ‘LINE_MODIFY’ of BADI will use BAPI ‘BAPI_PO_CHANGE’ to update latest Statistical price (MBEW-STPRS) to PO line items.


Code to update Statistical Price should execute only for Goods Receipt process for the POs other than Stock Transfer POs.


  • To check if activity is Good’s receipt (A01) or not, method ‘MODE_SET’ of ‘MB_MIGO_BADI’ will be used. Parameter I_ACTION of method ‘MODE_SET’ will be used for checking the same.


  • To check if PO is Stock Transfer PO or not, EKPV (Shipping Data For Stock Transfer) table will be used. IF entry for PO exists in EKPV, it’s Stock Transfer PO else it’s not.


Once the PO is updated with latest Statistical Price, message ‘Latest Cost updated in PO’ will be displayed.

In order to execute this price updating logic only once, internal table GT_PROCESSED is used. All the processed PO# for that particular session will be marked as 'X' initially so that when control comes again to method LINE_MODIFY, it will not execute the price updating logic again and thus will improve the performance. Finally, all the memory IDs will be flushed when user posts the document using method POST_DOCUMENT.




Go to configuration settings through path SPRO – Ref IMG - Material Management – Purchasing – Conditions – Define price determination process – Define condition type – Select condition “Z101” – click on Details tab


Table V_T685A in condition type “Z101” should have status “No limitations”





Code Snippets :


1. Method LINE_MODIFY :








        END OF LTY_KONV.




          PO_NUM TYPE EBELN,

          PROC  TYPE CHAR1,








        END OF TY_MBEW.





























          LV_MES TYPE CHAR100.






















  CONSTANTS : LC_X    TYPE CHAR1                  VALUE 'X'.








              LC_S    TYPE BAPIRET2-TYPE    VALUE 'S',

              LC_ME  TYPE BAPIRET2-ID      VALUE 'ME',

              LC_06  TYPE BAPIRET2-ID      VALUE '06',

              LC_006  TYPE BAPIRET2-NUMBER  VALUE '006',

              LC_023  TYPE BAPIRET2-NUMBER  VALUE '023'.



* Execute only for Goods Receipt





* Execute only Once.This Memory ID GET Export from below code

















* Restrict the logic from Execution for Stock Transfer PO

















* Get Condition Record Number







* Get PO details




      ITEMS        = LC_X




      PO_ITEMS      = GT_ITEMS.






* Get Std Price










* Sort Material Valuation details












                                            MATNR = GW_ITEMS-MATERIAL BINARY SEARCH.



    IF SY-SUBRC EQ 0 .

* Assign Current Standard Price


        LV_CALC_AMT = GW_MBEW-STPRS / 10 .





* Delivery Complition Flag is marked,do not process the Item







* Condition Records



    GW_COND-COND_TYPE    = LC_Z101.




















    GW_BAPI_POITEM-CALCTYPE  =  LC_C.          " Reprice it

    GW_BAPI_POITEM-PRICEDATE =  LC_3.          " Reprice it based on current date











* Schedule Line




* Supress Leading zeros





        OUTPUT = LV_LINE.

















* Update PO with latest Pricing





        RETURN        = GT_RETURN

        POITEM        = GT_BAPI_POITEM




        POCOND        = GT_COND

        POCONDX      = LT_POCONDX.





* When PO is open in change mode, show error message


                                          ID    = LC_ME AND

                                          NUMBER = LC_006 .



      MESSAGE GW_RETURN-MESSAGE TYPE 'S' DISPLAY LIKE 'E'. "PO is being edited by some user





* Display Success message


                                          ID    = LC_06 AND

                                          NUMBER = LC_023 .



          WAIT = LC_X.

      IF SY-SUBRC EQ 0.

        MESSAGE TEXT-002 TYPE 'S'. " Latest Cost updated in PO











2. Method MODE_SET.



*Local Constants

  DATA : LC_A01 TYPE GOACTION VALUE 'A01', " Goods Receipt




    LV_MODE = 'X'.














Conclusion :

During GR when User enters the PO in MIGO.


Once the user hits Enter button after entering PO# in MIGO, in the background BADI ‘MB_MIGO_BADI’ implementation changes the PO Pricing conditions with new material standard price ($150 in this case).

Finally Success message is shown.


Now, if we check the PO 4500264840 in ME23N, we see latest cost for condition type 'Z101'.


Post GRN : Financial document :

Freight will be calculated on new material price in GRN that resulting in posting correct PPV.



Test Cases:




Kill delayed work processses automatically through batch


Generally we use TCode SM50 to view running processes and delete the long running processes manually. This is an attempt to make this manual process into automated process.

SAP has given a function module 'TH_SERVER_LIST' which gives all the details of the SAP Application Servers on the network.

SAP has given a function module  'TH_SYSTEMWIDE_WPINFO' which gives all the details of work processes on given SAP Application Server.

We can filter the details by which type of work processes shall be stopped based on the time it has taken.

We have to take those process identifications (PID) and SAP Application Server and call the function 'ThWpInfo' to stop the process permanently.

This report could be scheduled so that it runs on its own and stop the long running processes automatically.

It is to be noted that this Program uses unreleased function modules and kernel calls, and so is to be used at your own risk.


Complete source is as follows:

I do hope it helps.

I thank Mr. Matthew Billingham for his valuable suggestions and guidance.





CONSTANTS: opcode_wp_stop TYPE x VALUE 2.

= itab_as
= 1
OTHERS         = 2.

LOOP AT itab_as INTO wa_as.

= wa_as-name
= itab


IF WA-WP_TYP = 'DIA' AND WA-WP_STATUS = 'Running' AND WA-WP_ELTIME GT delay_seconds.

ALL 'ThWpInfo'
ID 'OPCODE' FIELD opcode_wp_stop
ID 'SERVER' FIELD wa_as-name
ID 'PID' FIELD wa-wp_pid.



Damir Majer

ABAP Developer quo vadis?

Posted by Damir Majer Apr 27, 2015

ABAP Developer Specialist or Generalist or something else?


What is an ABAP developers nowadays? This question I'm trying to get answered and also how I would describe my work at this time as a developer?


( https://infogr.am/abap_developer-96 )

In this blog I try to "better understand" the ABAP Developer or sort the required Skill-Set of an ABAP Developer mentally.


The classic ABAP developers

Is the classic ABAP developer existing at all? Why the skill requirements are so different? And how the developer Jobs actually looks really?

In other professions there was a development from generalists to specialists and to Super-specialists. Take, for example, the doctor profession for comparison. Here the development of the general physician to the medical specialist as to the Super-specialist. A similar trend I see already in our profession.

Specializations of the ABAP Developer

  • classic ABAP Developer
    • enjoy Controls / Reports / Screen Programming
  • WebDynpro Developer
    • WebDynpro ABAP 4 / JAVA
  • BW Developer
  • SAU UI Developer 5
    • Fiori
    • HTML, CSS, Javascript, Jquery
  • SAP HANA Developer

MUST-HAVE-knowledge for all ABAP developers

Yes, it is a criterion that both in freelance as well as in permanent Jobs you should mastery the ABAP OO and  also the OO thinking which summarizes for me content such as OOA, OOD and architecture skills.


SAP Module knowledge

Among the technological skills SAP Module skills are added.
In the SAP environment, there are an estimated 250 main and 750 sub-Modules. The SAP Module knowledge is very often a must-criterion for the ABAP Developer and only in combination they describe the "ideal candidate" for the company. I have my own opinion abaout the module-topic and my experience is so far that even experienced generalists  brings added value to projects where for them new Modules are used.

Additional knowledge

Each ABAP Developer should bring a good basic skills in the following topics:

  • Interface technologies (BAPI, RFC, IDoc, XML)
  • Performance Basics
  • Security Basics
  • Testing Basics



New frameworks and tools


  • BRFplus (see SCN)
  • BOPF (see SCN)
  • Core Data Services (CDS, see SCN)


What does this mean for me as a developer? The comparison to medicine can certainly bring many insights, but our profession is without question to understand quite different. My intuition tells me that the skill-set is quite developed so that a "broad-based developer" can make a big added value in the company in combination with a "specialization".

Generalist or specialist or super-specialist?


How do you see that?
What specializations  can you find in your job environment?



This Blog is also translated in german: ABAP Entwickler quo vadis?

Paul Hardy

The Loch Ness Monster

Posted by Paul Hardy Apr 25, 2015

The Loch Ness MONSTER

image001.jpg image002.jpg

Writing a Book for SAP Press – Part Four

Table of Contents


Debugger Scripting

Enhancement Framework

Exception Handling

To Be Continued

Back Back Back Back, Back to the Start

I have been writing a series of blogs about writing a book for SAP Press, a book all about the woes of being a programmer in the employ of Baron Frankenstein. The latest ABAP features also get a look in as well. The last such blog was:-



I am trying to get through this as fast as I can, but I have been delayed by a disaster. When I first joined SCN (SDN as it was then) back in about 2001, the only way to do so was by using your “S” number. The problem is, what if your S number ever changes e.g. you move jobs? In other words a disaster waiting to happen, especially now we have “gamification” which encourages us to get “points”.

I have not moved jobs, but my company did move from regional licences to a single global licence (3 years ago) which meant I got a new S number. I did not notice, but after 3 years SAP cancels dead S numbers, so that was that for my poor old SCN account.

It might seem childish to miss all those points I had amassed, about 3000 odd, and start again with the one point for setting up a new account, but it was not as if there was any choice. However the good news is that SCN are working on a way to “merge” dead accounts with new ones when this happens.

Anyway that’s my problem, not yours, so let’s talk about some exciting new SAP technology and why I felt it vital to the future of the universe to talk about this in print.

Debugs Bunny

In earlier chapters I had talked about unit testing and static code checks, to try and pre-empt bugs before the program was ever run. However there are always going to be bugs, which is why we programmers (yellow shirts) spend so much time in front of the debugger. As you all know with the advent of ECC 6.0 we have the “new” debugger with all sorts of extra functionality.

In the West Country of England where I grew up it is quiet common for a stranger to walk into a pub and the whole place stops talking and looks at them in a threatening manner. Then someone will come up to them and say “we don’t like unfriendly strangers in here”. It is often the same when SAP developers encounter some new technology like the “new” debugger when it walks into the room.

As a result many developers switch the new debugger off on the day after the system is upgraded and they see the debugger has changed.


In the same way there are four billion bacteria in the room you are currently in, the programs we write are always riddled with bugs at the start, hopefully not four billion - though with some program I have seen I wonder.

If someone tells me a program I have written does everything that was desired with no errors the very first time it is run in DEV or QA I am deeply suspicious, it is rare that anything works perfectly first time.


As a result we expect the first few tests – by ourselves or others – to return unexpected results. Hopefully we first see these as a result of failed unit tests before anyone else goes anywhere near our lovely new application, giving us a chance to fix the problems in our code before anyone else can pick them up and sneer at us.


Then it is time to sit in front of our program, type in /H to start the debugger and sit in front of our screen for hours stepping through the program a line at a time trying to work out the exact point where everything goes horribly wrong.


I once heard our BASIS department get a request from an HR consultant to extend the time before a debugger session times out from the default 45 minutes. If you need to spend more than 45 minutes at a time debugging a program then “something is rotten in the state of Denmark” as someone somewhere once said.


Where be that problem? I be after ‘e. It be up that Wurzel Tree and I be after ‘e.

As mentioned just now, in version 7.02 of ABAP the debugger changed dramatically. The look and feel was so different a lot of people looked for the option to change the debugger back to the way it used to be, set that flag, and then forgot there was ever such a thing as the new debugger. Tempting as that is I tend to feel that hiding your head in the sand like an ostrich is not going to let you take advantage of the myriad of added features in the new debugger, of which I think debugger scripting is one of the most useful.


Why are things always in the last place you look for them?

Because you stop looking when you find them.

— Children’s Riddle


Let us have a look at a pretty picture of what we tend to do whilst debugging.


Figure 1: Debugger Timeline

As can be seen the vast amount of time is spent debugging.


It could be said that spending 80%+ of your time looking for the problem is a horrible waste of time, even if it makes you feel like Sherlock Holmes. It has been suggested that Starship Captains, when menaced by aliens, should think of the last thing that could possibly work, and then try it first, to avoid wasting time, and in the same way if we could knock off some of the squares on the left and discover the problem sooner, then the day would be a lot less boring and we could proceed straight to the code writing activity that we love more than life itself.


The Robots of Death to the Rescue

Doctor : What do you do? What do any of you people do when you have a job that is too difficult or too boring for you?

Investigator Poul : I call for a robot….

Doctor Who and The Robots of Death – Terrance Dicks


The other day I was asked to check if there were any materials with duplicate legacy numbers (BISMT, as in Admiral Nelsons dying words to me which were “BISMT Hardy!” ) in our development system. I could have just dumped out table MARA in a spreadsheet, sorted the data and done a formula to compare each cell value with the one above it. That would have worked but I course I didn’t solve the problem that way – I am a programmer so I wrote a quick program to do the exact same thing.


If I can possibly solve any sort of problem by means of writing a program then that is the route I take. Let us say you have got to the situation where you know something is wrong with your program and are merrily debugging it. The fifth time you are in the debugger and find yourself doing the same steps, with no end in sight, you start thinking how boring this is and wishing you could make your life easier.


Solving this problem is what debugger scripting is all about, so I felt a small chapter on this subject in the book is the way forward. I wonder if anyone except me and my matey Brian O’Neill is actually using this. If you are please share what you think. I myself think it is so good all the programmers in your organisation should jump up out of their cubicles and do a Bollywood style musical number down the corridor singing the virtues of this “new” technology.


I want it all, I want it all, I want it all. And I want it now.

That about does it for testing, notice the first five chapters of the book – a third of the book – are all about improved development tools and quality control, or to put it another way “writing code fast and writing it right” the idea of which should make management types bounce up and down with joy i.e. the faster you bring the new thing to the table the more money the company makes.


In regard to the company making more money because of the programs you write, I read a blog by Chris Whealy the other day about Functional Programming



His position (I think) was that Functional Programming languages as pushed by universities were all about “purity” of the language i.e. “you do all the right things for all the right reasons” whilst imperative languages like ABAP were all about “making money. Mind you some CFOs view IT as a cost centre which can never have any sort of positive benefit to the top line.

I may have utterly misunderstood the above blog but I wonder if it is possible to square the circle. Is it possible to still make the money for the company (or make Government more efficient thus costing taxpayers like me less) by doing things right in the first place? Even more, can doing things right even make your programming faster than the traditional quick and dirty way? I hope so, which is why I focus so much on quality control.

User Exit – Stage Left

The first section of the book was all about programming tools, but I could not let you go without giving you a “game for a laugh” badge and mentioning something that has been around for a while now but was not mentioned in the “Next Generation ABAP Programming” book, namely the Enhancement Framework.


I think that (Enhancement Framework) is the bee’s knees, though some development departments in assorted companies ban the use of this. As an actual use case, here is what I had to deal with:-


As an example when creating a sales order via the standard VA01 transaction if you press the “create with reference” button then the default tab on the popup is to create the order with reference to a quotation. Once upon a time the business users wanted the contract tab to be the default, but after some debugging I found that what tab popped up first was hard coded (at least in the version of SAP I was using) as opposed to being read from a customizing table, and at that time there was no user exit to change this behaviour. So we had to live with it.


Enter the Enhancement Framework and you can insert some code in the standard so this does in fact read some sort of customising table rather than following hard coded rules.


SPAU Ballet

As can be imagined many companies have found that standard SAP programs almost exactly fit their needs, but need one or two tweaks, so the desire was to somehow change the standard SAP program. User exists solve the problem to a large extent but as you might have noticed they are not everywhere that every single company in the world might need them, so the answer was to do a “repair” which is in fact anything but a repair it is changing standard SAP code.  I’d just like to stress that in the vast majority of cases you can get round modifying standard SAP but sometimes you just have to do this as there is no other way of satisfying the business.


A long time ago SAP used to recommend you take a copy of the standard program, creating a “clone” that started with a Z, and then make your changes there.


As this was official SAP policy at the time many SAP customers did just that, and created an army of cloned programs. Then SAP belatedly realized this was the worst thing you could possibly do, as during an upgrade the original program would change (bug fixes and extra functions) but not the clone. Then came what can best be described as the “clone wars” with customers writing “clone hunter” programs, which eventually became part of standard SAP.

The revised policy was not to have clones, but to use the modification assistant to insert your changes directly into standard SAP code. Then, during an upgrade the SPAU process would recognize such changes and make you decide if you wanted to keep them or not.


This was a lot better, but if you have a fair number of such modifications to the standard system (and a lot of companies do, even ones with a “no modification” policy) then at upgrade / support stack time the SPAU process can take quite a while.


The enhancement framework can drastically reduce such overheads at upgrade time by replacing such modifications with enhancements. It is more than possible you could virtually eliminate the SPAU overhead during an upgrade or support stack application. As a specific example the form based user exits like MV45AFZZ are based on you modifying a standard SAP program, so at support stack time they have an alarming habit of removing all the code you added and on rare occasions this does not even show up in SPAU. Adding the code using enhancements rather the modifications is a lot safer.


The needs of every company vary dramatically so it is impossible to give a specific example that is useful to everybody, but here are a few potential ways to replace “repairs” with enhancements.


·         Let us say we have a standard SAP executable program which makes vendor postings, let us say the ERS process, but the document date is hard coded to today’s date via SY-DATUM. You want the flexibility to able to choose the posting date. You could use the enhancement framework to add some code right at the start of the program to add a new parameter for the user to input the date. Then at the start of the FORM routine which makes use of the posting data you can change the value of the variable that holds that date to the value of the input parameter.

·         You may want to add extra commands to a standard SAP screen or menu for whatever reason. Adding the button or menu entry is always going to be a modification, outside of the Web Dynpro framework. However, responding to that new button or command does not have to be a modification. Usually there is a CASE statement in the SAP program to respond to the various standard commands, and 99 times out of a hundred there is no WHEN OTHERS at the end. This means you can add an enhancement at the end of that routine with a new CASE block to respond to your new command.

As can be seen the possibilities are almost limitless. I think this is one of the best tools SAP has ever given us, but to use the phrase “not only, but also” there is another side to the enhancement framework.


BADI Santa

I have written a whole bunch of blogs on how to try and design an SAP system for use in multiple countries.




The answer there was to use BADIS (which go in and glove with the enhancement framework) so you can have a core system that is the same for all countries and yet each country can still do all the country specific weird things it wants to do.


When a country wants to change something, the new functionality is added, but the core program is not changed. This is a staple of OO programming called the “Open-Closed Principle”.


If you were to read any books on object orientated programming this principle would jump you at you almost at once.

In essence the idea is that you have a program that works perfectly and any change to that program might break it, so therefore you don’t want to change it. However you have been given the job of giving that very same program some extra functionality.

So the open-closed principal is all about making the program do something new without changing it. That’s obviously impossible you would think, so much so that when I explained this to one manager I could see he was thinking about committing me to the nearest madhouse.

When you look a bit deeper you will however see that SAP programs can be made to do different things by changing customizing values or implementing user exits – and all of this was well before SAP even looked at trying to be object orientated.

Warning! Warning! Danger Will Robinson


At long last it is time to turn to the business logic of programs, but once again I cannot stop myself going into broken record mode and turning back to the subject of quality This time I felt the need to waffle on about exception handling, specifically exception classes which I am not convinced many people are using, despite them having been around for ages.

There is nothing much I can say here which I did not say in the following blog:-



Earlier chapters talked about how you can prevent errors in the first place, errors in the program itself. Here I talk about the concept of “Design by Contract” which is designed to root out program errors before the program hits production, and also the normal use of exception classes which is (a) to handle situations which are “impossible” but you suspect might happen anyway, and (b) situations where things go wrong which are totally out of your hands but the program must react to anyway.

To Be Continued

To end with the same paragraph as the prior blogs on book writing, in subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.

Cheersy Cheers







I got interviewed the other day by a chap from the American SAP User Group (ASUG)


Have a look at the comments at the bottom. Some are very strange indeed, clearly written by some sort of automated comment writing robot.





Some months ago Thomas Jung introduced the REST API for the SAP HANA Repository. I've implemented a client in ABAP that uses the REST API, it includes a simple GUI that lets you edit files on the HANA server.




Clicking save will call the API and the code is saved on HANA.




I'll not recommend using the ABAP editor for XSJS development, as it is just a simple text editor that doesn't know about javascript.


The following example shows how a file can be created from ABAP using the API,


DATA(lo_factory) = NEW zcl_orion_factory( iv_url      = p_url

                                          iv_user     = p_user

                                          iv_password = p_passw ).

DATA(lo_file) = lo_factory->file( ).

lo_file->file_create( iv_path = 'foobar/'

                      iv_name = 'asdf.txt' ) ##NO_TEXT.

lo_file->file_update( iv_path = 'foobar/asdf.txt'

                      iv_data = 'Hello' ) ##NO_TEXT.


The code doesn't work with HCP, I haven't had any luck getting past the SAML authentication from ABAP.



larshp/abapOrion · GitHub

This post is our little collection of usefull table expressions used in SAP Transportation Management context. The examples are doamin specific, but maybe other can use the principles as well.

Special thanks to Horst Keller for helping us getting started!


A simple one to get started:


Extract  the latest timestamp from a table


    lr_tor_a_checkin->arrival = REDUCE /scmtms/actual_date( INIT res = lr_tor_a_checkin->arrival
                                                            FOR <fs_exec> IN lt_d_execinfo
                                                            NEXT res = nmax( val1 = res
                                                                             val2 = <fs_exec>-actual_date ) ).

Now for something a bit mor complex...

Extract Ealiest and latest timestamp out of a table with multiple time stamp fields in it




  TYPES: BEGIN OF ty_min_max_times,
           min_time TYPE /scmtms/timestamp,
           max_time TYPE /scmtms/timestamp,
         END OF ty_min_max_times.
  CONSTANTS: lc_max TYPE timestamp VALUE '29993112000000'.
    ls_min_max_times = REDUCE ty_min_max_times(
                            INIT res = VALUE ty_min_max_times( min_time = lc_max
                                                               max_time = 0 )
                            FOR <fs_stop> IN it_stop
                            USING KEY parent_key
                            WHERE (  parent_key = is_root-key )
                            res-max_time = nmax( val1 = res-max_time
                                                 val2 = <fs_stop>-appointment_end
                                                 val3 = <fs_stop>-aggr_assgn_end_l
                                                 val4 = <fs_stop>-aggr_assgn_end_c
                                                 val5 = <fs_stop>-req_end
                                                 val6 = <fs_stop>-plan_trans_time )
                            res-min_time = nmin( val1 = res-min_time
                                                 val2 = COND timestamp( WHEN <fs_stop>-appointment_start   IS NOT INITIAL THEN <fs_stop>-appointment_start ELSE lc_max )
                                                 val3 = COND timestamp( WHEN <fs_stop>-req_start           IS NOT INITIAL THEN <fs_stop>-req_start         ELSE lc_max )
                                                 val4 = COND timestamp( WHEN <fs_stop>-plan_trans_time     IS NOT INITIAL THEN <fs_stop>-plan_trans_time   ELSE lc_max )
                                                 val5 = COND timestamp( WHEN <fs_stop>-aggr_assgn_start_l  IS NOT INITIAL THEN <fs_stop>-aggr_assgn_start_l   ELSE lc_max )
                         ) ).


The underlying discussion can be found here.

Now, something more than just timestamps...


Extract the shortest duration together with another value which should come from the line with the shortest duration


DATA(ls_min_dur) = REDUCE ty_min_dur( INIT result = VALUE ty_min_dur( min_dur =
99999 )
FOR <ls_lddd> IN mt_lddd
USING KEY loc_fr WHERE ( loc_fr = iv_loc_key )
result-loc_fr  = <ls_lddd>-loc_fr
= nmin( val1 = result-min_dur val2 = <ls_lddd>-duration )
result-loc_to  =  COND #( WHEN result-min_dur = <ls_lddd>-duration
THEN <ls_lddd>-loc_to ELSE result-loc_to ) ).

This is just a step to think over how do we allow the programs to be debuggable. Its one of the ideas that i come to think over. We keep writing lots of code but at the end we need to debug them especially in the Production system. So debugging becomes an important issue!!.




Step 1- We will enable the program to be debugged thru the user parameters!!


This way we can add or remove the parameters and enable the code to be debugged in any system.

Lets say: we create parameters like: debug level, debug tcode and debug program name.


Some code snippet is:

CONSTANTS: c_param_debug_level TYPE memoryid VALUE 'DEBUG_LEVEL',     

c_param_debug_tcode TYPE memoryid VALUE 'DEBUG_TCODE',   

c_param_debug_prog  TYPE memoryid VALUE 'DEBUG_PROG'.


We will put a debug point in the program smth like this _debug_level 1. For more please see the implementation code i will attach!!


Step 2- We need to create a Function or a object that is going to be reading the parameters and checking the level of debugging and loading the details for debugging. Object that will be loading all the required data for debugging!!.


This should be called first then everything in the code! For example at the Standard report at initialization section.

As the code the name of this class is zcl_debug.


Step 3- We need to write a Macro in the code we want it to be debugged, so that we can stop the code at that execution point.

Why macro? Because via macro we can put Break-point and as macros can not be debugged thats the best candidate for this.


Code snippet: ***Writing the MAcros!!!


DEFINE _debug_level.

  if zcl_Debug=>get_instance( )->is_debug_level_correct( iv_debug_level =  CONV string( '&1' ) )  = abap_true.   "#EC USER_OK      BREAK-POINT.                                        "#EC NOBREAK




Step 4- we could be able to configure the level? We can use config table but that will complicate the debugging and most often its forgotten. So why not we use a pop up screen where we can change the debugging level dynamically!!


DEFINE _debug_configure.

  zcl_Debug=>get_instance( )->configure_debug_level( ).



Step 5- Final Look Report zxxx.


DEFINE _debug_configure.

zcl_Debug=>get_instance( )->configure_debug_level( ).





_debug_level 3. …


By this way we can enable the code to be debuggable which will make our life much easier!!



Any suggestions, please feel free to suggest me

There’s a MONSTER under my bed!


Writing a Book for SAP Press – Part Three

Table of Contents


Unit Testing

Static Code Checks

To Be Continued

Who’s that watching Benny Hill – Is it a Monster? Is it a Monster?

The other day I published my second blog about writing a book for SAP Press  - a book which primarily focuses on monsters but may possibly illustrate that subject by talking about all the latest ABAP technology.



My old matey Martin English – whom I shall be having a quick drink with at the Mastering SAP Technology event in Melbourne at the end of May 2015 – asked if I was ever going to shut up about this? Sadly the answer is no, not until I have finished documenting the thinking behind everything in the book, so ha ha ha ha, hard luck.

He also wondered if I was going to put all the best bits from the book online. Now that would be silly. I often do silly things, virtually all the time in fact, but I am not going to do that one. The author of the recent book “SAP Nation” Vinnie Mirchandani wrote that he likes to put 20% of the content of his books online. In my case SAP Press already give out a sample chapter, so that is enough to be going on with. Instead I am going to add in material that was cut out of my book for reasons of space.

Chapter and Verse

In the last blog I mentioned the thinking behind the first two chapters. To summarise…..

The first chapter was all about Eclipse,

Because that is so Cool and Hip.

The second was on new ABAP Features,

To show I practice what I preaches.

Going back to prose for a second I was trying to follow the logical flow of writing a program. The first step is choosing your development environment; the second is to make sure you are aware of all the new ABAP features at your disposal. The third step – and therefore the third chapter - is something more often seen in non-ABAP languages and is something I like to waffle on about like a broken record till you can’t take it any more.

How evil are YOU?

The first thing you are supposed to do when writing a new application is to write the tests before you write any actual code. A few years back I wrote a whacking great blog on the subject:-



I am an enormous fan of test driven development in general, and it’s manifestation in SAP namely ABAP Unit. This is not just an academic position, I write unit tests for all my new developments and retro-fit them when I make changes to old programs, and this has saved my bacon many times. What I mean by that is the automated tests point out to me the schoolboy errors in my programs well before anyone else can find out about them and laugh at me / sack me / whatever.

Yesterday, for example, I spent all morning writing unit tests for a business critical program. I would say as a result I made the application much more stable, but a lot of people would say I was wasting my time when I could have been doing something worthwhile. How can this be? Why, when some people realise what ABAP Unit is instantly say “oh my god, don’t do THAT!”?

Is this the right room for an argument?

The ABAP Unit framework came in with ECC 6.0, which entered ramp up in October 2005. So we are looking at something that is ten years old in the near future. If this approach and supporting framework are as good as I (and all the experts I keep quoting) keep saying they are then you would think that everyone would be using this by now, and it would have no place in a book about the „latest“ SAP developments. Yet it has been my experience that in fact very few ABAP developers use ABAP Unit at all and a surprising number are utterly unaware of its‘ existence.


Even worse, some development organisations have an outright ban on this approach. We now look at two common arguments against the test driven development methodology.


There are two possible groups who can raise objections:-

·         The developers themselves

·         IT Management


Developers Won‘t Use It / Don’t Like It


At a demonstration at my company in 2013 none of the other programmers had heard of ABAP Unit and my boss asked me if this was open source software like ABAP2XLS that I had found somewhere on the SAP Community Network web site.


So one reason ABAP Unit is not used as much as might be expected is that a lot of people don‘t know it’s there, but the other side of the coin is that even when they do know about it you have the „you can lead a horse to water but you can’t make it drink“ problem. This is when the developer has a quick look at the tool and decides it doesn’t add any value and so disregards it.


When I started looking at test driven development a few years back I thought “what a waste of time, 95% of my programs involve reading things from the database and updating other database tables, and then showing the result to the user, if you fake all of this using stubs what in the world is the benefit?”

It turns out that the remaining 5% of code is riddled with bugs and this shows up instantly during unit testing. If you don’t believe me, try it yourself and you will most likely discover the same thing on the very first attempt. Many times I have thought “this routine has only three lines of code – so it cannot possibly be wrong“ – yet it was. In the ABAP2XLS project unit tests have started to be introduced, and there was a test on a three line method that failed – a null value was passed in and the test was that a null value was passed out, except that it wasn’t.


Just to be clear about this, I think that any developer using test driven development and ABAP Unit for the first time on an actual program they are writing for productive use will discover a bug they would not normally have found until weeks later- within the first half hour, quite possibly the very first time you take the test • unit test option.


This is literally a product that sells itself (if you can get someone to try it), so developers are easy to convince, but then we come to the next barrier, which is management...


Some Things Just Can’t Be Tested

How can you do a unit test on say, a part of a program that has a pop up box requiring user input? It’s impossible surely?

Well yes, you do not have a user. The trick is to alter the program being tested so that all user interface code and screens (the user interface layer) is in its own class. Unit tests cannot have any user output at all, not even messages, so a unit test cannot call any code which might do a CALL SCREEN or a MESSAGE statement.


SAP have not yet worked out a way to reconcile the “call screen” statement which all GUI user interfaces revolve around with OO principles. The recommendation is to put your screen in a function module, and then wrap that in a method so it can be subclassed for unit testing. That’s a lot of work when creating programs when just doing a CALL SCREEN or MESSAGE statement is so easy, for what seems like zero return and you may wonder – is it really worth it? I would say yes, the benefit of being able to test something you could never test before (a part of the program which involves user interaction) outweighs everything.


It Takes Too Long

The only way to make your programs absolutely bullet-proof is to make sure every single line of code gets tested – every variation of every IF statement, every CASE statement etc.


This really means the amount of tests you have to write is directly proportional to the amount of production code you are testing, and because of the code needed to set up the tests and evaluate them afterwards that proportion is greater than 100%.


There are tools to reduce the amount of test code, but it could still be the case that the amount of test code you need to write is at least equal to the amount of code in the program being tested, probably more. So when you are done there will be more test code than production code.


You try telling that to an IT manager and see what happens. It is difficult enough getting a program working before the incredibly tight deadline as it is, and now we are talking about doubling the amount of code. That means doubling the development time doesn’t it? Doubling the cost? That would imply missing the deadline and coming in well over budget.


If that was true then test driven development would never get off the ground, management would ban the entire concept the instant they heard about it – and some managers do just that.


Here are two arguments you can bring to bear to counter the – inevitable – criticism from people who have never heard of the concept of automated unit tests.


Unit Testing’s impact on maintaining existing developments

If someone were to ask “what is it exactly that programmers do?” after the swearing and derogatory comments died down the answer would probably come back as “they write new computer programs”. That sounds correct but anyone who has spent any time at all programming would realize the correct answer is “a programmer spend 5% of their time writing new programs (the interesting bit) and 95% of their time fixing bugs and enhancing existing programs”.



Development time vs Maintenance time over total life cycle

The development manager at our company was amazed to hear this, he thought I had made this up after being hit on the head or something, and only after every programmer on the team voiced their agreement did he come to the conclusion this might possibly be true.


A huge debate raged about this on the internet – people were saying that if you spend 95% of your time fixing existing programs then it must mean the programs were really badly written in the first place.


I used the analogy of the SAP HR module – every year in every country the governments change the laws and taxes governing payroll, and SAP has to modify their HR / Payroll programs to reflect the legal changes. It does not matter if the program was written badly or well – the law is the law and SAP has to change these programs, every year, forever. Thus, over a (say) 20 year period the percentage of maintenance effort as opposed to the effort of originally writing the programs climbs to near 100%.


Not everything changes that much, but we have found that any custom program in heavy use is subject to a non-stop stream of enhancement requests from the users. No-one is ever content – it is human nature and good job too, otherwise as programmers we would be out of a job – and so it could be argued the only reason you are NOT getting lots of requests to add new features to any given program is because no-one is using it.


If you accept that you will spend the vast bulk of your working life maintaining existing programs, then your main day to day problem becomes this – how to change an existing program that works perfectly without breaking it.


That’s where the unit test framework comes in – traditionally you change one area and then break other areas, and either people have to manually test the vast array of different things the program does to ensure nothing has broken, or the end users find out in production, and you have to spend hours debugging to find out what in the world went wrong.


Nothing is ever a 100% silver bullet, but with automated unit tests you can see if any area of the program unrelated to your change has broken, five seconds after making your new change.


The argument is that the amount of time saved on maintenance over the entire lifecycle of the program more than outweighs the extra time needed at the start. The problem is that accepting this involves thinking in the medium to long term instead of just the immediate short term, and we seem to be living in a short term focused world.


It might be that you are a start-up and if the program is not finished really quickly then the company will go belly up and there will not be a medium or long term to worry about, in which case you might think the whole argument would fall on its face. That brings me to my second argument against test driven development taking too long.


Unit Testing’s impact on new developments

Traditionally if you had a really large development, you could only be sure it was working properly when you had finished a large chunk of it, and were then able to run it in the development environment yourself, doing what you end user was supposed to do and seeing what happened. Usually a short dump was the result, or all sorts of weird results, certainly nothing like what you were expecting.


The test driven development methodology turns this on its head – by the time you get to that stage you have a big bunch of tests covering every line of code you have written, so if something is wrong you will have found out and fixed it long before the stage where you try and simulate what the end user would do.

A lot of the time the development system has no meaningful data, or is not hooked up to an external system, so you wait till the program is in QA before you can do a meaningful test, then you (Or the testers) find the problem, and you fix it in development and have to move it to QA to try again. If you could resolve a lot of those problems before the program got moved to QA you would solve a tremendous amount of time.


So my argument would be – by writing twice as much code you actually get a working product (program) out of the door faster. That may sound difficult to believe but all you have to do is try this approach once and see if what is descried above is true or not. I would hope you would be pleasantly surprised.


Code Quality Street

If the third chapter was going to be on the sort of dynamic testing that is represented by Unit Tests, then the fourth chapter would cover static code checks.

During upgrades SAP are always telling us to get rid of as much custom code as we can – that is primarily because so much custom code never gets used after a very short while, but this can be perceived as an attack on the quality of us “customer” programmers.

It is easy as a non-SAP developer to get all offended by this, especially since standard SAP code is 100% visible and sometimes schoolboy errors are spotted by us “customers” which then get corrected by OSS notes - leading to the observation “people who live in glass houses should not throw stones”.

SAP do have a point however, many companies have got into serious trouble over custom code quality, the reason is unclear but possibly this is down to the fact that a lot of programmers started without any formal training in ABAP (I am an example) because they knew other programming languages, or because they were experts in other areas of SAP (or even the business) and migrated to ABAP programming, or in my case because I was in the right place at the right time.


A Code Inspector Calls

We are all familiar with static code check tools like the extended syntax check and the code inspector, but do you ever find that some of your developers either can’t be bothered and/or think the whole idea is a waste of time?

I once recall being told by a programmer that a gigantic program was maintained by the whole programming team, and the person telling me the story got to make a change about every four months. After they had made their change they did a SLIN/SCI exercise and found dozens of warnings and errors that had popped up over the intervening period when other programmers who did not use the checks had made changes. The icing on the cake was that the programmer who did use the code inspector was not allowed to fix the other problems because they did not relate to the change at hand.


SAP had clearly thought about this sort of situation and as a result the ABAP Test Cockpit was born, which became the subject of my fourth chapter. A lot of people find it difficult to get their head around what this actually is and what the difference between the ATC and a code inspector with more checks is.

As mentioned just now, some developers don’t bother with the static code check tools. They sometimes justify that by saying that those tools can come up with so many false positive errors that you can’t see the wood from the trees.

Pragma – we’re all Crazy Now!

You may have seen the t-shirts where you have the familiar picture of a monkey on all fours behind a monkey walking on his hind legs following a Neanderthal behind a human who then turns round and says “you lot - stop following me!”


That was all about evolution, and in regard to false positive errors SAP’s handling of these has evolved from “Pseudo Comments” via “Pragmas” to “exemptions”. All three follow the same premise but become more informative each time.


With a “pseudo comment” in the code the warning/error went away but all a later reader of the code knew was that the developer thought this was not a real error. The practice of some developers to use the technique to suppress every single reported error did not help matters much either.


With “pragmas” you could have a real comment (on the same line) after the pragma to say why the error is being suppressed. That was a big step forward, and with exemptions (such as you find in the ATC) you can write a war and peace length explanation as to why this is not a real error.


Big Brother is Watching YOU

The ATC is based on the idea of some sort of “Quality Manager” with horns and fangs who has to keep the programmers in line by beating them with a stick every time they make one their numerous mistakes.

This is the so called “four eyes” principal where a different person to the developer reviews the code for correctness, and is all well and good, but a proper “peer review” system where another programmer has to check the code before the transport gets released is better in my opinion.


That may be more manual but it keeps the development team informed as to what their colleagues are doing, and less experienced programmers can learn from more experienced ones. A peer review can involves using the code inspector, just to make sure everyone is using it.


Naturally there is nothing against doing both peer reviews and having the SAP recommended ATC Quality Manager / Demon with a Pitchfork approach, as long as the Quality Manager actually knows something about programming, hopefully all the Quality Manager would have to do is review the exemptions as any real errors would have been picked up by


·         The developer doing their own ATC checks on their own objects in development

·         Peer Reviews

·         The transport system displaying warnings and errors before releasing the transport to test


Nonetheless having a good explanation of false positives in the SAP system itself can only be a good thing, as it stops someone coming along later and trying to correct the “error”.


To Be Continued

To end with the same paragraph as before, in subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.

Cheersy Cheers







Horst Keller

ABAP Obfuscation Riddle

Posted by Horst Keller Apr 10, 2015

Tobias Trapp wants to start an ABAP obfuscation contest.


For warming up a small riddle:







This program is syntactically correct (as of 7.40, SP08).



Now tell me how that?


I was in the process of responding to Christian Drumm's excellent blog on Functional Programming in ABAP, when I realised that my mental ramblings should really be put into a blog (or perhaps more of a brain dump).


Please read Christian's post for the context of the following comments...


I must say that over the last few years, I've somewhat lost touch with the latest language developments in ABAP, so its nice to see that in a 7.40 system, ABAP has these additional features and that they're heading in the functional direction.


However, it does beg the obvious question though - why didn't ABAP have these features 20 years ago?  But anyway, they're here now, and that's a good thing.


Real Functional Programming in ABAP?

Well, yes but not entirely.

Until ABAP is able to treat a function as a 1st Class Citizen, then only partial progress can be made towards making ABAP a true functional programming language.  For those who are not sure, a "1st Class Citizen" is any object that can be created and deleted dynamically, can be passed as a parameter to a function or subroutine, and can be passed as the return value from a function.  An ABAP function module does not meet all of these criteria.

The underlying principle of functional programming is not simply being able to use the map or reduce functions, but rather in the fact that the software is designed using the systematic application of referential transparency.


Adding various operators like COND, WHEN and LET certainly allows solutions to be programmed in a more concise, functional style; but this only permits an occasional, ad hoc use of referential transparency, rather than its systematic application.  Nonetheless, these additions to ABAP are a good step in the right direction and I'm sure people will find it very useful.


I'm sure the ABAP language developers are well aware of the need to create a unit of code that behaves as a 1st class citizen, and have already been thinking long and hard about whether and how such changes could be implemented.


Borrowing from Clojure?

Looking at the syntax and implementation concept behind the new ABAP operators like COND, WHEN and LET, they look very much like they've been lifted directly out of Clojure - which is certainly not a bad thing!

We just need to add operators like DEFN and FN and ABAP will have made the switch - but see the comments above about ABAP functions and 1st class citizens...


Functional vs Imperative Programming in General

I have been a long time advocate of the functional programming paradigm, and at the risk of sounding like a broken record, have been trying to convince people within not just SAP, but also the business programming world that this paradigm needs to be treated as a viable and beneficial development option.


However, the blunt fact of the matter is that there tends to be a large cultural divide between the functional and imperative programming camps.


I may use a little bit of exaggeration here, but this is only to highlight the polarities that exist between these two camps.  Each camp tends to view the other with suspicion on the basis that "we have the correct priorities" and that "they are focused on all the wrong things".


The business programming world (the imperative camp) is focused on writing software as a means to make money.  Yes, yes, they want to solve customer problems, but in a world governed by a market driven economy, at the end of the day, the share price is king.


Over in the functional camp, this programming paradigm is presented as an implementation of Alonzo Church's Lambda Calculus.  Here, the Platonic concept of "pure intellectual thought" reaches one of its pinnacles.  Pure functional programming languages such as Haskell have created rigorous implementations of this mathematical concept, and the result is a problem solving technique that, after you have first accepted the very restrictive modus operandi imposed by all functions needing to be pure (that is, they never have side effects), can produce solutions whose correctness can be determined with a very high degree of certainty.


Whilst there is far more to the situation than simply "making money" and "functional purity", when you talk to people from these two camps about their differences, the conversation tends to come back to the importance of one or other of these priorities.


Why are the two camps so polarised?

Over in the Functional Camp

A large part of the polarisation here comes from the fact that many universities still teach functional programming as just an implementation of lambda calculus; therefore, if you're not interested in mathematics, functional programming is of little use to you.


Having said that, universities are gradually seeing the need to change this approach.  I've spoken with Prof Kevin Hammond of St Andrew's University in Scotland about this, and he is actively working to join up the worlds of business programming and functional programming.  However in general, functional programming is not really presented as a viable solution to the practical problems seen in the business world - such as creating warehouse stock management systems or running your accounting system.  Instead, students of functional programming are often told to write their own language interpreter that outputs an abstract syntax tree, or to design an algorithm that decides if a graph tour can be performed in which each edge is visited only once.


That's all well and good, but it doesn't prepare students for work in the business software world.  Consequently many students are implicitly taught to exclude this development paradigm as a viable option in the hard-nosed world of business (where success is measured solely in financial terms (Is this a good thing? Discuss))


For those software developers who do enjoy the supposed purity of mathematical thought, there is often the sense that being able to write in the functional programming style makes one intellectually superior to the lowly imperative programmers.


Well, there's a small element of truth to this argument, but a larger element of blindness caused by intellectual snobbery.  This blindness then causes otherwise intelligent people to suggest that all business software is written by money-grubbing companies interested only in meeting their greedy revenue targets. (Yes, one functional programmer I spoke to a while back implied that SAP's market dominance meant I worked for "The Great Satan")


Meanwhile, back in Gotham City... uh sorry, The Imperative Camp

From the imperative side of things, this programming paradigm is easier to pick up than functional programming in the same way that the mechanical engineering solution to a problem is "visible" (you can see wheels and gears turning, drive shafts spinning and valves operating) and the electrical engineering solution to the same problem is "invisible" (you can see the resistors, capacitors and diodes on a circuit board, but you can't see the current flowing through those components).


There also tends to be the overriding attitude that "time is money"; therefore, software must be pushed out the door as fast as possible to avoid loosing (the perception of) market share.  It is certainly true that from time to time, software companies push software out the door way too early (this is the "if it compiles, ship it" approach), but this is generally avoided.


Similarly, the business programming world must avoid the smugness of thinking that they deal with the "real" world, and dismiss the functional crowd as just a bunch of intellectual snobs who live an abstract world completely divorced from, and irrelevant to anything down here on terra firma.


Again, there's a small element of truth here, but a larger element of blindness caused by thinking that success is measured solely in financial terms.


Can the two camps co-exist?

Yes, certainly.  And I believe the first step that must be taken is to remove the sectarian boundaries that been erected to protect the supposed rightness of each camp's particular point of view.


Both sides can benefit from each other by exchanging techniques that they have found to be successful.


On the imperative side, the software needs to meet the customer's needs at a price the market is willing to pay.  When a company does this well, that company makes money.  But making money is by no means the sole measure of success.


And on the functional side, the use of functional programming techniques often allows for a more concise definition of the solution. Also the correctness of that solution can typically be determined with a higher degree of certainty than is possible with the imperative approach; however, the rigour with which the policy of functional purity is applied should not override the other factors inherent to running a business.


The division between the camps is certainly less than it was 10 years ago, but it still tends to be true (at the macroscopic level at least) that when these two camps come into contact, they generally regard each other with suspicion, throw a few shallow, poorly considered insults over the fence, then as they leave, they congratulate themselves for having the "correct" approach to software development and get back to business as usual.


However, I'm happy to say that developers on the imperative side of things are starting to look more closely at the functional way of doing things, and that the universities are trying to tailor their functional programming courses to include business software as a target problem domain.


Unfortunately, there are some other factors that reinforce this cultural divide.

Functional Programming at SAP

SAP is already a highly successful software company, and none of that success is attributable to coding written using a functional programming language, or even the functional programming paradigm.  So this leads to two further problems; and I must stress that these problem are by no means unique to SAP, but apply generally to all fields where expertise has lead to success:


  1. The "inertia of expertise" problem.  This is a well known phenomenon in which genuine expertise in a subject has on the one hand, produced genuine break throughs and resulted in the creation of valuable and highly successful solutions; yet on the other hand, that very success creates a large mental inertia that makes it very hard for experts to seriously consider the possibility that other, equally viable solutions may also exist.
  2. The "innovator's dilemma".  This is also a well known problem that can be thought of as the flip side of the "inertia of expertise" problem.   This is where it is very difficult (or even impossible) to innovate in an environment within which complex problems have already been solved, and solved effectively.  Existing ABAP systems contain many highly successful solutions for solving business problems, so the overriding mindset is "if it ain't broke, don't fix it".  The resistance to the use of innovative languages is compounded by the fact that the solution created by the innovative approach will often not be any better than the existing solution.  Thus the person trying to introduce a new way of solving an old problem is often viewed as someone who "doesn't really get it" because "that problem has already been solved - move on!".  This makes indifference to innovation appear entirely plausible.


Having said that, the functional programming language R is used within the HANA system, but at the moment there are no tools by which a customer or partner could extend or develop their own R procedures.


I strongly believe that if the business software world (SAP) is to survive the next major phase shift in computing technology (Cloud computing), then at least two things need to change.  By taking the perspective of an ABAP system, we could rather loosely describe these as "changes from within" and "changes from without".


Changes from within (The Natural Growth Approach)

Adjust the ABAP programming language so that true functional programming can be performed.  This will require ABAP to be able to handle functions as 1st class citizens; however, since I am not an ABAP language developer, I don't know whether this proposal is even viable.


Assuming that such a change is viable, then the syntax that has already been used by the new COND, WHEN and LET operators could be extended to create a language that looks and behaves very much like Clojure.  (Though there are other much deeper issues as stake here, particularly when handling concurrency).


However, this change (assuming its even possible) will be the slow option because it relies on the natural growth of ABAP software from within the developing system.  In realistic terms, natural growth like this takes 3 to 5 years to become an integral part of the system.


Changes from without (The Innovative Approach)

Due to the "Innovator's Dilemma", the adoption of functional programming as a way of life cannot take hold in any area where mature solutions already exist.  Therefore, new programming paradigms must occupy new problem domains.  This avoids the plausible accusation of trying to re-invent the wheel.


I believe the area where this approach has the most potential is in the Internet of Things.  This is a wide open field in which mature solutions do not yet exist.  Therefore, the possibilities exist to create cloud-based software based on the functional programming paradigm that can handle the huge volume of data and connections demanded by a connected world.


I further believe this paradigm shift is absolutely necessary for the following reason:


To survive the IoT, we must be highly scalable and be able to support massive levels of concurrency

Sorry to burst anyone's bubble here, but if you think that concurrency and scalability are topics that can be handled after you've got your business app up and running, then you'll be in for a very nasty surprise come go live...


Scalability can generally be solved by throwing more hardware at the problem (up to certain limits of course), but concurrency is a much thornier problem.  Concurrency poses a different type of challenge because it requires us to fundamentally change the way we write software.  But there is a natural human resistance to change - especially if we have existing solutions that have worked well in the past.  Sorry, but yesterday's imperative solutions will not solve tomorrow's concurrency problems.


Concurrency is of fundamental importance to any business scenario that expects to perform real-time communication with the number client devices expected with a realistic IoT solution.  These devices could either be mobile smart phones or static devices such as pieces of machinery on a production line or low energy Bluetooth beacons.


The exponential growth in computing device numbers means that any business involved in the IoT will, in the reasonably near future, have to handle in excess of a million concurrent connections as its normal runtime state, rather than as a peak-load exception.  From a database perspective, a HANA system can handle the number of queries generated by such levels of concurrency, but how about all the intermediate systems that connect the outside world with your backend HANA system?


A totally new approach is needed for the communication interface between the SAP world and the gazillions of devices all screaming for a timely response from the backend business system.  Concurrency is an area where functional programming can provide a solution with far less development effort than would be required if an imperative language were used.


Therefore, it is of the greatest importance to choose both a programming language and paradigm that will contribute towards the solution and not become part of the problem.  Such a language must not contain any unnecessary complexity, for as Tony Hoare has said:


"If our basic tool, the language in which we design
and code our programs, is also complicated,
the language itself becomes part of the problem
rather than part of its solution."


Ignore this advice at your peril...


Therefore when writing a communication interface for the IoT, it makes perfect sense (to me at least) to choose a language in which concurrency is a natural feature, rather than an additional construct that must be implemented in that language.  Here, the obvious language choices would be either Erlang or Clojure - both of which are functional programming languages and are both very good at concurrency.


For the specific task of an IoT communication hub, my first choice would be Erlang due to the fact that this language is already battle-hardened due to having been used in the Telecoms industry for over two decades.  Among other things, Erlang was specifically designed to handle the massive levels of concurrency experienced by a telecoms switch, so this makes it an ideal candidate.


If you're still sceptical about the commercial viability of a language like Er...whats-it-called (Erlang), then consider that WhatsApp is written entirely in Erlang and they regularly handle more than 200,000 messages per second.  See here for reviews and technical details.


Also Massively Multiplayer Online games such as the different Call of Duty variants all use Erlang servers to handle the client-to-client transfer of game state information.


Whilst the idea of using a niche language like Erlang for handling massive levels of communication concurrency might scare you, it really is the best choice for this particular problem domain.


However, if you want a more general purpose language that runs on the more familiar environment of a Java Virtual Machine, then Clojure would be a more comfortable choice.  This language is also very good at handling concurrency and since it compiles down to Java byte code, can easily be understood by experienced Java developers.


The choice to use either of the languages mentioned here (or any functional programming language for that matter - Haskell, Scala, OCaml etc) requires a willingness to move outside our comfort zone.  Generally speaking, this willingness is not always forthcoming until we have first experienced the failure that comes from thinking old solutions will solve new problems (I.E. our persistent attempts to rationalise not having to move outside our comfort zone).


The bottom line here is that the imperative programming paradigm cannot solve the concurrency issues raised by having to support massive levels of simultaneous connections.  If you don't believe me, go away and write a solution in <pick_your_favourite_imperative_programming_language> and see how much scalability you can practically achieve, and how robust that solution actually is.  After this painful experience of blood, sweat and tears, I venture to say you will be more willing to consider a solution based on the functional programming paradigm. 



So what? What does this have to do with SAP software?

With the whole computing industry moving towards Cloud-based solutions, providing massively scalable, centralised communication access to your backend system/s is fast becoming a make-or-break topic.


The potential exists to use something like a Cloud Foundry Custom Buildpack to implement an IoT communication solution based on any programming language you like.  This in turn could be used to communicate with a HANA system...


The field is wide open here.  Let's seize this opportunity to create new solutions for the new environment, and not make the mistake of thinking that our comfortable, old solutions will be suitable - they won't.


Chris W


The idea to write a blog exploring the possibilities of functional programming in ABAP first came to my mind when I read Horst Keller's blogs on ABAP Language News for Release 7.40, SP08. Especially the REDUCE operator that is part of the new iterator expressions ( ABAP News for 7.40, SP08 - FOR Expressions) immediately reminded me of the reduce function in Clojure. As I was learning different function languages in my spare time anyway I started to try to implement some of the examples used in the functional programming tutorial in ABAP.  After a twitter conversation with Uwe Fetzer and Fred Verheul (see Uwe's blog Rosetta Code and ABAP) I decided to collect some of the code examples I created so far and share them in a blog.


A (very, very) short introduction to functional programming

Functional programming is one of the oldest programming paradigms, dating back as far as the late 1950s (cf. Functional programming - Wikipedia). Despite this long history, functional programming never gained widespread acceptance (compared to e.g. C or C++). However, in recent years there has been a growing interest in functional programming and functional programming languages again.

For example, the RedMonk Programming Language Ranking for January 2015 list with Scala (The Scala Programming Language), Haskell (Haskell Language) and Clojure (Clojure - home) three functional languages among the top 20 programming languages (cf. image below). In addition functional extensions to popular programming languages like Java have been developed (cf. Functional Java  and How Functional is Java 8?).


There are numerous articles and discussions available on the internet regarding the advantages and/or disadvantages of function programming (e.g. Functional thinking: Why functional programming is on the rise and Advantages Of Functional Programming). In my opinion there are two key advantages that lead to the current interest in functional programming. Firstly, the possibility to develop specific abstractions is an integrated part of each functional language. Secondly, the property of functional languages of being side effect free simplifies the development of parallel programs.



I don't advocate the code examples I will show below for productive usage (at least not yet). With all the new language features getting added to the ABAP language Tobias Trapp's advice "Don't try to be smart. Be smart." is more valid then ever. In the context of what I'll show below I would paraphrase Tobias's statement as "Just because something is possible doesn't mean it is a good idea to do it."

Furthermore, it is important to keep in mind that ABAP is not (and most likely will never be) a functional programming language. In ABAP, it is not possible to pass functions as arguments to other functions. The ABAP compiler and runtime currently lack important features (e.g. tail call optimization, cf. Tail call - Wikipedia or What Is Tail Call Optimization? - Stack Overflow) of runtime engines for functional languages. Consequently, functional programming in ABAP is limited to certain cases. The examples shown below might also only run very slowly or only work for small input values compared to an imperative or object-oriented implementation.

Nevertheless, it is in my opinion quite interesting to see what is possible with the current version of the ABAP language.


Functional ABAP examples

In the following sections I'll show some quasi functional implementations of different algorithms in ABAP. Note that all code examples in this blog a screen shots. There reason for this is that no syntax highlighting for ABAP is available. In order to simplify the usage of the code snippets is also create a pastie (Pastie) for each snippet and added a link to it below each screen shot.


Simple start

As a simple start to functional programming in ABAP let's calculate the sum and the product of the values of an internal table. The code snippet below  shows how this would be implemented in ABAP without the usage of any of the new language features. To calculate the sum and the product one would simply loop through the internal table and store the calculation result in a temporary variable. It would of course be possible to calculate the sum and the product using a single loop. However, I used two loops to make the similarity to the functional implantation more obvious.

2015-04-07 21_49_40-ABAP - Programm ZCD_SUM_AND_PRODUCT [IFD] - Inaktiv, Gesperrt - IFD_100_drumm_en.png

#10078959 - Pastie - zcd_sum_and_product


Using the reduce table expression calculating the sum and the product can also be implemented as shown below.

2015-04-07 21_31_09-ABAP - Programm ZCD_REDUCE_TEST [IFD] - Aktiv - IFD_100_drumm_en [IFD, 100, DRUM.png

#10078938 - Pastie - zcd_reduce_test


Note that in this case there is not much difference with respect to the code amount between the two solutions. In fact the classical solution using only one loop would be shorter than the functional one. The key advantage of the REDUCE operator is that it can be combined with other operators to create more expressive expressions.



The first a little more advanced algorithm I implemented using a functional paradigm in ABAP is the Fizz Buzz Test. The Fizz Buzz Test is a simple programming exercise I stated to use in job interviews for developers lately. Many implementations of the Fizz Buzz Test in different languages are documented on rosettacode (http://rosettacode.org/wiki/FizzBuzz). The goal of this test is to:

"Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”."

The code snippet below shows the implementation of the Fizz Buzz Test in "normal" ABAP without the usage of any of the new ABAP features. In lines 6 to 9 an internal table is initialized with the numbers 1 to 100. After that the lines 11 to 22 show the core implementation of the FIZZ BUZZ Test.

2015-04-06 20_43_34-ABAP - Programm ZCD_FIZZ_BUZZ [IFD] - Aktiv, Gesperrt - IFD_100_drumm_en - Eclip.png

#10076806 - Pastie - zcd_fizz_buzz

An alternative implementation of of the Fizz Buzz Test using functional ABAP is shown below. It is immediately obvious that the second implementation is much more concise then the previous one. The implementation consists of a constructor expression for a string table (line 4). Using the FOR iterator expression the values form 1 to 100 are passed to a COND expression. The COND expressions uses a LET expression to create two local variables r3 and r5. r3 and r5 store the result of i MOD 3 and i MOD 5 respectively. Finally, the WHEN and ELSE clauses in lines 8 to 11 implement the core logic of the Fizz Buzz Test.

Besides being more concise, the functional implementation is in my opinion a lot cleaner then the classical one.

2015-04-06 20_44_40-ABAP - Programm ZCD_FUNCTIONAL_ABAP [IFD] - Aktiv, Gesperrt - IFD_100_drumm_en -.png

#10076802 - Pastie - zcd_functional_fizz_buzz



Next I implemented the factorial function. The factorial of a positive integer n is defined as the product of the sequence n, n-1, n-2, ...1. Furthermore, the factorial of 0 is defined as being 1. Using the the COND and the REDUCE operator the factorial function can be implemented as shown below. This functional implementation of the factorial function nicely resembles the definition. Therefore the functional implementation is in my opinion simpler to understand compared to the classical implementation.

Note, that the COND operator is not required in the implementation. The REDUCE operator would also handle the special case of 0 correctly. Nevertheless, I included the COND operator in order to have the function definition more clearly expressed in the code.

2015-04-07 22_28_27-ABAP - Programm ZCD_FUNCTIONAL_FACTORIAL [IFD] - Aktiv - IFD_100_drumm_en - Ecli.png

#10079013 - Pastie - zcd_functional_factorial


Fibonacci Sequence

The last algorithm I implemented using the functional operators is the Fibonacci sequence. I used a recursive approach for this implementation. The COND operator is used to represent the definition of the Fibonacci numbers (lines 13 - 18). In order to implement the recursive call I used a LET expression to invoke the Fibonacci function recursively (line 18). The two auxiliary variables x and y store the last and second to last element to the Fibonacci sequence for n-1 (lines 19 and 20). Finally the result of adding x and y is concatenated with the elements of the Fibonacci sequence for n-1 and returned (line 22).

2015-04-06 21_28_21-ABAP - Programm ZCD_FUNCTIONAL_ABAP [IFD] - Aktiv - IFD_100_drumm_en - Eclipse.png

#10076876 - Pastie - zcd_functional_fibonacci


What's next?

As stated in the introduction it is quite interesting to see what is possible with the new ABAP features. However, there are still some open questions:


1. Performance

In the examples above I didn't compare the performance of the classical ABAP solutions to the functional ones. It would be quite interesting to see how the different solutions compare with respect to performance. This might be the topic for a future blog post.


2. Productive usage scenarios

Another open question is which productive usage scenarios are suitable to apply the functional ABAP features. The examples above are implementation of mathematical algorithm. However, productive ABAP code usually deals with the handling of business objects (e.g. business partners). The first usage scenario that came to my mind is the usage of the FILTER operator (not shown in the examples above, cf.FILTER expression) to filter an internal table after some select (e.g. select from BUT000 and the filter the business partner type). However, It would be interesting to find further usage scenarios in which a functional solution offer advantages over the classical one.


3. Future ABAP versions

It will be really interesting to see what future ABAP version will offer. Maybe ABAP will in the future offer some functional features that are currently still missing.


Finally, I'd be interested to hear your opinion of the code examples I've shown above. Do you think this is something that should be used in productive code?


H.M Hofman

Join types SAP queries

Posted by H.M Hofman Apr 7, 2015

Quickviewer / Query – Joining tables.

There are 2 ways of joining tables in SAP: Inner and outer joins.

If you have to following 2 tables, that you want to join, you see that there are 2 matching records: 11 and 12.


Table 1



Table 2


Using this table to explain the matter:



1: Inner join


This is a 1:1 relation. In short, this will only show records when the data is available in both tables.

Using an inner join, you will have a better performance. It is advisable to use this when possible.


When joining these 2 tables, the data that is available in both tables is 11 and 12. This is what you will get as a result.


Table 1Table 2


2: outer Join


This is a 1:n relation. In short, this will show all records of the left table in the join, regardless if it is available in the joined table.


When joining these 2 tables, it will show all data of Table 1. Only there where there is a match, it will show the data of Table 2.


Table 1Table 2




you want to show all material information using MARA, and see wich materials are available in a storage location (MARD).


Inner Join:

Create a query using a Table Join.


Afbeelding 1.png


In the join, select MARA and MARD


Afbeelding 2.png


Note the connecting line, this shows you have an inner join.


Now click back and select the fields you want to use for selection and  output.

For this example, I have selected as selection and output: MARA-MATNR and MARD-WERKS.


Afbeelding 3.png


I have 2 material numbers: 51 and 801.  Material 51 is not available in the MARD table.

The result from running the report is that only for 801 the results will be shown (inner join only shows data that is available in both tables):


Afbeelding 4.png


Outer Join:

I go back to the data join, and change the join to a outer join.


For this, right-click on the connecting line and select Left Outer Join


Afbeelding 5.png


Note the connecting line is now showing it is an outer join.


When now executing the report with the same selection, this is the result:


Afbeelding 6.png



With a left outer join, all data from the left table will be shown and only there where this data is also available in the right table it will be shown.

In this example, material 51 is available in the left table (MARA) so the material number is listed. Since there is no info in the MARD, this info will remain empty.


Example 2:


Inner join preferred:


You have created a new Availability check and want to see all materials where (still) the old checking group is used.

For this, the table with the checking groups is TMVF. The master data is stored in MARC.

Since you only want to see the data that is available in both tables, you can use an inner join.


For the left table, you pick TMVF, since this is where you want to make the most important selection for your report.

The right table then is the MARC table.


Afbeelding 1.png


You select the MTVFP field and MATNR and WERKS as both input and output fields.


Now, to show all materials with checking group 02:


Afbeelding 2.pngAfbeelding 3.png


Outer join:

You have a list of invoices, some of them might be in an invoice list. You want to see all invoices and when they are in an invoice list, the IL number should be shown.


Left table is the VBRK. Right table is the VBRL.


Afbeelding 4.png


Note that I have changed the join to VBELN_VF and made it a Left Outer Join.


Now I select VBELN from VBRK and VBELN from VBRL as input and output.


Afbeelding 5.png


Afbeelding 6.png



If I want to add more info about the invoice list, I need to also use the VBRK table. But I can only use this table once.

To be able to add info a second time from VBRK, I have to create an alias:


Go to the join and click on the Alias button. In the pop-up, click on create.

Afbeelding 7.png


Fill in the table name, and think of a name for your alias. Accept your input.

Now insert the newly created 'alias' table and use an inner join from VBRL to the alias (outer join can only be used once in a dataflow):


Afbeelding 8.png


Now when you select the billing type as output from VBRK and the alias, you will get the following result:


Afbeelding 9.png


As you can see, the outer join is ignored because of the inner join further to the right. When using a right outer join, it should be the last table in the flow.


What’s that coming over the hill? Is it a Monster? IS IT A MONSTER?


Writing a Book for SAP Press – Part Two

Table of Contents




ABAP 740

To Be Continued

It’s Alive – In the City of Light

Simple things please simple minds, so I was delighted by the positive response to my first blog about writing a book for SAP Press, a book about monsters (and the latest ABAP features).



In that blog I talked about the process of getting access to a trial SAP system, and some thinking about what type of content to put in the book. Once I had scribbled down by list of topics on the back of an envelope, which co-incidentally is the same medium that is used for storing technical specifications for ABAP programs, then the next question was how to arrange those topics.

Turn Around Bright Eyes

When connecting to the trial SAP 740 HANA system you log on by means of a remote desktop session. On that remote desktop is an SAP GUI logon pad as might be expected, but also an icon to call up Eclipse. The idea is to open the Eclipse system, not use the SAP logon pad, and do your programming from Eclipse.

Now, Eclipse is not everyone’s cup of tea – comments made in regard to my last blog described programming in Eclipse as “programming with broken fingers” and no doubt there are far better equivalent tools out there, but that is rather like discussing which airline is best with someone who refuses to fly.

In other words there seemed to be a lot of people who would rather die than stop using SE80. So as a first step talking about Eclipse seemed a good idea. If they don’t accept the idea that an alternative to SE80 is even possible / desirable then the other tools will not get a look in, and I bet some conservative development managers would not be comfortable with having their team move to a development environment that was not endorsed by SAP.

I try to keep an open mind, so some considerable time before Eclipse became available for ABAP I installed Eclipse to see what it was like and ran through all the tutorials – which were all to do with Java naturally – and was very impressed.

Even at that point Eclipse was not just for Java – it could be used to develop in a large number of languages, for example Ada, C, C++, COBOL, Fortran, Haskell, JavaScript, Lasso, Natural, Perl, PHP, Prolog, Python, R, Ruby, Scala, Avengers Assembler, Clojure, Groovy, Scheme, and Bang Bang Thank You Erlang. Given the size of that list it would seem that some years later when support for ABAP was added it was just a case of another member joining the club.

So, I put Eclipse in as the first chapter on the grounds that what development environment you use would seem to be the first step in any programming project. I would try to look for ways in which you could do useful things in Eclipse whilst writing code which you could not normally do in an SE80 environment.

I would also note that an open source IDE such as Eclipse evolves far faster than an SAP system. Already since the book was finished there have been two minor releases of the SAP tools and I have started making a list of new features in case I get asked to write a second edition of the book in 3 years’ time.

An open source IDE might evolve faster, but in fact the whole of the SAP technology stack – every single subject I write about in the book - is evolving at a ridiculous pace. Most likely in 3 years’ time so much will have changed the book will need a total re-write, which is fine by me.

The Bash Street Kids – featuring Plug-In

American songwriter Steve Earle once sang a song called “I ain’t ever satisfied” which is what gives us IT types job security – not only are the end users never happy, but neither are the developer community.

Due to this fact I was hoping to try to end each chapter which dealt with an imperfect new tool (and how many are going to be perfect? Oh yes that’s right, none of them) with ways that it is possible to improve the functionality that you get “out of the box”.

In the case of Eclipse adding new functionality takes the form of “user defined plug ins”.

As an example, if I found a boring repetitive task that I had to do every day in the ABAP workbench I would write a tool to help me, but that would be my tool and I could not add it into the standard SE80 menu without the sort of modification to the core system we try to avoid, so even my colleagues inside the company would find it difficult to re-use this, let alone the whole world.

Eclipse works off the principle of being able to add such tools as plug-ins – the whole ABAP in Eclipse framework is such a plug-in. So I wanted to find an example of where there was a gap in the ABAP workbench and someone had added a plug-in to ABAP in Eclipse to address that gap.

I am a Universal Model, if you know what I mean

When I first started getting interested in object orientated programming someone said to me “before you do anything, learn UML”. So I found and read a corker of a book called “UML Distilled” by Martin Fowler.



My favourite quote is as follows:-

“If someone came up to you in a dark alley and said ‘psst – wanna see a UML diagram?’ it would probably be a class diagram”

We have two programming teams where I work – the “yellow shirts” who program in ABAP and the “pink shirts” who program in what traditional ABAP people would consider weird and obscure languages like Angular JavaScript.

When I walked past this enemy territory I noticed that they had pinned to the wall above their desks posters full of square boxes all connected with arrows. It turns out those were UML diagrams, literally a map of whatever application they were creating.

It seems the idea in OO programming is to draw up a diagram showing what classes you need and how they inter-relate, and what methods and attributes such classes have before you start programming. Moreover, such UML diagrams can be created with VISIO like tools within IDE’s like Eclipse, and then for languages like Java and Avengers Assembler at the press of a button the system will generate skeletons of the classes and methods and method signatures for you.

Then you are supposed to write unit tests for these skeleton classes before putting any real code in them – but I am getting ahead of myself.

So, if that is what a real OO programmer does, and I want to act like one to see what it is like, then I would need something similar in ABAP. So if I could find an Eclipse plug-in that enables this functionality in ABAP (i.e. creating skeletons of ABAP classes and methods based on a diagram) that would be a wonderful example.

Hunting for the UML Snark

It doesn’t take much googling to find blogs about UML for ABAP. I found two almost at once, and I thought they were both talking about the same plug-in but in fact they were utterly different.

Now I don’t want to go into how to install these or how they work – as that is in the book – but I do want to thank the creators of both for the help they gave me, and to make sure people do not get as confused as I was at the start.

The problem is the name of both tools appears at first glance to be the same, which is why I thought there was only one.

UML2ABAP is the name of a product which you would have to pay for, from a French company called Obeo.

UMAP is an open source project, but just to confuse everybody, the web site for this is called UML2ABAP, and the open source project uses a lot of technology supplied by Obeo.

The company Obeo were kind enough to give me a trial edition of their product, for which I am grateful. I imagine they were very happy to have their product being mentioned in a book, though they only get a couple of paragraphs.

I also conversed via email with the inventor of the open source UMAP, Mathias Märker.

You are not my TYPE

One point that he mentioned I was meaning to put in the book but never got around to, so I will mention it here. UML is language independant, and you download whatever open source tool you can find to Eclipse or somewhere similar to create the diagrams.

Naturally since such tools that you use to create UML diagrams in the first place have never even heard of SAP, so when when someone writes a tool to convert the diagram into ABAP code they have a whacking get problem.

Creating classes and methods is easy enough, as is generating the names of the input and output pramters in the signatures. In languages like JavaScript you don;t TYPE a variable, it takes on the type of any value passed into it. However in ABAP world attributes and method parameters need a TYPE and how in the world does the conversion tool know how to TYPE such thing? For example you would manually type ID_SALES_ORDER TYPE VBELN but VBELN is 100% SAP specific.

Naturally it cannot, so the generated code in SAP comes out looking like:-




That is how the two tools deal with the problem i.e. by giving up in the face of the seemingly impossible. Then you would have to manually add the data type yourself.  According to Mathias in UMAP the workaround is in the UML diagram creation tool to create a package called “datatypes” and in there you can create UML elements of type “Data Type” and name them like standard SAP data elements e.g. PERNR or VBELN. Those you can then assign to your UML attributes (either class attributes or signature parameters) in the diagram you are building and when the conversion tool is called in your SAP System the generated code will have the attributes and parameters that are created TYPED with the corresponding data element.

I tried this myself to make sure and it works fine.

Language Timothy!

The limits of my language means the limits of my world.

-          Ludwig Wittgenstein

If the first step in programming is the development environment, and the next stpe is to generate skeletons of classes and what have you, then the next step is to fill up those skeletons .... with code! And what sort of code do we like?

  • ·         Morse Code
  • ·         The Spy who Came in from the Code
  • ·         ABAP Code

I thought I would go with the third one, and so therefore the next obvious subject to include was a chapter on the improvements in the ABAP language that came along in version 740 – what can only be described as a sea change. I can‘t stress that enough – going from 7.02 to 7.40 is an enormous boost.

Mind you since ABAP is backwards compatible, you can get away with writing things the same way you did in version 3.0 and everything will work fine, though the extended syntax check will – quite rightly - have a cow as Bart Simpson would say.

So, given the „we have always done it this way“ nature of some programmers, along with all the new 740 things I also included some features that came in with version 7.02 which I strongly suspected a lot of people did not know about, let alone use.

Obviously there is standard SAP online documentation for each new ABAP statement, but (a) IT people do not read documentation and (b) most of it is boring and (c) often such documentation does not appear related to the real world. It is difficult to grasp the idea when the examples use variables called A and B, when we are used to dealing with real world objects like sales orders and purchase orders. That is why at the SAP Architects and Developers conference in Sydney in 2014 Thomas Jung used all his own examples for each new feature.

However credit where credit is due – unless it is been censored by now, if you go on the internet looking for SAP online help. Once you have found the site take the path ABAP Keyword Documentation -> ABAP Reference -> Declarations -> Local Declarations in Expressions, and if you look at the example code for the LET expression then that may well win the award for the funniest example code in the history of SAP online help. Of course, now I have said that „they“ will probably remove it, and take out the author and shoot them.

The Man who Never Asked WHY?

I have a horrible habit of mixing the HOW with the WHY. What I mean by this is that when a new feature comes along 99% of the blogs and documentation are concerned with how to get whatever it is working technically. As to discussing whether using this shiny new feature is a good idea or not – that discussion never seems to get a look in.

The „how“ part of programming is always changing as technology evolves, the „why“ part is philosopical and so never changes. As part of the chapter on new ABAP language features I had included a discussion as to whether the new (much more condensed) syntax made the code less readable and how we can counteract this.

I was allowed to keep that in the book, though it got moved to an appendix. As time goes by I have started to wonder if I am a madman – thus far everyone I have asked says that mixing the WHY and the HOW is a no-no. The consensus seems to be that the two topics should not even be in the same book, let alone the same chapter. However to me it seems they go hand in hand.

As an example the other day I saw a series of blogs on SCN about the BUS framework for coding DYNPRO screens in an object orientated manner. That was very well written but focused solely on how to get this working. I did not spot anything about why using this framework was a Good Thing, though that may be coming along in a subsequent blog.

When trying to justify something as a Good Thing I don’t accept statements like „because it is object orientated“. I want an example of the bad way of doing things, and the good way, and it should be obvious that the good way makes things more resistant to change, or faster to develop, or some other benefit.

So when I was trying to write a book I wanted to say why these new tools were good, alongside the mechanics of how they worked. However due to the vast amount of content a lot of the WHY had to be cut in order to concentrate on the HOW.

That makes perfect sense, but just for my curiousity I would like to ask the floor – is it enough just to say how to make something work? Do the philosophical aspects have no place in SCN blogs or in „how to“ textbooks?

To Be Continued

In subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.

Cheersy Cheers







Filter Blog

By author:
By date:
By tag: