Friday 5 August 2022

ABAP Restful Application Programming: Custom actions => Merge Draft entities into Active and switch to display mode

Introduction:

In this blog post, I will explain about “Custom actions” that can merge draft entities into Active and switch to display mode. An action in RAP is a non-standard modifying operation that is part of the business logic. The standard use case of an action is to change specific fields of a business object entity.

Problem statement:

In General, MODIFY ENTITIES can be used to change the required fields in an entity. That means, Active instance remains as active and Draft instance remains as Draft. But some business requirements expect us to convert those draft instances into active instances.

This can be achieved using “EXECUTE Activate” on MODIFY ENTITIES. With this, Active instance is prepared but the real challenge comes now.

How does the fiori app come to know about this change to show modified information of the entity?

​Then “side effects” strike my mind but later I realize that they can be triggered to reflect modified information ( different property / entity ) on change of a field/entity/action  . 

But, In our case, Own entity needs to be refreshed. Actual challenge here is that the “original key” is “IsActiveEntity=false” while the modified key is “IsActiveEntity=true“.

Solution:

As the entity instance itself is changing ( key ) through the action , we can declare the result parameter as “entity” with an “entity type” but not $self. That helps the fiori app to identify that the result instance is different from the initial instance. 

$self keeps the same instance even after action execution. 

Let us take an example action “CompletePR” that sets status code to “CMPL” on the header entity.

Please note that Base/Interface view entities need to be declared in Base Behavior Definition.

action CompletePR result [1] entity ZRK_I_PUR_REQ_H;

​The result projection view entities need to be exposed again in projection behaviour definition. ​

use action CompletePR result entity ZRK_C_PUR_REQ_H;​

During method implementation, We have to consider that there can be mixed instances of the input entities. Hence take out draft instances and apply “EXECUTE Activate” on MODIFY ENTITIES.

At this point of time, All the instances should be having active instances. So we have to read new instances to return to the fiori app in “result” .

So let’s prepare new keys where “%is_draft = if_abap_behv=>mk-off ” to read entities to get new instances.

It’s time to populate the result parameter and please note that

%key , %tky  to be filled from source instance while %param-%key to be filled from new instance. So that fiori app understands to fire “get” Call and retrive the new instance. As the result entity is an active instance, Fiori app automatically switches to display mode.

Below is the sample implementation.

  METHOD CompletePR.

*Modify the entities with required fields.

    MODIFY ENTITIES OF zrk_i_pur_req_h IN LOCAL MODE

      ENTITY _PRHead

      UPDATE FIELDS ( StatCode )

          WITH VALUE #( FOR key IN keys ( %tky = key-%tky

                                          StatCode ='CMPL' ) ).

* Check if there are any draft instances?

    DATA(lt_draft_docs) = keys.

    DELETE lt_draft_docs WHERE %is_draft = if_abap_behv=>mk-off.

    IF lt_draft_docs IS NOT INITIAL.

* EXECUTE Active only on draft instances.

        MODIFY ENTITIES OF zrk_i_pur_req_h IN LOCAL MODE

          ENTITY _PRHead

            EXECUTE Activate FROM

            VALUE #( FOR key IN keys ( %key = key-%key ) )

          REPORTED DATA(activate_reported)

          FAILED DATA(activate_failed)

          MAPPED DATA(activate_mapped).

   ENDIF.

* Change Keys to read active Instance

    DATA(lt_keys) = keys.

    LOOP AT lt_keys ASSIGNING FIELD-SYMBOL(<ls_key>).

      <ls_key>-%is_draft = if_abap_behv=>mk-off.

    ENDLOOP.

* Read the active instance to send back to Fiori App.

    READ ENTITIES OF zrk_i_pur_req_h IN LOCAL MODE

        ENTITY _PRHead

        ALL FIELDS WITH CORRESPONDING #( lt_keys )

        RESULT DATA(lt_pur_req).

* Populate %key , %tky  to be filled from source instance while %param-%key to be filled from new instance.

    result = VALUE #( for <fs_old_key> in keys

                      for <fs_new_key> IN lt_keys WHERE ( ObjectId = <Fs_old_key>-ObjectId )

                                                    ( %key = <fs_old_key>-%key

                                                      %tky = <fs_old_key>-%tky

                                                      %param-%key = <fs_new_key>-%key ) ).

    mapped-_prhead = CORRESPONDING #( lt_pur_req ).

  ENDMETHOD.

ABAP RESTful Application Programming Model, ABAP Development, SAP BTP, ABAP Environment, SAP S/4HANA, SAP ABAP Career, SAP ABAP Jobs, SAP ABAP Preparation, SAP ABAP Career Exam, SAP ABAP Tutorial and Materials, SAP ABAP Restful, SAP ABAP Certification

ABAP RESTful Application Programming Model, ABAP Development, SAP BTP, ABAP Environment, SAP S/4HANA, SAP ABAP Career, SAP ABAP Jobs, SAP ABAP Preparation, SAP ABAP Career Exam, SAP ABAP Tutorial and Materials, SAP ABAP Restful, SAP ABAP Certification

As we can see, “Get” call is fired with new key and fiori app is switched to display mode.

No comments:

Post a Comment