If you’re not already using ABAP Objects you’re chicken.

If you use them, I do hope you’re following the best practice of using class exceptions.

And if you’re using class exceptions you better understand the best way of using them, particularly the advantages of chaining them.

This said, here’s what brings us here today. In the post about chained exceptions I showed a way to get the text of the deepest exception in the chain by using a WHILE loop:

I’ve been using more and more references in ABAP.

I used to use REF TO only for classes but I’ve been finding more and more advantages in using them for other data types. But, just like in C++, care must be used when dealing with data references. Things can easily go very wrong.

In this article, I’ll try to show you how to use and how not to use REF TO DATA. Let’s start by an example of how not to do it.

Any object created in SAP must belong to a package.

Until recently, whenever I needed to create a program for a quick test I’d put it in the $TMP package. This way I was sure that it would never be transported to another system.

But sometimes I have the need to create stuff in the development system which, even though it should never be transported, should stay there forever. For example, development tools like ZSAPLINK and abapGit. But if we put everything under package $TMP it will soon be a big mess.

Every day I use more reference variables in ABAP. First I used REF TO just for classes but, as I become more familiarized with its advantages, I start using them more and more for data structures, instead of field-symbols.

But I recently found na unfortunate behavior of the following command:

INSERT wa INTO itbl REFERENCE INTO ref.

Let me give you some context before I complain about it.

If, when building a bridge, a civil engineer makes a mistake in one of the calculations, the bridge falls. But the bridge won’t fall alone. Most probably that engineer will also fall with it. He is accountable for what he did because he must sign his projects.

ABAP programmers don’t have that kind of problems.

[Guest post by Artur Moreira]

From ABAP version 7.4, SAP introduced the code pushdown concept, which means using more database for calculations (data aggregation, sums and previous calculations).

We’ve all sorted internal tables to use AT NEW on a LOOP. But starting from 7.40, we can use GROUP BY on LOOPs.

The ability to group by values based on expressions or even methods is great.

The grouping is done on the first LOOP and can be processed afterwards. Try running the code below and I bet you’ll be as impressed as I was.

Checkpoints is a very powerful ABAP framework which almost nobody uses. Why? Probably for the same reason hardly anyone listens to Sun Ra and knows that Frank Zappa has 102 albums. Because, even though really good, it’s obscure and not commercial. Checkpoints are, indeed, really good and not commercial. But they should be more like Mozart and the Beach Boys which are both good and commercial.

Today we have a guest, Tamás Holics. He owns STA Consulting, a Hungarian company which has created 2 very interesting SAP products. In this article Tamás presents the STA Ticket System.

The problem

A lot of time is wasted in SAP software testing and maintenance processes due to incomplete or incorrect error reports from users and testers. Support people (analysts, developers) usually have to ask for more information about the error. This takes a lot of valuable working time from both the reporters of the error and support people. Solving the problem is often blocked until every information is available.

For many years I’ve been complaining about how backward ABAP development ecosystem is and how long it takes to evolve. Every time he heard me saying it a good friend of mine would wisely advise me to never bite the hand that feeds you.

But how can a man not speak out?

We are constantly learning. But once in a while we learn something which is a leap forward forcing us to look in a new way to everything we do. The last time this had happened was when I started using OO in ABAP. OO was not new to me as I had already used it extensively in Java, C#, C++, etc. But to finally be able to apply these precious concepts on my daily job was a relief and a big improvement in the quality, flexibility and speed of my work.

This is how internal tables used to be declared:

DATA: itbl TYPE TABLE OF bkpf.

Some times I don’t like the names SAP gave to things. So I change them.

For example, one day I was very angry and thought all customers were parasites.

So I did the following:

When we learn ABAP, we are taught a series of rules on how to name variables. Not everyone uses the same rules but, still, some strict rules are shared between many people:

• Local variables must start with L: L_BUKRS;

• Global variables must start with G: G_MODE;

• Internal tables must have T_: LT_MARA;

• Structures must have S_: LS_MARA;

• Object references must have R_: R_CUSTOMER;

• input parameters must start with I, output with O, changing with C and returning with R.

• And the most stupid of all, field-symbols must start with FS_: <FS_MARA>.

In the early XXI century those rules made some sense (except for the field-symbols on, which was, and still is, as stupid as writing ‘pencil’ in all our pencils). Today they don’t make much sense anymore. Let me explain.

Nuno Morais has developed another very useful tool to help simplify mass translations of most SAP objects. The toold is not for automatic translation between two languages. Instead, it has the following features: Export an Excel file with texts Import an Excel file with texts Copy texts from one language into one or more languages Create a transport order with the changed texts