ABAP_to_the_Future

8
Business Object Processing Framework (BOPF)
Delegated Objects
A delegated object is a BOPF business obje ct that encapsulates commonly used functionality
used in business object processing in order to make that functionality available
for reuse in multiple business objects. The change document is a very good example of
such a delegated business object, because virtually all other business objects will want
to use it—but there are several others available, such as objects to handle addresses,
long texts, and attachments.
This is the same concept you’ve seen throughout the book in which there are small,
reusable helper classes that do one specific thing being used by main classes, such as our
monster model class.
The SCDO step explained previously is always needed when dealing with change
documents. The steps specific to setting up change documents for a BOPF object
are then performed subsequently and are as follows:
1. Create a subnode of your root node, and choose object /BOFU/CHANGE_DOCUMENT
as the delegated object.
2. Create an association for the new change document node.
3. Create a subclass of standard class /BOFU/CL_CDO_BO_GENERICCALLBACK, and
redefine two of its methods.
4. Link the custom business object, change document objects (as created in Transaction
SCDO), and the callback subclass you just created together using a customizing
table in the IMG.
5. As always, you should of course test to make sure everything works correctly.
Each of these steps is discussed next.
Creating a Subnode for a Delegated Object
In this step, you’ll attach a delegated object to your monster object to take charge
of tracking all data changes. Transact ion BOB cannot handle adding delegated
objects, so you have to go to the old-fashioned Transaction /BOBF/CONF_UI,
which was the predecessor of BOB.
Note
Transaction /BOBF/CONF_UI will have the Change button grayed out unless you set a
PID for you user called /BOBF/CONF_PROTOTYPE to the value X.
344