ABAP - BOPF Action
You need additional processes on your data model? Today we show you how to publicize simple actions to the outside world and users of your model.
There should be different actions available on the data model that each user of the BOPF should execute? In today's article, we'll show you what such an action can look like by "a partner is signing". The actions are externally published and collected changes to the data model, which are made available to the user.
Create an action
In the first step, we create the action at the top level, the contract. The reason is that the different partners in the real world also sign on the contract and not on the partner data.
Again name and description must be entered to complete the data. The name of the class can be generated via the suggestion in the context menu (more about this in the investigation). The partner structure should serve as an import parameter because the new partner should sign a contract.
In the final step, we also set a cardinality of the change. There are three options that can be chosen: Work on one node, several nodes or no node. In our case, we only want to work with one contract.
We implement the logic in the new class which implements the interface /BOBF/IF_FRW_ACTION. In the EXECUTE method, the logic of the conversion is developed and all the addressed nodes are processed. A small example for the implementation:
DATA: lt_partners TYPE ztest_t_partners, ls_new TYPE ztest_s_partners, ls_param TYPE ztest_s_partners. eo_message = /bobf/cl_frw_factory=>get_message( ). IF lines( it_key ) <> 1. et_failed_key = it_key. eo_message->add_message( EXPORTING is_msg = VALUE #( msgty = 'E' msgid = 'ZTEST_MSG' msgno = '003' ) ). RETURN. ENDIF. ASSIGN is_parameters->* TO FIELD-SYMBOL(<ls_param>). IF sy-subrc = 0. ls_param = CORRESPONDING #( <ls_param> ). ELSE. et_failed_key = it_key. eo_message->add_message( EXPORTING is_msg = VALUE #( msgty = 'E' msgid = 'ZTEST_MSG' msgno = '004' ) ). RETURN. ENDIF.
The first part of the coding we build the message instance, because here we validate further data and check whether data has been transferred. If more than one key has been handed over or the partner data is missing, we will trigger a corresponding error.
io_read->retrieve_by_association( EXPORTING iv_node = zif_tst_bopf_c=>sc_node-contract it_key = it_key iv_association = zif_tst_bopf_c=>sc_association-contract-partners iv_fill_data = abap_true IMPORTING et_data = lt_partners ). READ TABLE lt_partners WITH KEY rltyp = ls_param-rltyp partner = ls_param-partner TRANSPORTING NO FIELDS. IF sy-subrc = 0. et_failed_key = it_key. eo_message->add_message( EXPORTING is_msg = VALUE #( msgty = 'E' msgid = 'ZTEST_MSG' msgno = '002' ) ). RETURN. ENDIF. ls_new-partner = ls_param-partner. ls_new-rltyp = ls_param-rltyp. io_modify->create( EXPORTING iv_node = zif_tst_bopf_c=>sc_node-partners is_data = REF #( ls_new ) iv_assoc_key = zif_tst_bopf_c=>sc_association-partners-to_parent iv_source_node_key = zif_tst_bopf_c=>sc_node-contract iv_source_key = it_key[ 1 ]-key iv_root_key = it_key[ 1 ]-key IMPORTING ev_key = DATA(ld_key) ).
In the second part, we read out all the partner data for the association agreement and validate the current partners against the new one. If all goes well, we will add the new record to the database and sign the contract.
For the test of the action we want to show you an implementation in a program that does not need BOBT and what it would probably look like in the real world:
DATA(lo_tmgr) = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ). DATA(lo_smgr) = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( zif_tst_bopf_c=>sc_bo_key ). DATA(ls_parameters) = VALUE ztest_s_partners( rltyp = 'BUP001' partner = '0000888002' ). lo_smgr->do_action( EXPORTING iv_act_key = zif_tst_bopf_c=>sc_action-contract-partner_sign it_key = VALUE #( ( key = '42D85ED56C0A1ED9B7D7FC8BAC534005' ) ) is_parameters = REF #( ls_parameters ) IMPORTING et_failed_key = DATA(lt_failed) eo_message = DATA(lo_msg) ). IF lt_failed IS INITIAL. lo_tmgr->save( IMPORTING ev_rejected = DATA(ld_reject) et_rejecting_bo_key = DATA(lt_keys) ). ENDIF. IF ld_reject = abap_true. lo_tmgr->cleanup( ). ENDIF.
In our example, the data and the entry to be changed are hard-coded, here a dynamic determination should be performed and read via the contract. If the action was successful and the table lt_failed is empty, the data can be persisted to the database.
In transaction BOBT, after loading a contract, the action can be found in the upper context menu, where all available actions are listed.
After execution of the action, a pop-up appears with the expected import data that can be filled or left empty for testing. After confirming this popup, the action will be executed and iterated through your code.
If, for example, a partner record is already included, an error message occurs as with the validations. The buttons behind the message can also be used to navigate to the source code where the message was generated. Since we left nodes and keys blank when generating the message, the information is missing in the display.
Providing actions for the data model should no longer be a problem for you. With our tip you can control the data in the model depending on the action, adjust and cause state changes.