8.2.10 BOPF Re-Usables
BOPF has been around (internally at SAP) for quite a while. Therefore, many solutions to common requirements have been created. So why not benefit of things others have created, tested and sometimes even still maintain? There are different levels at which Re-Use can be done and I cannot write about each re-use-component, but I would like to explain the different mechanisms and give a sample for each of them.
Business objects encapsulating existing functionality
Whenever someone has learned BOPF, one of the first questions sound something like this: “This all sounds beautiful, so where’s the business object for Material/Employee/Any other business object?” My sad answer to this is: “There is none and I am not too positive that SAP is going to ever provide one which encapsulates the existing models.” At least, I am sure no executive at SAP is going to spend effort on providing an encapsulation just for the sake of easier consumption at customers side. Still I hope that SAP internally sees the benefits and if there are monetary benefits for SAP as well, why should there not be something in the wild in future?
Still, there’s a very limited set of features for which such an encapsulation has been provided. To these documents, a cross-BO-association can be established from your custom object. The benefit is that you can program to them like to any other business object. You don’t have to look up some function-module-API or analyze their internal behavior: You can simply consume and even extend it. Also for some of them, additional features such as a UI have already been provided by SAP. I know the following ones
- Change-Documents (/BOFU/CHANGE_DOCUMENT)
This business object provides access to the netweaver change documents which keep track of database-table-changes. How to configure your BO in order to make use of this often required feature is nicely explained in A2tF (with the only correction that it is denoted as “dependent object” which it isn’t). There is also an FPM UIBB which you can easily re-use if you use a browser-based UI. With the help of those tools, you are able to enable change-documents including a proper visualization with less than a day effort (personal experience). - Application log (/BOFU/BAL_APPLICATION_LOG).
The application log provide a BOPF-based API for accessing instances you can monitor in SLG1. It features actions with which you can propagate message objects directly into the log. Quite funky and really easy to integrate. There is also an FPM-Application which you can integrate into your user’s cockpit (which is not beautiful, but honestly, would you call SLG1 “beautiful”?). - Business Partner (read-only, /BOFU/BUSINESS_PARTNER)
This BO wraps the function modules for reading the non-trivial BuPa-model, but cannot be used in order to manipulate them. That’s too sad, but still might be useful in order to integrate to it from process business objects.
Dependent objects
A dependent object (DO) is a business object which is included into a host-BO in order to provide some common behavior. We did not treat dependent objects so far, but it should be enough to know them as a set of nodes with determinations, actions and validations on them. SAP also ships some Dos which you can include into your custom objects:
- Attachment folder (/BOFU/ATTACHMENT_FOLDER)
An attachment folder (ATF) can be used to store documents with a relation to a BO node instance. For the actual storage, the knowledge provider is wrapped, so that also a content server can easily be connected using the known tools. The ATF itself takes the role of the generic object services. Using this DO has the benefits of enabling a BO-like interaction with the KPro and a very easy integration into web-based applications: A feature-rich FPM UIBB is also provided by SAP which enables up- and download of attachments with very less implementation effort. - Text collection (/BOBF/TEXT_COLLECTION)
There are usecases in which an instance of a BO shall carry language-dependent texts . Think of a support-incident, in which each interaction might be translated (optionally) to the language of the next-level support team. Or you might imagine a monster’s howl being language dependent as well. If this is the case, you’d most likely present the text in the user’s logon-language to him if available; else you’ll fallback to the original language. This functionality including some further customizing in order to give a semantic to each text is provided along with the text-collection.
Libraries
You might recall, that in BOPF there is something called the “configuration object” (/BOBF/IF_FRW_CONFIGURATION). An instance of this interface holds the metadata of the business object model and provides fast runtime access to it. Mostly, this is being utilized by the framework and its components in order to generically fulfill its duties, but it can also be used in order to provide generically implemented libraries.
Within the Conf-UI, there is even a dedicated tool in which you can inspect the contents of libraries shipped by SAP (though surely not every reuse-class has been added there); the library-feature in BOPF looks a bit deserted to me. Nevertheless, this is a valuable place if you are looking for some other re-use feature. Let me highlight the most important ones.
Validations
- Alternative key validation (/BOBF/CL_LIB_V_ALT_KEY).
Once you defined an alternative key the modeling environment requests you to configure an action validation for the actions "create" and "update" (if an update of the attributes of an alternative key is possible at all) or (depending on the time point when the check should be executed) for the action "save". Funky feature: This implementation will also prevent creation of identical alternative keys in parallel sessions (on multiple app servers). - Code-value-check (/BOFU/CL_V_CODE_VALUES)
This class is used to check the code values based on the domain definition. This class needs to be inherited from. GET_VALIDATION_CONFIGURATION needs to be redefined: This method obtains the configuration details, that is, the field names for which the code value has to be checked. - Mandatory attributes (/BOBF/CL_LIB_V_MANDATORY_ATTR)
This library class interprets the mandatory property (no matter whether it is statically defined or determined via a property determination) and can be configured either as consistency validation or as action validation preventing an action which needs to be based on consistent data.
Determinations
- Admin Data (/BOBF/CL_D_ADMIN_DATA)
This class generically determines the last modification of the node instance. Thus, it’s usually located at the root node and is being triggered by all modifications even on subnodes. Pre-requisite: Include structure /BOBF/S_ADMIN into the node which the determination is assigned to. - Determine new number from Number Range (/BOFU/CL_D_DRAW_NUMBER)
This determination class has to be inherited from providing configuration in the constructor (Number range, Interval, Attribute name which carries the drawn number).
Consumers
One of the benefits of the command-pattern used all over the interfaces is that it’s quite comfortable to provide generic consumers (particularly in conjunction with the configuration object), mostly providing an adapter to a frontend technology. Due to their complexity, I can only list them here:
- Floorplan Manager BOPF Integration (FBI)
FBI provides a huge set of webdynpro components which can be configured to be bound to BOPF business objects. This allows the implementation of code-free web-based user interfaces. It’s notable that FBI also provides an own model for defining adaptation of the BO services, such as de-normalization, code-to-text-translation and dedicated exits. You can find loads of information on FBI on the SCN in the BOPF space (check posts by Matan Taranto, responsible architect for FBI) - Gateway BOPF Integration (GBI)
GBI does not only sound like a sibling to FBI, it in fact is one. GBI allows you to import a BO-model into the gateway service builder. Though you can easily expose you BO as GW-service, there are some limitations to this approach. As far as I remember, the scope of each service can only be one BO. If you want to include multiple BOs, you have design from scratch. - The service adaptation definition language (SADL)
SADL is an artifact which can be used to describe relations and transformations of various sources. It can consume among others DB tables (and their FK-relations) as well as BOPF business objects. SADL is not getting modeled explicitly, but is majorly a runtime artifact providing a harmonized consumption layer. This layer aims at replacing the FBI-view-based approaches mentioned above in order to enable BOPF-consumption via Gateway and FBI in a performance-optimized way. At the time of writing, I could not really get my hands dirty on it, so I can’t tell you more, but at least now you know it exists and will be more and more important in future – And we’re all on our way to the future, so much is for sure.
> Find more alternative versions of other chapters in my blogs.
