Skip to Content
Technical Articles
Author's profile photo Julian Danho

RAP EML Dynamic Operations: Dynamic EML Requests

Introduction

In the world of ABAP development, the RAP framework has revolutionized the way we build robust and flexible applications. One of the key features of RAP is the ability to dynamically generate EML (Entity Manipulation Language) requests. In this blog post, we will explore the dynamic form of MODIFY ENTITIES OPERATIONS, which allows us to perform operations on multiple business objects within a single statement.

 

Understanding MODIFY ENTITIES OPERATIONS

The MODIFY ENTITIES OPERATIONS statement in RAP enables us to manipulate entities by performing various operations such as CREATE, UPDATE, DELETE, or EXECUTE (Actions). What makes the dynamic form of this statement particularly powerful is its ability to handle operations on multiple business objects simultaneously. Operations expects an internal table of the type ABP_BEHV_CHANGES.

 

The ABAP Documentation you can find here: https://help.sap.com/doc/abapdocu_754_index_htm/7.54/en-US/index.htm?file=abeneml_modify_entities_op.htm

Here you will find my example in the business partner context (based on the CDS root view entity I_BusinessPartnerTP_3).

DATA:
  _BP_ROOT           TYPE TABLE FOR CREATE I_BusinessPartnerTP_3,
  _BP_ADDRESS        TYPE TABLE FOR CREATE I_BusinessPartnerTP_3\_BusinessPartnerAddress,
  _BP_IDENTIFICATION TYPE TABLE FOR CREATE I_BUSINESSPARTNERTP_3\_BusinessPartnerIdentification,
  _BP_ADDRESS_USAGE  TYPE TABLE FOR CREATE I_BusinessPartnerAddressTP_3\_BusinessPartnerAddressUsage.

MODIFY ENTITIES OPERATIONS
  VALUE ABP_BEHV_CHANGES_TAB(
    ( VALUE ABP_BEHV_CHANGES(
        OP = IF_ABAP_BEHV=>OP-M-CREATE
        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'
        INSTANCES =  REF #( _BP_ROOT )
    ) )
    ( VALUE ABP_BEHV_CHANGES(
        OP = IF_ABAP_BEHV=>OP-M-CREATE_BA
        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'
        SUB_NAME = '_BUSINESSPARTNERADDRESS'
        INSTANCES = REF #( _BP_ADDRESS )
    ) )
    ( VALUE ABP_BEHV_CHANGES(
        OP = IF_ABAP_BEHV=>OP-M-CREATE_BA
        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'
        SUB_NAME = '_BUSINESSPARTNERIDENTIFICATION'
        INSTANCES = REF #( _BP_IDENTIFICATION )
    ) )
    ( VALUE abp_behv_changes(
        op = if_abap_behv=>op-m-create_ba
        entity_name = 'I_BUSINESSPARTNERADDRESSTP_3'
        sub_name = '_BUSINESSPARTNERADDRESSUSAGE'
        instances = REF #( _bp_address_usage )
    ) )
  )

  MAPPED DATA(_MAPPED)
  REPORTED DATA(_REPORTED)
  FAILED DATA(_FAILED).

The Structure of Operations

Operation%20Structure

Operation Structure

Important: The name/value of ENTITY_NAME and SUB_NAME should be in upper case. Otherwise you will get an unknown shortdump. This seems to be a bug in the standard SAP operation. Normally the upper case conversion could be done in the standard functionality.

But how should the instances (here e.g. _bp_root, _bp_address) be filled?

Instances

Instances

The %cid attribute is the content ID which are used as unique and temporary ID for RAP BO Operations. In this case, we assign the %cid “bp_root” to the root object, which must be assigned as %cid_ref for the underlying object address.

The attribute %data is self-speaking for the transfer of the data to be created.

 

“Usual” equivalent

This would be the “usual” equivalent of the dynamic EML call:

MODIFY ENTITIES OF I_BusinessPartnerTP_3
  ENTITY BusinessPartner
    CREATE
      SET FIELDS WITH _BP_ROOT
    CREATE BY \_BusinessPartnerAddress
      SET FIELDS WITH _bp_address
    CREATE BY \_BusinessPartnerIdentification
      SET FIELDS WITH _bp_identification
  ENTITY BusPartAddress
    CREATE BY \_BusinessPartnerAddressUsage
      SET FIELDS WITH _bp_address_usage
  MAPPED DATA(_mapped)
  FAILED DATA(_failed)
  REPORTED DATA(_reported).

 

Dynamic Flexibility

One of the significant advantages of using the dynamic form of MODIFY ENTITIES OPERATIONS is the flexibility it offers. By allowing operations on multiple business objects within a single statement, developers can streamline their code and enhance efficiency. It eliminates the need for repetitive operations and simplifies the overall development process. It offers the possibility to create a generic EML concept in case of dynamic requests regarding the operation (CRUD) or the entity or associations.

 

Conclusion

In this blog post, we delved into the dynamic form of MODIFY ENTITIES OPERATIONS. Leveraging the power of RAP’s dynamic EML requests opens up new possibilities for building advanced applications in ABAP development. By harnessing this flexibility, developers can achieve greater productivity and maintainability in their projects. So, go ahead and explore the dynamic world of RAP EML Dynamic Operations and take your ABAP development to the next level!

 

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Andre Fischer
      Andre Fischer

      Hi Julian,

      nice blog post.

      With regards to your statement:

      Important: The name/value of ENTITY_NAME and SUB_NAME should be in upper case. Otherwise you will get an unknown shortdump. This seems to be a bug in the standard SAP operation. Normally the upper case conversion could be done in the standard functionality.

      I would like to add that this is mentioned in the documentation that "The name must be provided using capital letters.".

      If you feel that the error message itself is misleading please open a ticket for that.

      Kind regards,

      Andre

      https://help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/index.htm?file=abapmodify_entities_operations_dyn.htm

       

      Component Details
      op It is a mandatory component specifying the operation to be executed. It can be set with the defined constants, for example, op-m-create, of interface IF_ABAP_BEHV or just the predefined value for the operation in the interface, for example 'C' for a create operation (op = 'C').
      entity_name It is a mandatory component and specifies the name of the BO entity for which the operation is executed. The name must be provided using capital letters.
      sub_name Optional component. It is only relevant for specifying association names in case of create-by-association operations or for actions. The name must be provided using capital letters. In case of create-by-association operations, when using the constant if_abap_behv=>op-m-create_ba, the alias name for the association must be provided in uppercase.
      instances It is a mandatory component specifying the instances in an internal table. The table is a reference variable with static type DATA.
      request It is an optional component specifying an internal table for requests. The table is a reference variable with static type DATA.
      results It is an optional component storing results of an action. The table is a reference variable with static type DATA.

       

      Author's profile photo Julian Danho
      Julian Danho
      Blog Post Author

      Hello Andre,

      Thank you for your remark.

      I did see the note about using capital letters, but unfortunately that goes under. You only read that when you get an ST22 dump.

      For example, here you find the part of the standard coding of the operation. This is where the exception is thrown because the non-upper-case CDS view or association is not found. Here a "to_upper" could be put. I will open a ticket for this.

      Author's profile photo Andre Fischer
      Andre Fischer

      I will follow up on this with my colleagues from development to see if there is something that can be done.