To make the Action effective you have to implement the class. Therefore double click on the class ZCL_CUST_A_LOCK_BANK_ACCOUNT and follow the popups to create the class. Actions have to implement interface /BOBF/IF_FRW_ACTION which contains the following methods:
RETRIEVE_DEFAULT_PARAMETERS is used to get context dependent default
values for the parameters of an action.
PREPARE method is used to adjust the set of node instances the action is invoked on.
This includes removing and adding instances.
EXECUTE method implements the action.
In this tutorial you create an action to set the lifecycle status to locked, the coding we have used is as shown in the figure
METHOD /bobf/if_frw_action~execute. DATA:
lt_bank_details TYPE zmy_t_cust_bank_details, lt_chg_fields TYPE /bobf/t_frw_name,
lr_bank_details TYPE REF TO zmy_s_cust_bank_details. io_read->retrieve( EXPORTING iv_node = is_ctx-node_key it_key = it_key iv_fill_data = abap_true IMPORTING et_data = lt_bank_details ). APPEND zif_cust_zmy_customer_c=>sc_node_attribute-bank_details- lc_status TO lt_chg_fields.
LOOP AT lt_bank_details REFERENCE INTO lr_bank_details. lr_bank_details->lc_status = '01'. " locked io_modify->update( EXPORTING iv_node = is_ctx-node_key iv_key = lr_bank_details->key is_data = lr_bank_details it_changed_fields = lt_chg_fields ). ENDLOOP.
10.
Associations
BO nodes are linked by associations. BOPF supports different association types. The most important one is the Composition association by which the BO node hierarchy is defined. When you create a child node BOPF automatically creates a composition association between the parent and the child node. In addition it creates two further associations: one from the child node to the parent node ( TO_PARENT ) and one up to root node (TO_ROOT ). The composite association by default gets the name of the created node. Besides composition associations BOPF supports:
Foreign Key associations: The key of the target node instance is contained in an
attribute of the source node.
Reverse Foreign Key associations : The key of the source node is contained in an
attribute of the target node. A Reverse Foreign Key association determines the keys of those target nodes which contain the source node key as foreign key. The BOPF composition association belongs to this type.
Specialization associations: A Specialization is a “filtered composition”. It filters the
“composition” by some constant values (e.g. role code). At runtime the check is performed against a field in the target node.
Reverse Specialization associations: Is a kind of filtered Foreign Key association.
The target node key is contained in a specialized source node. This association determines the target node key contained in the specialized source node.
Cross-BO associations: The target node of a Cross-BO-Association is located on
another BO then the source node.
Composition to Delegated Node: The composition to the delegated node is a special
composition.
BOPF uses Association Binding in order to resolve associations. This means no implementation is needed when Association Binding is used. Duri ng the binding you maintain those attributes which need to be evaluated in order to identify the target node keys. The following association types support Association Binding: Composite, Association to parent, Association to root, Specializations, Reverse Specializations, Foreign Key Associations, Reverse Foreign Key Associations, Cross-BO-Assoications.
Each association has a cardinality. BOPF supports the following cardinalities [1:0..1], [1:1], [1:0..n] and [1:1..n]. BOPF does not checked automatically whether a node meets the
check. However, for mandatory child nodes – cardinalities: [1:1] or [1:1..n] – you can reuse the library validation /BOPF/CL_LIB_V_MANDATORY_NODES(out of the BOPF library). More informations about associations can be found in the following document:
https://wiki.wdf.sap.corp/wiki/download/attachments/223184988/How+to+implement+a+BO PF+Business+Object+in+the+Business+Suite.doc?version=1
10.1. Association to a Delegated node
BOPF distinguishes between Business Objects and so called Dependent Object (DO). A Dependent Object is something different than a Business Object. It has its own model but it can only be used by embedding it into a Business Object. You can’t instantiate a Dependent
Object outside of a Business Object. A couple of reusable Dependent Objects are available in software component BS_FND: Text Collection, Attachment Folder and Address.
When you embed a Dependent Object into a Business Object (=Host Business Object) the Dependent O bject’s model gets part of the Business Object’s model. Thus the Business Object consumer accesses the nodes of the Dependent Object through the hosting Business Object. However, BOPF only merges the model of the Dependent Object into the model of the Business Object at runtime. At design time in the BOPF Configuration UI the models are not merged. This process is called the Blackbox Delegation, that is, the model information for the Dependent Objects are only known at runtime and not during design time of the host object.
In order to embed a Dependent Object into a Business Object you have to create a Delegated Node in the Business Object. During runtime, BOPF replaces the Delegated Node with the complete subset of the Dependent Object’s. At runtime, BOPF delegates the calls to the Dependent Objects node to the Dependent Object.
In this tutorial you will embed the Text Collection Dependent Object into the Customer.
10.2. Creating Association to Dependent Object
Within this section you will embed the Dependent Object /BOBF/TEXT_COLLECTION into you Customer BO. Thus open your Customer BO in BOPF and select the root node in the Business Object Detail Browser. From the context menu select the entry as shown in the following figure.
This command will create a Delegated Node directly underneath the root node. In the details screen for the Delegated Node maintain the following fields:
Node Name: Names of the Delegated Node. Use the name Note.
Node Prefix: The node prefix is used by BOPF at runtime in order to identify the
Dependent Object which is called by a consumer. Example: The Collection used here could additionally be embedded underneath the Bank Details node. Let’s assume this for a while. When you access the embedded Text Collection via the BOPF APIs you need to tell BOPF which embedded Text Collection you want to access – the one underneath the Root node or the one underneath the Bank Details node. You use the Delegated Node to provide BOPF this information. Thus both embeddings of the Text Collection need to have a Node Prefix, to be more precise a different Node Prefix.
Description: Maintain “Customer note”
Referenced Business Object: Select /BOBF/TEXT_COLLECTION
When you create the Delegated Node as described above BOPF automatically creates the required association to the root node of the Dependent Object. This is possible since the Text Collection Dependent Object supports a standard linkage to a hosting Business Object. The standard linkage is supported for each Dependent Object that fulfills the following requirement: The embedded Dependent Object must have an alternative key on its root node that uses /BOBF/S_LIB_K_DELEGATION as DATA_TYPE and /BOBF/T_LIB_K_DELEGATION as DATA_TABLE_TYPE. Furthermore this alternative
key must be set to "Not-unique" to enable one-to-many usages of it. Further details about the delegation concept can be found here:
https://wiki.wdf.sap.corp/wiki/display/BOPF/BS+BOPF+FAQ+and+Features#BSBOPFFAQa ndFeatures-Delegation
Note: Don’t forget to regenerate the BOPF constant interface every time when you add or delete something in the BO.
Afterwards you can test the embedded Dependent Object in the Test Tool. For this purpose open the Test Tool (F8) for the Customer and create a new customer or select an existing one. Navigate to node Root Note and press the Create Button. This will create the root node of
the Text Collection (you don’t have to maintain anything here). Subsequently navigate to the content node and maintain a text.
11.
Testing the Business Object
There are two methods of testing the Business Object in the BOPF 1. Using the test tool
2. Using reports
You can test the Business Object using the test tool by pressing F8 in the Business Object Configuration UI by which a separate SAP GUI window is opened showing the test tool (transaction /BOBF/TEST_UI). This method was used several time trough out the tutorial. The other method is using a manually written report. The report accesses the Business Object via the Service Manager and the Transaction Manager. They provide the APIs you need to access a Business Object from any consumer to trigger queries, to retrieve data, to modify data and to execute actions. By triggering these operations, the determinations created in the design time will get executed.
The first report performs a query on the Customer Root node and retrieves the Bank Details for each Root node in the result set.
* Data declaration DATA:
lo_customer TYPE REF TO /bobf/if_tra_service_manager, lt_root_key TYPE /bobf/t_frw_key,
lt_root TYPE zmy_t_cust_root,
lt_bank_detail TYPE zmy_t_cust_bank_details. * Get Service Manager for Customer BO
* - use the constant interface maintained in the BO
lo_customer = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = zif_cust_zmy_customer_c=>sc_bo_key
).
* Trigger the query on the root node lo_customer->query( EXPORTING iv_query_key = zif_cust_zmy_customer_c=>sc_query-root- select_by_elements iv_fill_data = abap_true IMPORTING et_key = lt_root_key et_data = lt_root ).
* Retrieve Bank Details node belonging to the queried root nodes lo_customer->retrieve_by_association(
EXPORTING
The next report creates a Customer Root Node.
* data declaration DATA:
lo_transaction_mgr TYPE REF TO /bobf/if_tra_transaction_mgr, lo_customer TYPE REF TO /bobf/if_tra_service_manager, lt_root TYPE zmy_t_cust_root,
ls_root TYPE zmy_s_cust_root,
lr_root TYPE REF TO zmy_s_cust_root, lt_mod TYPE /bobf/t_frw_modification, ls_mod TYPE /bobf/s_frw_modification. * Set customer data
ls_root-customer_id = '4711'. ls_root-first_name = 'Max'.
ls_root-last_name = 'Mustermann'. GET REFERENCE OF ls_root INTO lr_root. * Fill modification structure
ls_mod-key = /bobf/cl_frw_factory=>get_new_key( ). ls_mod-node = zif_cust_zmy_customer_c=>sc_node-root. ls_mod-change_mode = /bobf/if_frw_c=>sc_modify_create.
ls_mod-data = lr_root. APPEND ls_mod TO lt_mod.
* Get Service Manager for Customer BO
* - use the constant interface maintained in the BO
lo_customer = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = zif_cust_zmy_customer_c=>sc_bo_key
).
* Call the Service Manager to create the customer lo_customer->modify(
EXPORTING
it_modification = lt_mod ).
* Get the Transaction Manager to save the changes
lo_transaction_mgr = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manage r( ).
* Save the changes
lo_transaction_mgr->save( ).
The last report calls the action LOCK_BANK_ACCOUNT on all Bank Detail nodes belonging to queried root nodes.
* Data declaration DATA:
lo_customer TYPE REF TO /bobf/if_tra_service_manager, lt_root_key TYPE /bobf/t_frw_key,
lt_bank_detail_key TYPE /bobf/t_frw_key. * Get Service Manager for Customer BO
* - use the constant interface maintained in the BO
lo_customer = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = zif_cust_zmy_customer_c=>sc_bo_key