08-12-2015 9:01 AM
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
08-13-2015 2:45 PM
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.
08-13-2015 2:45 PM
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.
08-13-2015 5:46 PM
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:
Cheers,
Oliver
08-14-2015 11:32 AM
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