Introduction:

ABAP Restful Programming model is the latest programming model which SAP has introduced and It’s a successor of ABAP programming model in FIORI. In this series of blog posts, I would like to highlight comparison between BOPF Model and RAP model to achieve the different requirements in a sample FIORI app. It would help people to easily adapt the transition from ABAP programming model in FIORI into RAP model. Additionally, I will also highlight some important comparative features between SAP Web IDE and SAP Business Application Studio( BAS ) .

Pre-requisites:

1. Good knowledge on CDS Modeling, BOPF Framework.
2. Basic knowledge in RAP Model ( Managed Implementation )
3. Basic understanding of SAP Web IDE and BAS.

Business Use Case:

A customizing FIORI app is required to configure various active company id and it’s allowed communication language keys. Different departments in one organization can have flexibility to customize different company ID and allowed languages. For that, a unique application ID will be maintained at first place. Use cases handled by the FIORI app would be as follow:

1. There should be a unique application ID for each business department ( e.g. FI-AR, FI-FSCM, SD-BILLING )
2. Only active applications can further allowed to have different company ID. For inactive applications, company ID cant be maintained.
3. CUD operations are not allowed for any inactive instance.
4. Actions to update the status( Active/Inactive ) should be enabled as per the FIORI UX guidelines.
5. Custom actions should be dynamically enabled/disabled based on status.
6. For Company ID, a popup dialog would be needed to set the validity period.
7. Company IDs where Valid from is in past are NOT allowed.
8. Valid To for a company should not be less than Valid From date.
9. Only Authorized users for each application can maintain the entries in the app.
10. Copy function to allow copy an existing application instance along with its associated entries.

The above points are just few of the use cases our FIORI app can perform but we will group the use cases and based on that, we will follow different blog posts in the series.

App Preview:

At the end, FIORI apps deployed in the launchpad would be a List report FIORI app created via templates but look and feel of the app has been changed as Master-Detail style since It would be helpful for end users to view all the associated entities on one screen.

Business Object Model:

Technical artifacts in the ABAP side can be created for the FIORI app based on the programming model we follow. Lets start now with the listed requirements with both the programming models.

1.1 Change Custom action visibility

As per BO model described above, there are 2 custom actions for all the entities: Set Active and  Set Inactive. Based on the status of the selected entity instance, visibility of the action buttons should be enabled/disabled.

Approach 1 : BOPF

• In the Business Object, Go to Determination ACTION_AND_FIELD_CONTROL .

• Navigate it’s implementing class and Implement the method /bobf/if_frw_determination~execute .

METHOD /bobf/if_frw_determination~execute.

    DATA: lt_context_data   TYPE ztipb_application.
    DATA: lv_action_enabled TYPE abap_bool.

    io_read->retrieve(
      EXPORTING
        iv_node                 =  is_ctx-node_key
        it_key                  =  it_key[]            " Key Table
      IMPORTING
        eo_message              =  eo_message          " Message Object
        et_data                 =  lt_context_data[]   " Data Return Structure
        et_failed_key           =  et_failed_key       " Failed Key Table
    ).

"(1)--> Handle Actions Dynamically
    LOOP AT lt_context_data ASSIGNING FIELD-SYMBOL(<ls_context>).
      IF <ls_context>-x_active = 'X'.
        lo_property_helper->set_action_enabled(
        iv_action_key = zif_i_pb_application_c=>sc_action-zi_pb_application-set_active
        iv_key        = <ls_context>-key
        iv_value      = abap_false ).

        lo_property_helper->set_action_enabled(
        iv_action_key = zif_i_pb_application_c=>sc_action-zi_pb_application-set_inactive
        iv_key        = <ls_context>-key
        iv_value      = abap_true ).
      ELSE.
        lo_property_helper->set_action_enabled(
        iv_action_key = zif_i_pb_application_c=>sc_action-zi_pb_application-set_active
        iv_key        = <ls_context>-key
        iv_value      = abap_true ).

        lo_property_helper->set_action_enabled(
        iv_action_key = zif_i_pb_application_c=>sc_action-zi_pb_application-set_inactive
        iv_key        = <ls_context>-key
        iv_value      = abap_false ).
      ENDIF.
    ENDLOOP.
ENDMETHOD.

Approach 2 : RAP

• In Behavior definition, Define Feature Control for custom actions with scope instance as we need to implement the action visibility based on selected instance’s status.

• In Behavior implementation, Implement the method for instance feature control and set the visibility of custom actions:

METHOD get_instance_features.
** Read the status of current application record
    READ ENTITIES OF zi_pb_active_appl IN LOCAL MODE
    ENTITY Application
    FIELDS ( IsActive ) WITH CORRESPONDING #( keys )
    RESULT DATA(lt_context_data)
    FAILED failed.

    result = VALUE #( FOR ls_data IN lt_context_data
                        LET lv_active   = COND #( WHEN ls_data-IsActive IS NOT INITIAL 
                                                  THEN if_abap_behv=>fc-o-disabled ELSE if_abap_behv=>fc-o-enabled )
                            lv_inactive = COND #( WHEN ls_data-IsActive IS INITIAL 
                                                  THEN if_abap_behv=>fc-o-disabled ELSE if_abap_behv=>fc-o-enabled )
                        IN ( %tky                         = ls_data-%tky
                             %action-activeApplication    = lv_active
                             %action-InactiveApplication  = lv_inactive )
                     ).

  ENDMETHOD.

Output in FIORI App:

Application with status active is selected so only action “Set Inactive” is allowed and “Set Inactive” will be disabled in List page.

Application with status Inactive is selected so only action “Set Active” is allowed and “Set Active” will be disabled in List page.

1.2 Enable fields dynamically

We can either enable the fields on FIORI UI as read only statically at design time or dynamically at run time based on some application logic. For that, there would be different steps in different programming models.

Approach 1 : BOPF

• Set Object Model annotation for CUD operations as EXTERNAL_CALCULATION in BO CDS view.

@ObjectModel:{

    semanticKey: ['application'],

    transactionalProcessingEnabled: true,
    compositionRoot: true,

    writeActivePersistence: 'zfar_active_appl',

    createEnabled: 'EXTERNAL_CALCULATION',
    updateEnabled: 'EXTERNAL_CALCULATION',
    deleteEnabled: 'EXTERNAL_CALCULATION'

}

• Set Object Model Annotation with readOnly property as dynamic for Application ID and true for admin fields. With this, Admin fields (CreatedBy, CreatedAt) would always be read only and Application ID will be editable during creation and read only during update operation.

define view ZI_PB_APPLICATION
  as select from zfar_active_appl
{
      @ObjectModel.readOnly: 'EXTERNAL_CALCULATION'
  key applicationId,
      name,
      @ObjectModel.readOnly: true
      @Semantics.user.createdBy: true
      created_by

• Now, Go to BOPF determination ACTION_AND_FIELD_CONTROL, navigate to implementing class and method EXECUTE and add following method call after reading the context node data:

      lo_property_helper->set_attribute_read_only(
        EXPORTING
          iv_attribute_name = zif_i_pb_application_c=>sc_node_attribute-zi_pb_application-application  " Name of the attribute for which the property is to be set
          iv_key            =  ls_attribute-key   " Key of the instance for which the property is to be set
      ).

Approach 2 : RAP

• In Behavior definition, Define property for create and update operation for field ApplicationID

field ( mandatory : create, readonly : update ) ApplicationID;
field ( readonly ) CreatedAt, CreatedBy;

By defining the applicationID mandatory during Create operation, RAP framework will allow UI to enable applicationID and once created, It will be read only during Update operation.

However, we can always define this behavior dynamic at field level using feature control and in the Feature control implementation method, we can set its property as:

  METHOD feature_ctrl_method.
    " Read data required 
    READ ENTITY CDSEntityName 
         FIELDS ( field1 field2 )
           WITH VALUE #( FOR keyval IN keys ( %key = keyval-%key ) )
         RESULT DATA(read_result).
    
    " Return feature control information
    result = VALUE #( FOR variable IN read_result
             ( %key                          = variable-%key
    " Field control information
               %field-field1                 = if_abap_behv=>fc-f-read_only
               %field-field2                 = if_abap_behv=>fc-f-mandatory ) ).
  ENDMETHOD.
        

Conclusion:

In this blog, All the different business scenarios have been discussed , Data Model has been explained which will be used in subsequent blog posts in the series and we covered 2 scenarios to handle the visibility of custom actions and fields dynamically both in BOPF ( ABAP programming Model in FIORI ) and RAP ( RESTful ABAP programming model ).

In the next blog post, we will cover authorizations on standard CUD operations in both the programming models.

I hope this topic will be helpful for those who are transitioning from BOPF Model to RAP model and can easily compare different ABAP programming approach. In future posts, we will also see comparative analysis about UI developments and tools so stay tuned and please provide your feedback in the comment section.