RAP Messages

Introduction :

In the Restful ABAP Programming Model (RAP), messages play a crucial role in validations as they provide meaningful feedback to the user regarding errors, warnings, or informational prompts. These messages help ensure data integrity and guide users during transactional or CRUD (Create, Read, Update, Delete) operations. And REPORTED and FAILURE structures are used to handle messages effectively during validations and other operations. They provide mechanisms to return meaningful feedback to the user. 

The Reported structure is used to collect and return messages to the caller. These messages can be of various types, such as errors, warnings, or informational messages. 

The Failure structure we have to fill what is cause of that particular failure .

There are different type of messages in rap such as state messages and transition messages 

State message:  As state messages are semantically related to the state of business object 

It belong to  particular state of business object instance. State messages always save in database along with the particular message. State messages are very useful the draft scenario because in the draft we are saving not only the consistent and we are saving the inconsistent data in the draft table . 

 Transition messages: Since transition messages are semantically related to the current request rather than the state of a business object, they are returned using the REPORTED structure of the corresponding EML statement. And transition messages will be available during the transition from one state to another state it will displayed when displayed once. if user will close it will disappear and it will not save in backend. 

In transition messages it is not important to pass %TKY. 

Key Components of Messages: 

 %TKY: it is important to pass the %TKY in state messages  because it will tell this particular messages belong to this behavior  

%element : it will specify from which field  the error will raise. We need specify both %element and %TKY it will specify from which field  and entity the error raised. 

%path : in this we are specifying error will be from root entity are from child entity  

%op-%create  

%op-%action-action1 : this error came due to create operation or action . 

By this user will get to know error will came due to create operation. 

%STATE_AREA: When this component of type String is populated, the framework treats the message as a state-related message. 

%other: The %OTHER to handle messages that are not related to a specific entity. The %OTHER component is populated with an instance of the message-wrapper class for unbound messages that are not tied to any business object entity. 

%MSG: Contains an instance of the message-wrapper class. 

Let see practical of both state and transition messages  

Scenarios for messages: 

 State messages :  

 Scenario for state:  When a user attempts to enter or update a subject name in the Fees details, the system should validate that this subject name exists in the exam Details. If the subject name does not exist, an error message should be displayed, preventing the operation. 

Behavior definition: 

Validation method code:

METHOD Check_Subject.

READ ENTITIES OF zdp_i_cds_stu IN LOCAL MODE
ENTITY Student
by _fees
ALL FIELDS
WITH CORRESPONDING #( keys )
RESULT DATA(lt_fees).

read ENTITIES OF zdp_i_cds_stu in LOCAL MODE
ENTITY student
by _exam
from CORRESPONDING #( lt_fees )
link data(student_exam_subject).

data(ls_fees) = lt_fees[ 1 ].

select SINGLE from zdp_dt_exam fields subject_name WHERE stuid = _fees-Stuid INTo (ls_subject).

if ls_subject ne ls_fees-SubjectName.
APPEND VALUE #( %tky = ls_fees-%tky ) to failed-zdp_i_fees_m.
APPEND VALUE #(
%tky = ls_fees-%tky
%state_area = ‘VALIDATE SUBJECT NAME’
%element-subjectname = if_abap_behv=>mk-on
%path = value #( Student-%tky = student_exam_subject[ key id
source-%tky = ls_fees-%tky ]-target-%tky )
%msg = me->new_message(
id = ‘ZDP_MESSAGE_CLASS’
number = ‘011’
severity = ms-error
v1 = ls_fees-SubjectName
* v2 =
* v3 =
* v4 =
) ) TO reported-zdp_i_fees_m.
ENDIF.
ENDMETHOD.

This my output screen. in that we can see three entities data will be displayed such as student, exam and fees details.

In exam details I pass the subject.

In fees details if I didn’t pass same subject name then error will raise. 

Output: the system generates a message specifying the entity and field with the issue. 

in this error we can see that messages is coming from fees details entity and Field name.

Transition messages : are of three type instance bound ,Entity bound ,Unbound Transition .

Instance bound : in instance bound along with the message you are passing messages belong to which instance. 

Scenario for transition: In exam details If user didn’t provide the marks at that time message will trigger. 

 Behavior definition: 

Code: 

METHOD marks_validation.

READ ENTITIES OF zdp_i_cds_stu
ENTITY Student BY _Exam
FIELDS ( Marks ) WITH CORRESPONDING #( keys )
RESULT DATA(lt_marks).

DATA(ls_marks) = lt_marks[ 1 ].
DATA(lv_marks) = ls_marks-Marks.

IF ls_marks-Marks IS INITIAL.
APPEND VALUE #( %tky = ls_marks-%tky
%msg = new_message_with_text( severity =
if_abap_behv_message=>severity-error
text = ‘Please Enter Marks for STUID ‘ && ‘ ‘ && ls_marks-Stuid ) ) TO reported-student.
ENDIF.
ENDMETHOD.

Output: 

Entity bound : 

Entity bound messages are typically displayed in global authorization and global feature control scenarios. In such cases, the instance itself is not available. Therefore, before creating the instance, we check whether the user has the required access. 

Scenario:  If the user’s result_status is failed and is changed to pass by clicking the action button, the system will display a success message after the successful update using an entity-bound message. 

 Behavior definition: 

Code : 

METHOD change_exam_result_enabler.

MODIFY ENTITIES OF zdp_i_cds_stu IN LOCAL MODE
ENTITY Student
UPDATE FIELDS ( result_status ) WITH VALUE #( FOR key IN keys ( %tky = key-%tky result_status = ‘P’ ) ).
result = VALUE #( FOR key IN keys ( %tky = key-%tky
%param = CORRESPONDING #( key ) ) ) .

APPEND VALUE #( %msg = new_message_with_text(
severity = if_abap_behv_message=>severity-success
text = ‘Successfully changed Result_status’ ) )
TO reported-student.

ENDMETHOD.

Output: 

After successfully update  

Conclusion:  

As state messages are semantically related to the state of business object while transition messages are semantically related to the current request rather than the state of a business object. Both complement each other to enhance user experience and ensure clarity in the RAP model. 

​ Introduction :In the Restful ABAP Programming Model (RAP), messages play a crucial role in validations as they provide meaningful feedback to the user regarding errors, warnings, or informational prompts. These messages help ensure data integrity and guide users during transactional or CRUD (Create, Read, Update, Delete) operations. And REPORTED and FAILURE structures are used to handle messages effectively during validations and other operations. They provide mechanisms to return meaningful feedback to the user. The Reported structure is used to collect and return messages to the caller. These messages can be of various types, such as errors, warnings, or informational messages. The Failure structure we have to fill what is cause of that particular failure .There are different type of messages in rap such as state messages and transition messages State message:  As state messages are semantically related to the state of business object It belong to  particular state of business object instance. State messages always save in database along with the particular message. State messages are very useful the draft scenario because in the draft we are saving not only the consistent and we are saving the inconsistent data in the draft table .  Transition messages: Since transition messages are semantically related to the current request rather than the state of a business object, they are returned using the REPORTED structure of the corresponding EML statement. And transition messages will be available during the transition from one state to another state it will displayed when displayed once. if user will close it will disappear and it will not save in backend. In transition messages it is not important to pass %TKY. Key Components of Messages:  %TKY: it is important to pass the %TKY in state messages  because it will tell this particular messages belong to this behavior  %element : it will specify from which field  the error will raise. We need specify both %element and %TKY it will specify from which field  and entity the error raised. %path : in this we are specifying error will be from root entity are from child entity  %op-%create  %op-%action-action1 : this error came due to create operation or action . By this user will get to know error will came due to create operation. %STATE_AREA: When this component of type String is populated, the framework treats the message as a state-related message. %other: The %OTHER to handle messages that are not related to a specific entity. The %OTHER component is populated with an instance of the message-wrapper class for unbound messages that are not tied to any business object entity. %MSG: Contains an instance of the message-wrapper class. Let see practical of both state and transition messages  Scenarios for messages:  State messages :   Scenario for state:  When a user attempts to enter or update a subject name in the Fees details, the system should validate that this subject name exists in the exam Details. If the subject name does not exist, an error message should be displayed, preventing the operation. Behavior definition: Validation method code:  METHOD Check_Subject.

READ ENTITIES OF zdp_i_cds_stu IN LOCAL MODE
ENTITY Student
by _fees
ALL FIELDS
WITH CORRESPONDING #( keys )
RESULT DATA(lt_fees).

read ENTITIES OF zdp_i_cds_stu in LOCAL MODE
ENTITY student
by _exam
from CORRESPONDING #( lt_fees )
link data(student_exam_subject).

data(ls_fees) = lt_fees[ 1 ].

select SINGLE from zdp_dt_exam fields subject_name WHERE stuid = _fees-Stuid INTo (ls_subject).

if ls_subject ne ls_fees-SubjectName.
APPEND VALUE #( %tky = ls_fees-%tky ) to failed-zdp_i_fees_m.
APPEND VALUE #(
%tky = ls_fees-%tky
%state_area = ‘VALIDATE SUBJECT NAME’
%element-subjectname = if_abap_behv=>mk-on
%path = value #( Student-%tky = student_exam_subject[ key id
source-%tky = ls_fees-%tky ]-target-%tky )
%msg = me->new_message(
id = ‘ZDP_MESSAGE_CLASS’
number = ‘011’
severity = ms-error
v1 = ls_fees-SubjectName
* v2 =
* v3 =
* v4 =
) ) TO reported-zdp_i_fees_m.
ENDIF.
ENDMETHOD.

  This my output screen. in that we can see three entities data will be displayed such as student, exam and fees details.In exam details I pass the subject.In fees details if I didn’t pass same subject name then error will raise. Output: the system generates a message specifying the entity and field with the issue. in this error we can see that messages is coming from fees details entity and Field name.Transition messages : are of three type instance bound ,Entity bound ,Unbound Transition .Instance bound : in instance bound along with the message you are passing messages belong to which instance. Scenario for transition: In exam details If user didn’t provide the marks at that time message will trigger.  Behavior definition: Code:   METHOD marks_validation.

READ ENTITIES OF zdp_i_cds_stu
ENTITY Student BY _Exam
FIELDS ( Marks ) WITH CORRESPONDING #( keys )
RESULT DATA(lt_marks).

DATA(ls_marks) = lt_marks[ 1 ].
DATA(lv_marks) = ls_marks-Marks.

IF ls_marks-Marks IS INITIAL.
APPEND VALUE #( %tky = ls_marks-%tky
%msg = new_message_with_text( severity =
if_abap_behv_message=>severity-error
text = ‘Please Enter Marks for STUID ‘ && ‘ ‘ && ls_marks-Stuid ) ) TO reported-student.
ENDIF.
ENDMETHOD.   Output: Entity bound : Entity bound messages are typically displayed in global authorization and global feature control scenarios. In such cases, the instance itself is not available. Therefore, before creating the instance, we check whether the user has the required access. Scenario:  If the user’s result_status is failed and is changed to pass by clicking the action button, the system will display a success message after the successful update using an entity-bound message.  Behavior definition: Code :   METHOD change_exam_result_enabler.

MODIFY ENTITIES OF zdp_i_cds_stu IN LOCAL MODE
ENTITY Student
UPDATE FIELDS ( result_status ) WITH VALUE #( FOR key IN keys ( %tky = key-%tky result_status = ‘P’ ) ).
result = VALUE #( FOR key IN keys ( %tky = key-%tky
%param = CORRESPONDING #( key ) ) ) .

APPEND VALUE #( %msg = new_message_with_text(
severity = if_abap_behv_message=>severity-success
text = ‘Successfully changed Result_status’ ) )
TO reported-student.

ENDMETHOD.   Output: After successfully update  Conclusion:  As state messages are semantically related to the state of business object while transition messages are semantically related to the current request rather than the state of a business object. Both complement each other to enhance user experience and ensure clarity in the RAP model.      Read More Application Development Blog Posts articles 

#SAP