BOL programmers will, no doubt, be familiar with the GET_PARENT method. This method will return the parent entity of the current BOL entity. It is very convenient and used often. But, are you aware of the potential pitfall in using this method?
As you may be aware of, there may be multiple "paths" in a BOL model to reach a particular BOL object. For example, consider the BOL model "BT". A BTAdminI object may be reached via the relationship
BTItems--(BTOrderItemAll)-->BTAdminI
In a suitable scenario, it may also be reached as
BTAdminI--(BTItemSubItem)-->BTAdminI.
In the first case, the parent object would be of type BTItems. Whereas in the second, the parent object would be a BTAdminI object.
Now, the GET_PARENT method returns only the cached parent entity. That is, based on the most recent relationship used to obtain the entity. If your code assumes that it will get hold of a particular parent object using this method, it may fail in certain circumstances.
Let me cite an issue that we faced in our project. Our users complained one day that they got mismatched information when they tried to maintain prices from the Item view(BT131QI_SLSQ). The problem was with a standard code block in the custom controller (BT131QI_SLSQ/CuCoCondSet). Below is the code block from the ON_NEW_FOCUS method of the CONDSET context node.
* get collection of dependent nodes
entity ?= focus_bo.
TRY.
* go to BTAdminH and access CondSet
entity = entity->get_parent( ).
entity = entity->get_parent( ).
lv_collection = entity->get_related_entities( iv_relation_name = 'BTHeaderPridoc'
iv_mode = cl_crm_bol_entity=>bypassing_buffer ).
CATCH cx_crm_genil_model_error.
* should never happen
EXIT.
CATCH cx_sy_ref_is_initial.
CATCH cx_bol_exception.
ENDTRY.
This code assumes that it can get to the BTAdminH entity from a BTAdminI entity through two consecutive GET_PARENT calls(first to BTItems and then BTAdminH). One of our developers had used the relationship "BTItemSubItem" (ParentItem -> SubItem) in the DO_PREPARE_OUTPUT method of the items overview page(BT115QIT_SLSQ/Items). So, when the user clicked on the link to Items view, the parent was a BTAdminI instead of the BTItems. The standard code failed and the exception was caught, but not handled. And this resulted in mismatched pricing information display. We corrected this by updating the parent relationship before the navigation was triggered. This happened a while ago and I'm not sure if a note has been created to address this problem.
The lesson? When executing this method on objects for which multiple paths exist, use the GET_NAME method to make sure that you have got the correct object. Depending on the model, you can loop this method till you get the correct higher object. There's a lso the other useful methof GET_PARENT_RELATIONSHIP that you can make use of.
