Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Determination attribute assignments

Former Member
0 Kudos

Hi,

I was wondering how the attribute assignment checkboxes of the request nodes for a determination work. Can these checkboxes be used to define which attributes have to be changed to trigger the determination?

When I test this it seems that changing attributes which are not selected (e.g. currency) also trigger the determination.

In the determination's check_delta method, we can use io_read->compare method to retrieve the changed attributes.  Is it possible to retrieve the selected attributes of the determination's configuration instead of having them hard coded? I've tried with the following, but I don't find the selected attributes this way.


DATA(lr_nd_conf) = /bobf/cl_frw_factory=>get_configuration( iv_bo_key = is_ctx-bo_key ).

     lr_nd_conf->get_node(

       EXPORTING iv_node_key = is_ctx-node_key

IMPORTING es_node     = DATA(ls_node) ).

Thanks in advance!

KR,

Bjorn

1 ACCEPTED SOLUTION

former_member190794
Active Participant
0 Kudos

Hello Bjorn,

we implemented BOPF not to check the requested attributes due to performance concerns. In most cases it is much more performant to trigger more coarse grained instead of evaluating the attributes. However, some business determinations require to trigger on attribute level. Thereto you have to manually implement the CHECK_DELTA method.

In the internal BOPF transaction we propse the coding, however it is very easy to take it over in case of using BOBX from the end of the posting. Just adapt the attributes names.

Regarding your questions about using the meta information: At the moment, we do not take over the trigger attributes into our shared memory as there is no inbuilt BOPF runtime evaluation. Thus the configuration does not provide any information here.

Best regards

Tilmann

Here is the sample code for your convenience:

  DATA lo_change   TYPE REF TO /bobf/if_frw_change.
  DATA ls_change   TYPE        /bobf/s_frw_change.
  DATA lt_change   TYPE        /bobf/t_frw_change.
  DATA ls_key      TYPE        /bobf/s_frw_key.

* check changed attributes of own trigger node

  io_read->compare(
    EXPORTING
      iv_node_key        = is_ctx-node_key
      it_key             = ct_key
      iv_fill_attributes = abap_true
    IMPORTING
      eo_change          = lo_change ).

* get relevant changes
  lo_change->get(
    EXPORTING
      iv_sorted  = /bobf/if_frw_c=>sc_change_sort_key
     iv_no_load = abap_true
    IMPORTING
      et_change  = lt_change ).

* compare relevant attributes
  LOOP AT ct_key INTO ls_key.
    READ TABLE lt_change INTO ls_change BINARY SEARCH
      WITH KEY node_key = is_ctx-node_key
               key      = ls_key-key.
    IF sy-subrc <> 0. "should not happen
      DELETE ct_key.
      CONTINUE.
    ENDIF.

    READ TABLE ls_change-attributes TRANSPORTING NO FIELDS
      WITH KEY table_line = zif_ti_trigger_attr_c=>sc_node_attribute-root-attribute_2. "#EC CI_STDSEQ
    IF sy-subrc = 0.
      CONTINUE.
    ENDIF.

    READ TABLE ls_change-attributes TRANSPORTING NO FIELDS
      WITH KEY table_line = zif_ti_trigger_attr_c=>sc_node_attribute-root-attribute_1. "#EC CI_STDSEQ
    IF sy-subrc = 0.
      CONTINUE.
    ENDIF.

    DELETE ct_key.

  ENDLOOP.

3 REPLIES 3

former_member190794
Active Participant
0 Kudos

Hello Bjorn,

we implemented BOPF not to check the requested attributes due to performance concerns. In most cases it is much more performant to trigger more coarse grained instead of evaluating the attributes. However, some business determinations require to trigger on attribute level. Thereto you have to manually implement the CHECK_DELTA method.

In the internal BOPF transaction we propse the coding, however it is very easy to take it over in case of using BOBX from the end of the posting. Just adapt the attributes names.

Regarding your questions about using the meta information: At the moment, we do not take over the trigger attributes into our shared memory as there is no inbuilt BOPF runtime evaluation. Thus the configuration does not provide any information here.

Best regards

Tilmann

Here is the sample code for your convenience:

  DATA lo_change   TYPE REF TO /bobf/if_frw_change.
  DATA ls_change   TYPE        /bobf/s_frw_change.
  DATA lt_change   TYPE        /bobf/t_frw_change.
  DATA ls_key      TYPE        /bobf/s_frw_key.

* check changed attributes of own trigger node

  io_read->compare(
    EXPORTING
      iv_node_key        = is_ctx-node_key
      it_key             = ct_key
      iv_fill_attributes = abap_true
    IMPORTING
      eo_change          = lo_change ).

* get relevant changes
  lo_change->get(
    EXPORTING
      iv_sorted  = /bobf/if_frw_c=>sc_change_sort_key
     iv_no_load = abap_true
    IMPORTING
      et_change  = lt_change ).

* compare relevant attributes
  LOOP AT ct_key INTO ls_key.
    READ TABLE lt_change INTO ls_change BINARY SEARCH
      WITH KEY node_key = is_ctx-node_key
               key      = ls_key-key.
    IF sy-subrc <> 0. "should not happen
      DELETE ct_key.
      CONTINUE.
    ENDIF.

    READ TABLE ls_change-attributes TRANSPORTING NO FIELDS
      WITH KEY table_line = zif_ti_trigger_attr_c=>sc_node_attribute-root-attribute_2. "#EC CI_STDSEQ
    IF sy-subrc = 0.
      CONTINUE.
    ENDIF.

    READ TABLE ls_change-attributes TRANSPORTING NO FIELDS
      WITH KEY table_line = zif_ti_trigger_attr_c=>sc_node_attribute-root-attribute_1. "#EC CI_STDSEQ
    IF sy-subrc = 0.
      CONTINUE.
    ENDIF.

    DELETE ct_key.

  ENDLOOP.

0 Kudos

Dear Bjorn,

as usual there's not much to write after Tilmann has answered, but I wanted to respond to a non-asked question: "Then why the hell is there an option to model the attributes?"

There are two answers to this question:

  • "It makes the model readable". Even without looking at the implementation but only at the model, I can get an idea about the determination' responsibility. This only remains true if the one implementing the class knows this too
  • BOPF will interpret the attribute assignment for after-loading-determinations: Only those determinations will be executed which have got matching attribute assignments with the ones  requested with the retrieve or retrieve_by_association core-services.

Cheers,

Oliver

Former Member
0 Kudos

Hello,

Thank you both for your responses! I was indeed already using code like the sample code provided, but thanks anyway for the confirmation and extra information!  

Kind regards,

Bjorn