This article was written by José Vília:

The Dolly sheep was alive in ABAP and I didn’t know about it.

Having created a class instance, I’d like to share it with another totally independent program to use it as if the instance had been created there.

It’s an ABAP Dolly sheep factory we’re talking about here, people. Serialization in the ABAP world.

We’re all lazy. It’s just human. Programmers are human. We’re often lazy when it comes to the way we program something. And usually being lazy when making a program will result in someone else having more work when maintaining it.

Let he who is free of laziness throw the first rock.

I won’t!

Foreword

When I say that I like to use UML class diagrams to document my code, people think I’m crazy.

Introduction

The UML has gained a bad reputation because people think that, first you make the classes diagram in UML and only then write the program. But that was in 1996, when you the good practices said the first thing to do was the whole technical spec, even if no one really did it.

Nowadays, fortunately, we are no longer ashamed to say that the very act of programming is already in itself a way of drawing.

If you read Abapinho you already know how much I like exception classes. But this is not the only ABAP mechanism for dealing with errors.

There is another one, called ASSERT, which should be used more often.

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.

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.

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.

If you want to serialize a set of strings stored in an internal table there are two ways to do it. One is dull, the other one is full of style.

What I’m about to show you is not exactly new. It has even been used in Abapinho before. But since there is still a lot of people out there using LOOP to change a single field of an internal table, I thought it would be worth talking about it.

DELETE CLEAR REFRESH FREE

These are different ways of deleting all data from an internal table. They look the same. But they aren’t.

Get ready because you’ll soon be running into a lot of surprises. ABAP is learning new tricks. Look at this one: CONSTANTS: lc_menina TYPE STRING VALUE ‘GIRL', lc_menino TYPE STRING VALUE ‘BOY’, lc_senhor TYPE STRING VALUE ’GENTLEMAN’, lc_senhora TYPE STRING VALUE ‘LADY’. SELECT nome, CASE WHEN sexo_id = ‘M' AND idade < 18 THEN @lc_menino WHEN sexo_id = ‘F’ AND idade < 18 THEN @lc_menina WHEN sexo_id = ‘M' AND idade >=18 THEN @lc_senhor WHEN sexo_id = ‘F’ AND idade >=18 THEN @lc_senhora END AS titulo FROM zpessoa WHERE pessoa_id = @pessoa_id INTO CORRESPONDING FIELDS OF @lt_pessoas.