RAP Behaviour Implementation get_*_features/get_*_authorization : Should reported really get filled?

[WRoeckelein]

Hi RAP'lers,

the RAP Behaviour Implementation methods get_global_features, get_global_authorizations, get_instance_features, get_instance_authorizations have a changing parameter reported.

Is it really needed to fill this parameter? What is expected in this parameters? Where/when are they shown to the user in a Fiori Elements App?

If they should get filled, what would be the best approach?

The implementation eg in bp_demo_unmanaged_root_draft does not seem to be a sensible approach to me.

Thanks for some hints here,

  Wolfgang

[BjoernSchulz]

Hello @WRoeckelein,

as Marian mentioned, is the reported structure to handle messages to the UI, in a case you have some errors in the logic. You have to fill %MSG with a single message oder %OTHERS with more messages, if there is some generic stuff happening and you have more than one message.

Greetings

Björn

[WRoeckelein]

Hi @Marian_Zeis and @BjoernSchulz ,

I know what the structure in general is for.

The question is for feature and authorization specifically. Would a message from here really show up on the UI? If yes, is this eg for feature really sensible?

Regards,

  Wolfgang

[BjoernSchulz]

Hello @WRoeckelein ,

Have tested it in the system. Wenn you load the List Report and Object Page the method is called, but nothing happens. Wenn I click Edit the message from get_global_authorizations is coming up and I can decide, if I want to proceed or stop editing. So it seem to work in "special" cases.

[WRoeckelein]

Hi @BjoernSchulz ,

thanks, I found now some examples in /dmo/bp_travel_d=>lhc_travel->get_global_authorizations and ->get_instance_authorizations esp in the latter method I found this code

APPEND VALUE #( %tky = travel-%tky
                %msg = NEW /dmo/cm_flight_messages(
                                         textid    = /dmo/cm_flight_messages=>not_authorized_for_agencyid
                                         agency_id = travel-AgencyID
                                         severity  = if_abap_behv_message=>severity-error )
                %element-AgencyID = if_abap_behv=>mk-on
               ) TO reported-travel.

which seems to indicate in how to communicate a missing authorization of an authorization object with an authorization Field (AgencyID).

I still would like to read this somewhere more clearer in the documentation, there is some info in https://help.sap.com/docs/abap-cloud/abap-rap/messages , %element is used to relate the message to the UI field(s) (this is why even if the authorization check is for the country code of the Agency, the field used in the message is AgencyId, because this a field of Travel), if the problem is in a child, you also have to fill %path to relate the message to the correct parent entity.

There is also some info in https://help.sap.com/docs/abap-cloud/abap-rap/implementation-contract-feature-control and https://help.sap.com/docs/abap-cloud/abap-rap/implementation-contract-authorization-control however some of the stuff mentioned here is not done in the demos/examples provided by SAP...

Thanks for the help,

  Wolfgang

[Marian_Zeis]

reported is only needed for the communication to Fiori elements.

@BjoernSchulz has some examples here:

https://software-heroes.com/en/blog/abap-rap-messages

[WRoeckelein]

Hi Marian,thanks for the answer, the linked page only deals with actions and validations and not with get_*_features/get_*_authorization.

[Akshath]

If the Travel is open → Delete button is active.

If the Travel is cancelled → Delete button is greyed out, Update button also greyed out.

No messages are shown — just proper enablement/disablement.

CLASS zbp_travel DEFINITION PUBLIC FINAL CREATE PROTECTED.
PUBLIC SECTION.
INTERFACES if_abap_behv_impl.
ENDCLASS.

CLASS zbp_travel IMPLEMENTATION.

METHOD get_instance_features.
LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key>).

" Read status of the current Travel instance
SELECT SINGLE status
FROM ztravel
WHERE travel_id = @<ls_key>-travel_id
INTO @DATA(lv_status).

" Prepare feature result
APPEND VALUE #(
%tky = <ls_key>-%tky
%features-%delete =
COND #( WHEN lv_status = 'O' THEN if_abap_behv=>fc-o-enabled
ELSE if_abap_behv=>fc-o-disabled )
%features-%update =
COND #( WHEN lv_status = 'C' THEN if_abap_behv=>fc-o-disabled
ELSE if_abap_behv=>fc-o-enabled )
) TO result.

ENDLOOP.

" No need to fill reported here!
ENDMETHOD.

ENDCLASS.

Scenario

We still have the Travel entity.
We want to control authorizations:

A user with role TRAVEL_ADMIN → full access (update + delete).

A user with role TRAVEL_VIEWER → read-only, no update or delete.

CLASS zbp_travel DEFINITION PUBLIC FINAL CREATE PROTECTED.
PUBLIC SECTION.
INTERFACES if_abap_behv_impl.
ENDCLASS.

CLASS zbp_travel IMPLEMENTATION.

METHOD get_instance_authorizations.
LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key>).

" Check current user authorization (simplified example)
DATA(lv_is_admin) = cl_auth_check=>is_user_in_role( iv_role = 'TRAVEL_ADMIN' ).
DATA(lv_is_viewer) = cl_auth_check=>is_user_in_role( iv_role = 'TRAVEL_VIEWER' ).

" Prepare authorization result
APPEND VALUE #(
%tky = <ls_key>-%tky
%auth-%update =
COND #( WHEN lv_is_admin = abap_true THEN if_abap_behv=>auth-allowed
ELSE if_abap_behv=>auth-unauthorized )
%auth-%delete =
COND #( WHEN lv_is_admin = abap_true THEN if_abap_behv=>auth-allowed
ELSE if_abap_behv=>auth-unauthorized )
) TO result.

ENDLOOP.

" Again: leave reported empty
ENDMETHOD.

ENDCLASS.