ABAP - BOPF Action

Table of contents

• Create an action
• Implementation
• Report
• Test
• Conclusion

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.

 

Implementation

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.

 

Report

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.

 

Test

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.

 

Conclusion

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.