ABAP Development_ Navigating the BOPF_ Part 5 -Enhancement.pdf

7
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 Register Welcome, Guest Search the Community Activity Communications Actions Brow se ABAP Development 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 - Enhancement Techniques Posted by James Wood in ABAP Development on Feb 22, 2013 11:32:31 PM Share

description

ABAP Development_ Navigating the BOPF_ Part 5 -Enhancement.pdf

Transcript of ABAP Development_ Navigating the BOPF_ Part 5 -Enhancement.pdf

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