Accessing a delegated object in BOPF
A Delegated Object (DO) in BOPF is an elegant way of including identical functionality in multiple business objects, without having to carry out redundant modeling and development of the functionality. Accessing the contents of a DO using ABAP code is however not so trivial. Short ABAP dumps such as /BOBF/CX_FRW_FATAL result, if the seemingly most obvious approach is used for access. In this article, I would like to explain how access to Dos can be achieved with the help of a simple scenario.
Excursus: The delegation concept in BOPF
In BOPF, the concept of delegation refers to encapsulating parts of the model and a subset of functionality into a separate business object known as a delegated object. This business object can then be integrated into numerous other business objects.
To achieve this, BOPF follows a “Black Box” approach. This means that at design time the “host” business object is unaware of the structure of the delegated object. This structure is also not displayed in the modeling environment. The components of the delegated object are incorporated into the “host” business object only at runtime, and both business objects are then merged together into one business object.
A few delegated objects are delivered together with BOPF and can directly be integrated and used in own business objects. Examples include the Address, Text collection, Attachment folder, Business partner and Change document business objects.
Example scenario: The business object
To demonstrate how to use a delegated object, the following business object will be used:
This business object is a simple representation of a customer and consists only of a single root node. Below the root node the delegated object, Text collection (found on the right side) has been incorporated. The objective is to read some data from the delegated object and write it into transient fields of the root node of the customer business object, with the help of a determination.
Solution: Accessing the delegated object
A delegated object is just another business object and many BOPF developers know that cross-BO access (BO A wants to access data from BO B) can only be achieved using the Service Manager. Consequently, a common approach will be to first of all create the Service Manager for the delegated object. However, the framework doesn’t permit this instantiation for good reason and will result in a dump at run time. At runtime, the contents of the delegated object are fully integrated into the structure of the “host” business object and consequently access to the content takes place through the Service Manager of the “host” business object. Also, access using io_modify and io_read of the “host” business object is possible. An example of such access is depicted in the following code snippet.
Even with this approach, the application will abort at runtime with a dump. At runtime, new nodes, associations, etc. are generated in the “host” business object based on the delegated objects. These elements have a different technical key as specified in the constants interface of the delegated object. To solve this dilemma, a key mapping must be carried out. This can be seen in the code snippet below.
First of all, the configuration object of the “host” business object is obtained. The configuration object provides a method for the context key mapping. For the method, a content category is specified, i.e. if it is desired to convert the technical key of a node, association or action. Furthermore, the key of the model element to be converted and the root node of the delegated object are specified. See the following screenshot for an illustration.
If this step is taken into consideration, access to the content of a delegated object from the “host” business object is easily possible. When working extensively with delegated objects and in cases where frequent access to different content is required, it is recommended to write generic helper classes which take care of such conversions.
In case of any questions or comments to delegated objects based on your experiences, we will like to hear about them. Also, if you solved this problem using another approach or if this article helped you, we will be pleased to hear about it.
This article is a translated version of the article Zugriff auf ein Delegated Object im BOPF (in German). You can also find other related articles to BOPF and FBI (in German) on our blog Erlebe Software – Individuelle SAP Software.
Thank you for this very important post,
this is a recurring question that is raised periodically.
just a small remark,
BP and Change Document have a reusable functionality like a DO, but they are technically BOs, which means that for those BOs you need to use their service manager in the usual way of cross BO data access.
we implemented a Determination as part of an delegated object (DO).
When the Determination is called, we try to modify a DO-node, which of couse is actually hosted in the host-object.
So we have to map our DO-node-key to the actual Host-node-key.
We use the configuration-object of the Host-object and the get_Content_key_mapping.
However, the last Parameter iv_do_root_node_key is the DO-node-key as seen from the Host-Object.
From inside the DO-code we have no Information in which Host-Object we are actually included, so we cannot provide this Information.
the gist of it
Any hint how to map node-keys from inside an DO to the actual Host?
as far as I understand your scenario you have a HOST_BO including a DO and a determination located in the DO. A modification is done on the DO node triggering the determination. Now it depends on your use case:
Inside the determination (located on the DO) implementing class you would like...
a) access nodes or action of its host object
Thats not allowed, as the DO is not aware of its host. The host could by any object, thus it is an invalid assumption that the host always offer a certain node or action.
b) access nodes or actions of the same DO
Here you do not need the content key mapping at all, just use the constant interface of the DO or use IS_CTX-NODE_KEY.
c) access nodes of a DO_2 that is included in the DO
Here you have to do the content key mapping for the DO_2 as it is invoked out of DO.
I hope this helps otherwise please describe what kind of scenario you have (a,b,c).
Thanks for the post, it helped me a lot in my recent work.
If anybody should be interested in ABAP code to create a new attachment in SLC /SRMSMC/ on supplier, activity or task let me know, and I can provide the code for you.
All the best.
I have a requirement where I have to assign Test Cases in the Test Plan to a Test Flow within the Test Plan. When I try to create that association get error. Could someone please help me.