Description

Defines a RAP business event in a managed or unmanaged RAP BO. A RAP business event is a data record that expresses a significant change in the state of a RAP BO entity. An interested party that has subscribed to this event can consume and process it.

An input parameter ParamName can optionally be defined to specify the information that is passed to the event consumers. This information is called the payload of the event.

• If parameter ParamName is specified, ParamName must be a CDS abstract entity. The parameter is flat in this case. This means that the BDEF derived type for the parameter contains a component for each field of the CDS abstract entity.
• If deep parameter ParamName is specified, ParamName must be an abstract BDEF with hierarchy. The parameter is deep in this case. This means that the BDEF derived type for the parameter is a hierarchy that contains all entity fields plus the components for every CDS composition.

A RAP business event must be raised in the ABAP behavior pool of the RAP BO in question with the ABAP EML statement RAISE ENTITY EVENT. It is recommended that RAP business events are raised during the RAP saver methods save or save_modified. In managed RAP BOs, it is recommended that a RAP additional save is specified using the syntax addition with additional save and raise the RAP business event in this additional save implementation.

Availability

• RAP business events can be defined in managed RAP BOs and in unmanaged RAP BOs.
• RAP business events can be reused in RAP interface behavior definitions using the keyword use event. This is described in the topic RAP - use, Projection and Interface BDEF.
• Caution: Reusing RAP business events in RAP projection behavior definitions is not possible.

Further Information

Development guide for the ABAP RESTful Application Programming Model, section about RAP Business Events.

Example

The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_EVENT. It defines two events:

• myEvent defines a flat input parameter
• myEvent1 defines a deep input parameter

managed with additional save
implementation in class bp_demo_rap_event unique;
strict ( 2 );

define behavior for DEMO_RAP_EVENT alias Root
persistent table demo_dbtab_root
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  field ( readonly : update ) key_field;

  event myEvent parameter demo_abstract_root_1;
  event myEvent1 deep parameter demo_abstract_root;
}

The following CDS abstract entity is used as flat parameter:

@EndUserText.label: 'CDS root abstract entity, RAP event demo'
define abstract entity DEMO_ABSTRACT_ROOT_1
{
     col1: abap.int4;
     col2: abap.char(25);    
}

The following abstract BDEF is used as deep parameter:

abstract;
strict(2);
with hierarchy;

define behavior for DEMO_ABSTRACT_ROOT
with control
{
  association _item1;
  association _item2;
  association _scalar;

  field ( mandatory:execute ) num1;

}

define behavior for DEMO_HIER_ABS_ITEM1
with control
{
  field ( suppress ) root2_id;
  association _root2 with hierarchy;
}

define behavior for DEMO_HIER_ABS_ITEM2
with control
{
}

scalar entity DEMO_HIER_ABS_SCALAR field char1;

The RAP business event is raised in the RAP saver method save_modified as follows:

METHOD save_modified. 
  IF create-root IS NOT INITIAL. 
 
    RAISE ENTITY EVENT demo_rap_event~MyEvent 
      FROM VALUE #( 
        FOR var IN create-root ( 
            %param = VALUE #( col1        = var-data_field 
                              col2        = var-char_field ) ) ). 
  ENDIF. 
 
  IF update-root IS NOT INITIAL. 
 
    RAISE ENTITY EVENT demo_rap_event~MyEvent1 
      FROM VALUE #( 
        FOR var2 IN create-root ( 
            %param = VALUE #( char1      = var2-char_field 
                              num1       = var2-data_field ) ) ). 
  ENDIF. 
ENDMETHOD.

The BDEF derived type of the flat parameter looks as follows:

The BDEF derived type of the deep parameter looks as follows: