Transaction SE37 lets you test function modules. Sometimes these function modules use tables. And sometimes you need to load these tables with a lot of data records. But the only way to do it is manually. Or maybe not…

Here’s a trick to do it using a file.

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.

Every day I learn something new in ABAP. Sometimes I’d rather not learn them. Like this one.

Table T056P has a date field. While SELECTing this table using the date as criteria I couldn’t get any result even though the code seemed correct. Using SE16N I found that the date range was also not working as expected: it would only should results if the final date was put in the LOW field and the initial date in the HIGH. Bizarre.

John created transaction ZFB01 and associated it with program ZFB01 which, after doing some stuff, does a CALL TRANSACTION on FB01. Then came his friend Mike and ran transaction ZFB01.

He managed to start running it because he had permissions to do it. But half way through he got an error because he doesn’t have permissions to run transaction FB01.

Both John and Mike knew that the system administrators would never ever give Mike permission to run FB01.

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.