Defining Actions and Messages
Based on structure type IF_T100_MESSAGE=>SCX_T100KEY. Used to identify the message class (ID), the message number, a type and, if applicable, values for the placeholders &1, &2, &3, and&4 in the message text.
During instantiation of the class, both attributes need to be filled in the constructor logic, either hard coded or with suitable import parameters. It is a recommended practice to define one or more structured constants in the public section, to define possible value combinations for TEXTID. These constants can then be used to supply a constructor parameter textid when instantiating the message class.
Reporting Static Messages
Reporting Static Messages
Certain behavior implementation methods, like, for example, action implementation methods and validation implementation methods, have an implicit response parameter reported. This parameter indicates that you can issue messages as part of the implementation. To do so, you have to create an instance of a message class, that is, a class that implements interface IF_ABAP_BEHV_MESSAGE, and store a reference to this instance in parameter reported.
Static messages, which are not related to an entity instance, are stored in table-like component %other.
Reporting Instance Messages
Reporting Instance Messages
Instance messages, that is, messages related to a instance of a RAP BO entity, are stored in one of the other components of parameter reported.
If, for example, the message relates to an instance of entity Z00_C_Text, the message is stored in internal table reported-Z00_C_Text.
First, the key fields of the related entity instance are filled, for example via named include %tky. Then component %msg is filled with a reference to the created message object.
EML in RAP BO Implementations
EML Inside Behavior Implementation
To access a RAP BOs data from inside its behavior implementation, EML statements are used. There is no mayor difference in the syntax.
But there is an addition, IN LOCAL MODE, that can currently only be used in the RAP BO implementations for the particular RAP BO itself. That means that IN LOCAL MODE can only be used for this RAP BO's implementation classes in the behavior pool or other classes that are called from those implementation classes (for example, legacy code or other reused logic contained elsewhere).
The addition is used to exclude feature controls and authorization checks. It can be added to READ ENTITY/MODIFY ENTITY and to the long forms READ ENTITIES/MODIFY ENTITIES.
An example use case could be an action implementation that wants to update a field, that is set to readOnly for consumers of the BO.