I am exploring Draft based Fiori list report applications and usage of re-use components in Fiori List Report.
One of the most common requirement in Transactional List Report applications is to determine the values of fields or set of fields based on other fields. So how can we achieve this. Yes BOPF determination is the answer.
But there is an issue which developers come across. “I have done the determination. My determination is taking place successfully but the data is not reflecting in UI“.
This behavior of fields getting influenced based on other field content is named as Side Effects.(Name given by SAP)
Standard SAP documentation says.. If a user changes the content of a field, this change could potentially influence other fields on the UI.This system behavior is called a side effect.
I will put this blog content into below sections.
Derive the partner functions based on the customer and sales area information.
In this blog I will try to explain the steps involved in achieving this requirement. Creating an application from scratch is not part of this blog.
In the Header section, I gave Customer details and Sales Area information and the expectation is to have the derived partners under the section “Partners”
Partner section : Currently Empty.
Two questions that popped up
- Is my determination logic triggering?
- Are the determined partner nodes being added as child nodes.
Straight away placed an external break point and both my questions were answered. The create method is creating the partner nodes.
Debugging and UI rendering:
But is the application completely ignoring the changes? No. I can see the derived entries in two cases.
- If I click on ‘Create’ button
2.Moving out of the draft entry and coming back to object page.
After performing either one of the above steps I can see the partner information rendered on screen
But this is not what we are looking for. We need to have the partner information as and when we move from the sales area fields or by pressing ‘Enter’.
This is where the Side Effects comes into picture. Though the determination logic in place, the UI should be aware of the influence the changed fields brings on to the screen.
Side effects can be incorporated in two ways.
- Code based annotations in DEFINE method of MPC EXT class.
- Local Annotations.
I took the second approach and created local annotations for the fields.
- Choose the annotation ‘SideEffects’
2. Choose the source properties. In my case the source properties are Sold to Party/Ship to Party, Sales Org, Distribution Channel and Division.
3.Choose the Item and select the properties
Repeat the step 3 for all properties.
4. Choose the Target property/entity which gets influenced by the source fields. In my case its the partner entity
5. Refer to the target property/entity. In my case its to_Partner
That’s it!! Create an entry, key in the fields for which you want the determination to trigger.
Code for Determination
Below is the code for BOPF determination.
- Read the Header node details
- Get the sales area and customer information to derive the partner functions
- Loop of the partner functions and create nodes for partners using io_modify->create( ).
** Get the Header Information. In my case the its Sales Order Header io_read->retrieve( EXPORTING iv_node = zif_i_salesordertp_c=>sc_node-z_i_salesordertp it_key = it_key iv_fill_data = abap_true IMPORTING et_data = lt_header ). READ TABLE lt_header INDEX 1 REFERENCE INTO DATA(lr_header). lv_header_key = lr_header-key. **Derive the partner functions CALL FUNCTION 'CUSTOMER_PARTNERFS_GET' EXPORTING iv_kunnr = lr_header->soldtoparty iv_vkorg = lr_header->salesorganization iv_vtweg = lr_header->distributionchannel iv_spart = lr_header->organizationdivision TABLES et_e1knvpm = lt_partners. ls_partner-root_key = lr_header-key. ls_partner-parent_key = lr_header-key. ls_partner-salesorder = lr_header-salesorder. LOOP AT lt_partners INTO DATA(ls_partners). ls_partner-customer = ls_partners-kunn2. ls_partner-partnerfunction = ls_partners-parvw. **Create the entries for Partner Node which is a child node for Sales Order Node io_modify->create( EXPORTING iv_node = zif_i_salesordertp_c=>sc_node-z_i_hpartner_tp is_data = REF #( ls_partner ) iv_assoc_key = zif_i_salesordertp_c=>sc_association-z_i_salesordertp-_partner iv_source_node_key = zif_i_salesordertp_c=>sc_node-z_i_salesordertp iv_source_key = lv_header_key IMPORTING ev_key = DATA(lv_item_key) ). ENDLOOP. io_modify->update( iv_node = zif_i_salesordertp_c=>sc_node-z_i_salesordertp iv_key = lv_header_key is_data = lr_header ).
I would also like to share two of the methods to check which property has changed in the node.
**Gets the change object for the given node keys io_read->compare( EXPORTING iv_node_key = is_ctx-node_key it_key = it_key iv_fill_attributes = abap_true * iv_scope = /bobf/if_frw_c=>sc_scope_local IMPORTING eo_change = DATA(lo_change) ). **From the change object, get the properties which underwent a change. LT_CHANGE-ATTRIBUTES hold the **changed property names lo_change->get( EXPORTING iv_sorted = /bobf/if_frw_c=>sc_change_sort_key iv_no_load = abap_true IMPORTING et_change = DATA(lt_change) et_content_change = DATA(lt_con_change) ).
Side Effect Annotations:
Also please refer the standard application “Manage Purchase Order” which itself is an excellent guide for Fiori List Report. This application uses the components for Attachments, Standard Text(Notes) and Pricing Conditions.
Thanks to Mahesh Kumar Palavalli for hinting me to write a blog post on this topic.
Finally, please share your valuable feedback.