Tuesday, 11 February 2020 20:58

Access Gateway exposed CDS within the ABAP stack itself

Written by https://blogs.sap.com/2020/02/12/access-gateway-exposed-cds-within-the-abap-stack-itself/
Rate this item
(0 votes)

Introduction

At a development team I work with we make extensively use of CDS views. Not only for reporting purposes or exposing data to HTML5 frontend applications, but also for updating,

and I must say that the Gateway options in combination with the BOBF/SADL framework appears to be a rock solid platform that is also very easy to learn and fun to program with.

To get clear what context I am talking about:

  • ABAP CDS views
    • with ObjectModel.modelCategory is #BUSINESS_OBJECT
    • with ObjectModel.writeActivePersistency set to a database table
    • with ObjectModel.createEnabled (updateEnabled, deleteEnabled) set to true, so with updating logic in mind
  • Service generation through SEGW
  • Hook methods for data validation, determinations and so as provided for business objects by BOBF/SADL framework (transaction BOBX)

Now, the issue I came across is that updating through Gateway works fine, but the question came up what to do for an update from that very same ABAP system, for instance with batch processes. Searching on the web I have seen some workarounds or calling BOBF Api’s using the /BOBF/IF_TRA* framework. Maybe I missed something there, but I could not get that working for SADL entities. I don’t like other options like calling CL_HTTP_CLIENT either, so I searched for another way.

Why not use other ways to update my (non-standard SAP) data? Because I do not want to have multiple validation or update logic. Why use ABAP anyway at this era? Perhaps I’ll make you another blog on that.

For this blog, I only take the standard methods create, update, read set and delete into account, which leaves specific actions or complicated stuff like reading by associations out of scope. For the readers sake I did not pay any attention to proper exception handling

Scanning the Gateway service classes

Looking the way Gateway handles SADL requests can be started in two ways

  • By setting an external break-point in the BOBF hook methods
  • By checking the <SVCNAME>_DPC class

Both lead to the methods from interface IF_SADL_GW_DPC_UTIL implemented in <SVCNAME>_DPC. Within this part of the implementation we find methods like

  • if_sadl_gw_dpc_util~get_dpc( )->create_entity
  • if_sadl_gw_dpc_util~get_dpc( )->get_entity
  • and the likes

Focussing on what is happening inside these, in a private method _init, we find that processing at least requires:

  • An entity mapper
    subclass of cl_sadl_mp_entity, at least provinding an (empty) implementation of method get_sadl_definition( )
  • A runtime, instantiated by a factory within cl_sadl_entity_api_factory
  • For queries, a condition provider
    a class implementing at least a method for if_sadl_condition_provider~get_condition( )
  • A SADL transaction manager
    a subclass of cl_sadl_entity_transactional that has not to implement nothing but is not an abstract

Starting with a getlist

From a functional point of view definitely not interesting, since we have OpenSQL providing us access to CDS views. However pleasant as a starter. We use a simple ABAP report form as example with some local classes and without any global variables or includes.

First, we need te SADL entity mapper. As said, the get_sadl_definition( ) has to be redefined and implemented, but does not have anything to do.

class lcl_mp_entity definition inheriting from cl_sadl_mp_entity. protected section. methods: get_sadl_definition redefinition. endclass. class lcl_mp_entity implementation. method get_sadl_definition. " Any implementation if necessary endmethod. endclass.

Apparently the way to pass conditions (select-options) is the most difficult part here, and is only necessary for reading (and not even that). For the implementation I used code of cl_sadl_cond_grouped_ranges->if_sadl_condition_provider~get_condition( ) as example.  Since this is quite a lot of code I put this below as extra.

Calling the SADL classes looks pretty simple if set in ABAP code:

 try. " Preparation with service name data(lr_iomp) = new lcl_mp_entity( iv_uuid = 'ZPAMV2' iv_timestamp = new zcl_zpamv2_mpc( )->get_last_modified( ) ). data(lr_sapi) = cl_sadl_entity_api_factory=>create( cast #( lr_iomp ) ). " Initialize runtime with interface view name data(lr_runt) = lr_sapi->get_runtime( 'ZI_PAM_ROLE' ). " Set scope for selected fields (from CDS view), and flag data to be fetched data ls_parameters type if_sadl_query_engine_types=>ty_requested. ls_parameters-fill_data = abap_true. append: 'FIELD1' to ls_parameters-elements, 'ETC' to ls_parameters-elements. " Get the data data lt_data type standard table of zi_pam_role. lr_runt->fetch( exporting is_requested = ls_parameters importing et_data_rows = lt_data ). catch cx_root into data(lx). ... . endtry.

ZPAMV2 is the Gateway service in this example. ZI_PAM_ROLE is the CDS (interface-) view we wish to read. The data from the view is available after the fetch. Note that the timestamp comes from the service -MPC class (In this case, ZCL_ZPAMV2_MPC), and is a non static member.

Creating a record

For executing updates with the SADL interfaces, we need an transaction manager, a non-abstract subclass of cl_sadl_entity_transactional, which does not require any implementation.

class lcl_sadl_trans definition inheriting from cl_sadl_entity_transactional. endclass.

It can be instantiated directly by passing entity type SADL and an entity-id <SERVICENAME>~<ENTITYNAME>.

The create itself is implemented in the SADL runtime method if_sadl_entity_transactional~create_single which accepts a normal structure of the ABAP type of the CDS interface view. Code snippet:

 data(lr_iomp) = new lcl_mp_entity( iv_uuid = 'ZPAMV2' iv_timestamp = new zcl_zpamv2_mpc( )->get_last_modified( ) ). data(lr_sadl_transaction) = new lcl_sadl_trans( iv_entity_type = 'SADL' " TYPE SADL_ENTITY_TYPE iv_entity_id = 'ZPAMV2~ZI_PAM_ROLE' " SADL_ENTITY_ID ). data(lr_sapi) = cl_sadl_entity_api_factory=>create( cast #( lr_iomp ) ). data(lr_runt) = lr_sapi->get_runtime( 'ZI_PAM_ROLE' ). data ls_role type zi_pam_role. ls_role-field1 = 'VALUE'. " Just values for a record to create ls_role-etc = 'OTHERVALUE'. lr_runt->if_sadl_entity_transactional~create_single( importing ev_failed = data(lv_updatefailed) changing cs_entity_data = ls_role ).

The data supplied to the create is returned, and enriched by the logic you have implemented in your BOBF determinations such as number ranges.

If returned value ev_failed is false you can commit the update, otherwise rollback. This requires access to the transaction manager.

 data(lr_trans_man) = cl_sadl_transact_manager_fctr=>get_transaction_manager( ). if lv_updatefailed = abap_false. lv_updatefailed = lr_trans_man->save( ). " Commit the changes else. lr_trans_man->discard_changes( ). " Rollback endif.

Error messages, for instance those you have implemented in your BOBF validations can be fetched with the SADL message handler. Simplified snippet:

 if lv_updatefailed eq abap_true. lr_trans_man->get_message_handler( )->get_messages( exporting iv_severity = if_sadl_message_handler=>co_severity-error importing et_messages = data(lt_message) ). loop at lt_message assigning field-symbol(<message>). message id <message>-message->t100key-msgid type <message>-severity number <message>-message->t100key-msgno with cl_sadl_entity_util=>message_value( iv_attr = <message>-message->t100key-attr1 io_message = <message>-message ) " V2, V3 and V4 likewise . endloop.

Other updates

Code snippet for delete. Assume field1 is the key field for the entity.

 data(ls_key_value) = value ZI_PAM_ROLE( field1 = '040000002514' ). lr_runt->if_sadl_entity_transactional~delete_single( exporting is_key_values = ls_key_value importing ev_failed = data(lv_updatefailed) ).

Code snippet for change. it_updated elements is a table with fields to update, so the update behaves like a patch. Field1 is again the key.

 data(ls_role) = value zi_pam_role( field1 = '040000002514' etc = 'YD' ). lr_runt->if_sadl_entity_transactional~update_single( exporting is_entity_data = ls_role it_updated_elements = value #( ( |ETC| ) ) importing ev_failed = data(lv_updatefailed) ).

Multiple updates

Create, delete en update offers single line and multi line mode. An example for create multi line

 data lt_table type table of zi_pam_role. " Fill data r_sadl_runtime->if_sadl_entity_transactional~create( importing et_failed = data(lt_updatefailed) changing ct_entity_data = lt_table ).. data(lr_trans_man) = cl_sadl_transact_manager_fctr=>get_transaction_manager( ). if lines( lt_updatefailed ) > 0. " Rollback

Note that the failed is a table now. With update it_updated_elements_per_tabix is a list of a field set list

Get to proper classes

These examples are coded within an ABAP report. Off course you want this in an OO wrapper. I will not work this out here but I can imagine some structure containing three levels.

  1. A super class to isolate the usage of the SADL classes from your consumers
  2. Service dependent sub classes of that class, as service name is the main divider
  3. Entity dependent sub classes of the service dependent class

Final thoughts

I have not been able to match this solution with an ABAP NW752 stack, so maybe there are some SAP developments not taken into account here. Secondly, I don’t like the instantiation of the MPC class to get the timestamp. It seems too much for too little. I also have some doubts with the  <service> – tilde – <entity> thing when creating the transaction manager. It does not look that durable; what if someone at SAP decides might decide to change the tilde into a dash or a dot?

Still, programming this way is very easy to learn and provides a very good runtime performance.  Any comments or questions on this subject will be highly appreciated if you post them below.

Extra:

Adding conditions to your query

class lcl_cond definition. " Example taken from CL_SADL_COND_GROUPED_RANGES public section. interfaces: if_sadl_condition_provider. methods: constructor importing it_ranges type if_sadl_cond_provider_grpd_rng=>tt_grouped_range iv_use_placeholders type abap_bool default abap_false. protected section. data mt_ranges type if_sadl_cond_provider_grpd_rng=>tt_grouped_range. data mt_sadl_condition type if_sadl_query_engine_types=>tt_complex_condition. data mt_elements type if_sadl_query_engine_types=>tt_element_info. data mv_use_placeholders type abap_bool. endclass. class lcl_cond implementation. method if_sadl_condition_provider~get_condition. if mt_ranges is not initial and ( mt_sadl_condition is initial or it_elements <> mt_elements ). mt_elements = it_elements. if mv_use_placeholders = abap_false and it_elements is not initial. data lt_elements like it_elements. loop at mt_ranges assigning field-symbol(<s_range>). read table it_elements with key id = <s_range>-field_path assigning field-symbol(<s_element>). if sy-subrc = 0. insert <s_element> into table lt_elements. endif. endloop. cl_sadl_condition_generator=>get_field_descr( exporting it_elements = lt_elements importing et_field_descriptors = data(lt_field_descriptors) ). endif. cl_sadl_condition_generator=>convert_ranges_to_conditions( exporting it_ranges = mt_ranges it_field_descriptors = lt_field_descriptors iv_use_placeholders = mv_use_placeholders importing et_conditions = mt_sadl_condition ). endif. et_sadl_condition = mt_sadl_condition. endmethod. method constructor. * check_range_consistency( it_ranges ). mt_ranges = it_ranges. "#EC CI_CONV_OK mv_use_placeholders = iv_use_placeholders. clear mt_sadl_condition. endmethod. endclass. " In your method fetching the data " Initialize runtime with interface view name data(lr_runt) = lr_sapi->get_runtime( 'ZI_PAM_ROLE' ). " Set (optional query conditions). Note the simple implementation of class lcl_cond lr_runt->if_sadl_query_fetch~register_condition_provider( new lcl_cond( value #( ( column_name = 'PROJECTID' rule_group = 0 field_path = 'PROJECTID' " Just a field from CDS view t_selopt = value #( ( sign = 'I' " Range options option = 'EQ' " low = '000001001366' ) ) ) " Just a value as example ) ) ). " Set scope for selected fields (from CDS view), and flag data to be fetched data ls_parameters type if_sadl_query_engine_types=>ty_requested.
Read 7 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.