abap development_ navigating the bopf_ part 5 -enhancement.pdf
DESCRIPTION
ABAP Development_ Navigating the BOPF_ Part 5 -Enhancement.pdfTRANSCRIPT
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 1/7
Getting Started Newsletters Store
Products Services & Support About SCN Downloads
Industries Training & Education Partnership Developer Center
Lines of Business University Alliances Events & Webinars Innovation
Login RegisterWelcome, Guest Search the Community
Activity Communications Actions
Brow se
ABAP Development
Previous
post
Next
post
0 Tweet
In my previous two blog posts, we explored the BOPF API from a client point-of-view. Here, we learned how to perform
basic CRUD operations, execute actions, and so on. Now that you have a feel for how the API operates, we're ready to
take a peek behind the curtain and see these services are implemented within the business objects themselves. For
now, our emphasis will be on enhancing these services since SAP does not yet support the creation of new business
objects. However, whether we're enhancing existing business objects or creating new ones from scratch, the
concepts remain the same.
What to Enhance?
Before we dive into the exploration of specific enhancement techniques, let's first take a look at the kinds of entities
we're allowed to enhance in a business object. Aside from implicit enhancements applied to implementation classes
using the Enhancement Framework, the types of entities that we can enhance within a business object are as
follows:
Custom Attributes
For a given node, we might want to define a handful of additional custom attributes.These attributes could
be persistent (i.e., they get appended to the target database table which contains the node data) or
transient in nature.
New Sub-Nodes
In some cases, we may need to do more than simply define a few new attributes on an existing node.
Using the relational data model as our guide, we may determine that a new sub-node is needed to
properly model some new dimension of data (e.g. 1-to-many relations, etc.). Depending on the
requirement, the sub-node(s) might be persistent or transient in nature.
Determinations
If we add new custom attributes to a given node, it stands to reason that we might also want to create a
custom determination to manage these attributes.
Or, we might have a standalone requirement which calls for some sort of "trigger" to be fired whenever a
specific event occurs (e.g. fire an event to spawn a workflow, etc.).
Consistency Validations
If we are enhancing the data model of a business object, we might want to define a consistency validation
to ensure that the new data points remain consistent.
A custom validation might also be used to graft in a new set of business rules or a custom security model.
Actions
If we have certain operations which need to be performed on a business object, we would prefer to
encapsulate those operations as an action on the business object as opposed to some standalone
function module or class.
Queries
In some cases, the set of defined queries for a business object might not be sufficient for our needs. In
these situations, we might want to define custom queries to encapsulate the selection logic so that we can
use the generic query services of the BOPF API as opposed to some custom selection method.
Navigating the BOPF: Part 5 - EnhancementTechniques
Posted by James Wood in ABAP Development on Feb 22, 2013 11:32:31 PM
Share
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 2/7
You can find a detailed treatment of supported enhancement options in the BOPF Enhancement Workbench Help
documentation which is provided as a separate download in SAP Note #1457235. This document provides a wealth
of information concerning the use of the BOPF Enhancement Workbench, enhancement strategies, and even the
BOPF framework in general. Given the amount of detail provided there, I won't attempt to re-invent the wheel in this
blog post. Instead, I'll simply hit on the high points and leave the nitty-gritty details to the help documentation.
Working with the Enhancement Workbench
When enhancing a business object, you'll be spending quite a bit of time with the BOPF Enhancement Workbench
which can be accessed using Transaction BOPF_EWB. Here, enhancement projects are organized into
enhancement ob jects. From a conceptual point-of-view, enhancement objects bear a lot of similarities to sub-classes
in the object-oriented programming (OOP) paradigm. This is to say that enhancement objects inherit all of the entities
of their parent BO. With this foundation in place, we can begin defining custom entities in much the same way we
might add new attributes/methods to a subclass in the ABAP Class Builder tool. However, as is the case with classes
in the OOP world, we cannot extend BOs which are marked as final or that do not have the "Business Object can be
enhanced" flag set (see below).
All of the BOs which are eligible for enhancement will show up in the Enhancement Browser perspective of the BOPF
Enhancement Workbench shown below. To create an enhancement, simply right-click on the BO that you wish to
enhance and select the Create Enhancement menu option (see below). From here, the BOPF Enhancement
Workbench will guide you through a wizard process which allows you to select the name of the enhancement object,
the constants interface for the enhancement object, and so on.
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 3/7
Once the enhancement is created, you will be able to edit your enhancement object in the workbench perspective of
the BOPF Enhancement Workbench shown below. As you can see, it has a similar look-and-feel to that of the normal
BO browser tool (Transaction /BOBF/CONF_UI). From here, we can begin adding custom entities by right-clicking on
the target node and selecting from the available menu options. We'll see how this works in the upcoming sections.
One final item I would draw your attention to with enhancement objects is the assigned constants interface
(highlighted above). This constants interface can be used to access the enhancement object entities in the same way
that the super BO's constants interface is used for BOPF API calls, etc.
Enhancing the BO Data Model
Perhaps the most common type of enhancement to BOs in the BOPF is the addition of new fields. Here, we have the
option of adding new fields to existing nodes or creating sub-nodes to model more complex relationships. In the
former case, we sometimes don't even need to create an enhancement object; just a simple append structure will
suffice (see below).
For more complex data requirements, we typically need to define sub-nodes. This can be achieved by right-clicking on
the parent node and selecting the Create Subnode menu option. This kicks off a wizard process in which you can
select the sub-node's name, its persistent and/or transient structures, and the rest of the auto-generated dictionary
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 4/7
types which go along with a node definition (e.g. combined structure/table type, database table, etc.). Most of this is
pretty standard stuff, but I would draw your attention to the step which creates the persistent and/or transient
structures. Note that these structures must exist in the database before you move on from the Attributes step in the
wizard process. And, in the case of the persistent structure, you must include the /BOBF/S_ADMIN structure as the
first component.
After the custom sub-node is created, you can fill out its attributes by adding components to the persistent/transient
structures defined by the sub-node. If the sub-node is a persistent node, then we can create, modify, and retrieve
node instances using the BOPF API as per usual. However, in the case of transient nodes, we need determinations
to pre-fetch the data for us. We'll see how to define such determinations next.
Defining Determinations
According to the help documentation, determinations encapsulate internal changing business logic on a business
object. Unlike the logic encapsulated in actions which can be triggered at any time, the business logic contained
within determinations is triggered as specific times within the BO life cycle (e.g. right before a node is saved, etc.). So,
in a way, it is appropriate to think of determinations as being a little bit like user exits/BAdIs/enhancement spots in that
they provide a place to hang custom logic at particular points within the process flow.
Once we determine (no pun intended) that we want to create a determination for a given node, we can do so by simply
right-clicking on that node and selecting the Create Determination menu option. This will spawn a wizard which
guides us through the process. Here, there are two main properties that we must account for:
1. Implementing Class:
We must create or assign an ABAP Objects class that implements the /BOBF/IF_FRW_DETERMINATION
interface.
2. Determination Pattern:
This property defines the event which triggers the determination. As you can see below, the set of available
patterns will vary depending on the type of node you're enhancing, its location in the node hierarchy, and so
on.
Once a pattern is selected, you may be presented with additional options for refining when an event is
triggered. For example, if we select the pattern "Derive dependent data immediately after modification", we
will have the opportunity to specify if the dependent data should be created/modified after any modification,
only when the node is created the first time, etc.
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 5/7
Because determinations can be used for a lot of different things, they can be implemented in a lot of different ways.
Here, it is very important that you pay close attention to selecting the right pattern for the right job. The aforementioned
help documentation provides a good set of guidelines to assist here. Other valuable resources include the interface
documentation for the /BOBF/IF_FRW_DETERMINATION interface in the Class Builder tool and SAP standard-
delivered determinations implementations available in the system you're working on.
Defining Consistency Validations
The process of defining a custom consistency validation is quite similar to the one used to define determinations.
Walking through the wizard process, there are three main properties that we must account for:
1. Implementing Class:
Here, we must create/assign an ABAP Objects class which implements the /BOBF/IF_FRW_VALIDATION
interface.
2. Request Nodes:
This property allows us to specify which node operations should force a validation to occur (e.g. during
creates, updates, etc.)
3. Impact:
With this property, we can specify the behavior of the BOPF framework in cases where the validation fails.
For example, should we simply return an error message, prevent the requested operation from
proceeding, or both?
From an implementation perspective, the /BOBF/IF_FRW_VALIDATION interface provides us with everything we need
to perform the validation check: the context of the validation, the current data within the node instance being validated,
and so on. For more information about how to implement the validation class, I would highly recommend that you
read through the interface documentation for the /BOBF/IF_FRW_VALIDATION interface in the Class Builder tool. It
can also be helpful to look at various standard-delivered classes which already implement this interface to see
common patterns/idioms used by SAP.
Working with Actions
When it comes to the customization of actions, we have a couple of options:
We can create a brand new action definition for a given node (standard or custom).
We can enhance existing actions with pre/post action enhancements.
The first case is pretty straightforward. Basically, we simply follow along with the wizard process up to the point that
we reach the Settings step shown below. Here, we must define three main properties for the action:
Implementing Class:
This property is used to specify the ABAP Objects class which encapsulates the action logic. The class
must implement the /BOBF/IF_FRW_ACTION interface.
Action Cardinality:
The action cardinality property defines the scope of the action. This is somewhat analogous to the way we
have the option of defining class methods or instance methods within a regular ABAP Objects class. In
this case however, we also have the third option of defining a sort of "mass-processing" action which
works on multiple node instances at once.
Parameter Structure:
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 6/7
If we wish to pass parameters to the action, we can plug in an ABAP Dictionary structure here to
encapsulate the parameters.
Once the action is created, we simply need to plug in the relevant logic in the defined implementation class. You can
find implementation details for this in the interface documentation and/or sample action classes in the system.
In order to create a pre/post action enhancement, the target action definition in the super BO must have its "Action
Can Be Enhanced" flag set (see below). Assuming that the flag is set, then we can proceed through the
corresponding wizard process in much the same way we would if we were creating a custom action from scratch.
Indeed, as is the case with regular actions, the implementation class(es) for pre/post action enhancements must
implement the /BOBF/IF_FRW_ACTION interface.
Before you go to implement a pre/post action enhancement, I would definitely recommend that you read through the
help documentation so that you understand what you can and cannot do within an action enhancement. Most of the
rules are intuitive, but you can definitely get into trouble if you abuse these enhancements by using them for things
they weren't designed for.
Defining Custom Queries
Compared to the various enhancement options we've seen thus far, custom queries are perhaps the easiest entities
to create within an enhancement object. Indeed, if all we want is a simple node attribute query, we can zip through the
wizard and have a working model up and running in a matter of minutes. If we want something a little more
custom/sophisticated, our job is only marginally more difficult (at least from a configuration perspective) in that we
must assign an implementing class and an optional data type which serves as the parameter structure passed into
the query from the client side (see below).
12/3/13 ABAP Development: Navigating the BOPF: Part 5 -... | SCN
scn.sap.com/community/abap/blog/2013/02/22/navigating-the-bopf-part-5--enhancement-techniques 7/7
Follow SCNSite Index Contact Us SAP Help Portal
Privacy Terms of Use Legal Disclosure Copyright
Average User Rating
(1 rating)
0 Tweet
From an implementation perspective, all of the query logic for a custom query gets encapsulated in the
implementation class (which must implement the /BOBF/IF_FRW_QUERY interface). For the most part, you'll find that
the framework doesn't really get in the way with regards to how we go about implementing the query. Basically, it
passes in the query parameters up front and it's up to us to figure out how to find all of the node instances which
match the given parameters. Here, we must pay careful attention to the SQL statements that we use since the query
may be used extensively by a number of different clients.
Next Steps
Hopefully by now you have a general feel for how BOs are enhanced and the basic steps required to achieve these
enhancements. As is the case with most programming-related subjects, the best way to really drive these concepts
home is to look at live examples and experiment for yourself. I would also highly recommend that you read through
the aforementioned help documentation as it devotes quite a bit of time to understanding when and where to apply
specific enhancement techniques.
In my next and final blog post in this series, I'll demonstrate another useful tool within the BOPF toolset: the BO test
tool. This tool can be used to experiment with BOs and perform ad hoc unit tests, etc.
2011 View s Tags: abap, w eb_dynpro_abap, bopf
Share
There are no comments on this post
0 Comments