What is the modern replacement to obsolete FORM subroutine in ABAP?

Question

The ABAP documentation lists three kinds of modularization structures:

• Methods. Problem: methods don't accept parameters.
• Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
• Forms. Problem: are marked as "obsolete".

Is there a newer structure that replaces the obsolete FORM structure, that is:

1. Local to our program.
2. Accepts parameters.
3. Doesn't require ABAP Objects syntax ?

Answer 1

You are having some wrong information there. Don't know what system version are you in, but this info could help you out:

• Methods: They actually accept parameters (should be crazy if they wouldn't). In fact, they accept IMPORTING, EXPORTING, CHANGING and RETURNING parameters.

• Forms: Indeed they are obsolete, but in my opinion there is no risk in using then, almost every standard component relies in programs made out of FORMS. FORMS are a core concept in ABAP programming. They are the "function" or "def" of many other languages. They accept USING, CHANGING and TABLES parameters.

Answer 2

Methods. Problem: methods don't accept parameters.

I am not sure how you came to that conclusion, because methods support parameters very well. The only limitation compared to FORMs is that they don't support TABLES parameters to take a TABLE WITH HEADER LINE. But they support CHANGING parameters with internal tables, which covers any case where you don't actually need the header-line. And in the rare case that you are indeed forced to deal with a TABLE WITH HEADER LINE and the method actually needs the header-line (I pity you), you can pass the header-line as a separate parameter.

You declare a method with parameters like this:

CLASS lcl_main DEFINITION.
    METHODS foo
       IMPORTING iv_bar TYPE i
       EXPORTING es_last_message TYPE bapiret2
       CHANGING ct_all_messages TYPE bapiret2_t.
ENDCLASS.

And you call it either like that:

main->foo( IMPORTING iv_bar = 1
           EXPORTING es_last_message = t_messages
           CHANGING ct_all_messages = t_messages[] ).

or with the more classic syntax like that:

CALL METHOD main->foo
    IMPORTING iv_bar = 1
    EXPORTING es_last_message = t_messages
    CHANGING ct_all_messages = t_messages[].

Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.

Yes, function modules are supposed to be global while FORM's are supposed to be local (supposed to: You can actually call a FORM in another program with PERFORM formname IN PROGRAM programname).

But classes can be local or global, depending on how you created them. A global class can be used by any program in the system. So function groups can be substituted by global classes in most cases.

The one use-case where function modules can not be substituted by methods of classes is for RFC-enabled function modules. RFC is the Remote Function Call protocol which allows external systems to execute a function module in another system via network. However, if you do need some other system to communicate with your SAP system, then you might want to consider to use webservices instead, which can be implemented with pure ABAP-OO. And they also offer much better interoperability with non-SAP systems because they don't require a proprietary protocol.

Is there a newer structure that replaces the obsolete FORM structure, that [...] Doesn't require ABAP Objects syntax ?

Here is where you got a problem. ABAP Objects syntax is the way we are supposed to program ABAP now. There is currently a pretty hard push to forget all the non-OO ways to write ABAP and fully embrace the ABAP-OO styles of writing code. With every new release, more classic syntax which can be substituted by ABAP-OO syntax gets declared obsolete.

However, so far SAP follows the philosophy of 100% backward compatibility. While they might try their best to compel people to not use certain obsolete language constructs (including adding scary-sounding warnings to the syntax check), they very rarely actually remove any language features. They hardly can, because they themselves got tons of legacy code which uses them and which would be far too expensive and risky to rewrite. The only case I can think of when they actually removed language features was when they introduced Unicode which made certain direct assignments between now incompatible types syntactically illegal.