In my previous blog post, I briefly introduced the BOPF framework and its positioning within the ABAP development landscape. With that information in tow, we're now ready to begin peeling back the layers of the BOPF and seeing how all the pieces fit together from a technical perspective. In this blog post, we'll get things started by taking a look at the design time aspects of business objects.
11/2/2014
the / B O B F / I F _ F R W _ A C T I O Ninterface. To some extent, it is appropriate to think of actions as being similar to the methods of an ABAP Objects class. Associations Though BOs are designed to be self-contained, autonomous entities, they do not have to exist in isolation. With associations, we can define a direct and unidirectional relationship from one BO to another. For example, in just a moment, we'll take a look at a sample BO called / B O B F / D E M O _ S A L E S _ O R D E Rwhich is used to model sales orders. Here, we'll see how the product assignments for sales order items is defined in terms of an association with a product BO called / B O B F / D E M O _ P R O D U C T . This composition technique makes it possible to not only leverage the product BOs data model, but also its behaviors, etc. Associations allow us to integrate BOs together in complex assemblies la Legos. Determinations According to the aforementioned BOPF enhancement guide, a determination "is an element assigned to a business object node that describes internal changing business logic on the business object". In some respects, determinations are analogous to database triggers. In other words, they are functions that are triggered whenever certain triggering conditions are fulfilled. These conditions are described in terms of a series of patterns: "Derive dependent data immediately after modification" This pattern allows us to react to changes made to a given BO node. For example, we might use this event to go clean up some related data. "Derive dependent data before saving" This pattern allows us to hang some custom logic on a given BO node before it is saved. This could be as simple as using a number range object to assign an ID value to a node attribute or as complex as triggering an interface. "Fill transient attributes of persistent nodes" This pattern is often used in conjunction with UI development. Here, we might want to load labels and descriptive texts into a series of transient attributes to be displayed on the screen. Note: This determination can be bypassed via the API if the lookup process introduces unnecessary overhead. "Derive instances of transient nodes" This pattern allows us to load transient nodes into memory on demand. Here, for example, we might lookup real-time status data from a Web service and load it into the attributes of a transient node from downstream consumption. Determination patterns are described in detail within the aforementioned BOPF enhancement guide. The logic within a determination is defined via an ABAP Objects class that implements the/ B O B F / I F _ F R W _ D E T E R M I N A T I O Ninterface. Validations According to the BOPF enhancement guide, validations are "an element of a business object node that describes some internal checking business logic on the business object". Validations come in two distinct forms: Action Validations Action validations are used to determine whether or not a particular action can be executed against a BO node. Consistency Validations As the name suggests, consistency validations are used to ensure that a BO node is consistent. Such validations are called at pre-defined points within the BOPF BO transaction cycle to ensure that BO nodes are persisted in a consistent state. The validation logic is encapsulated within an ABAP Objects class that implements the/ B O B F / I F _ F R W _ V A L I D A T I O Ninterface. Queries
http://scn.sap.com/community/abap/blog/2013/01/04/navigating-the-bopf-part-2--business-object-overview 2/4
11/2/2014
Queries are BO node entities which allow us to search for BOs using various types of search criteria. Queries make it possible for consumers to access BOs without knowing the BO key up front. Queries also integrate quite nicely with search frameworks and the like. Queries come in two varieties: Node Attribute Queries Node attribute queries are modeled queries whose logic is defined within the BOPF runtime. These simple queries can be used whenever you simply need to search for BO nodes by their attributes (e.g. ID = '12345'). Custom Queries Custom queries allow you define your own query logic by plugging in an ABAP Objects class that implements the / B O B F / I F _ F R W _ Q U E R Yinterface. The figure below illustrates how all of these entities fit together within a BO node definition. Here, I've pulled up a BO called / B O B F / D E M O _ S A L E S _ O R D E Rin Transaction /BOBF/CONF_UI. Here, the BO metadata is organized into several different panels: On the top left-hand side of the screen, you can see the BO's node structure. Here, you can see that the node structure is organized underneath a top-level ROOT node which models sales order header data. Underneath this node are several child nodes which model sales order items, customer assignment, and texts. The ITEM node in turn encompasses its own child nodes to model item-level data. On the bottom left-hand side of the screen, we can browse through the node collection of a BO and view the entity assignments of a given node. As you can see in the figure, each node contains folders which organize assigned actions, validations, and so on. In the middle of the screen, we can view additional details about a selected node by double-clicking on a node within the Node Structure panel on the left-hand side of the screen. Here, we can look at a node's data model, implementation classes, and so on.
We'll have an opportunity to get a little more hands on with these entities in upcoming blog entries. For now, our focus is
http://scn.sap.com/community/abap/blog/2013/01/04/navigating-the-bopf-part-2--business-object-overview 3/4
11/2/2014
on grasping how pieces fit together and where to go to find the information we need to get started with a BO.
Next Steps
At this point, you should have a decent feel for how BOs are modeled at design time. In my next blog, we'll shift gears and begin manipulating BOs using the provided BOPF APIs. This will help put all of these entities into perspective.
4063 View s
1 Comment
Queries are often misused at runtime, therefore just some small addition: It's (almost) true that Queries identify a set of instance of the node at which they are modeled, but: (as per contract) they only return persisted data! As during transactional processing it can happen, that instances which shall be found have just been created during the session, queries should not be used while implementing transactional entities (such as determination, actions, validations). If a collection of instances has to be identified which can't be resolved via associations, alternative keys allow a translation of semantical attributes to technical keys. Now you are wondering how a key can translate to a collection of keys? The answer is in the nonuniqueness of the key. E. g. a purchasing group can be thought of identifying a set of purchasing documents. It thus acts as a non-unique alternative key. Cheers, Oliver P.s.:Excellent post, James! It's quite tricky to publish good non-redundant-content about BOPF after your series
http://scn.sap.com/community/abap/blog/2013/01/04/navigating-the-bopf-part-2--business-object-overview
4/4