Data storing & processing with BOPF in SAP TM 

Hello & welcome to another blog, 

Here we will discuss about the framework called Business Object Processing Framework (BOPF) used for data storing & processing in SAP TM. 

Let’s begin with our today’s topic. 

SAP TM uses frameworks that allow a consultant or even the user to customize and personalize the application without having to consult a programmer. The new framework, called the Business Objects Processing Framework (BOPF), encompasses both data storage and data processing. 

Before going further let’s understand that SAP TM does not use the SAP GUI interface (transaction codes and ABAP programs); it uses web user interfaces instead. SOA (service-oriented architecture/software architecture) is an architecture for exchanging data between different business partners or systems, also a new way of data modelling within a system itself. The BOPF is the central technological foundation of SAP TM and incorporates the idea of modelling data in an SOA-compliant way.  The BOPF models the storage of data in an object-oriented way, but also merges the processing of data into the same framework. Therefore, data storage and data processing are closely linked. 

 To understand the relation between SOA & BOPF, let’s have a look at below flow diagram (Figure 1). 

Web based UI 

 

SOA (service-oriented architecture) 

 

For exchanging data between BPs or systems 

Data Modelling 

 

Business Objects Processing Framework (BOPF) 

 

 Data storage 

Data processing 

BOPF stores data in an object-oriented way, each document or master data item is stored as an object instance in the database 

Node elements are used for the data processing part of the BOPF methodology. Determinations, actions, and validations three node elements responsible for built-in data processing. 

Storing Data in the BOPF

Because the BOPF stores data in an object-oriented way, each document or master data item is stored as an object instance in the database. The BOPF reflects the information structure in its business object structure. A business object consists of different nodes, each with its own purpose. The superordinate root node contains header information. The subordinate nodes contain item’s information. Refer figure 2 ,

 

Business Objects Processing Framework (BOPF) 

 

Business process objects store transactional data (TRQ/TOR) 

For eg. Master Data Object (Vehicle resource, Locations), Meta Data Object (Optimizer Planning, Carrier Selection) 

 

Business Object Nodes < Assigned with simple Data Dictionary (DDIC-SE11) structure (Fig. 2.3) 

Superordinate root node 

Subordinate nodes 

Header information 

Items information 

Figure 2 

 For example, the freight order has some unique header data such as the order number and the assigned carrier. Can occur only once per freight order. All items are linked to order number. Having Node /BOBF/CONF_UI > /SCMTMS/TOR(FO). 

Figure 3 Overview of Business Object Nodes

Figure 4 Node Information

As you can see on the right side of Figure 4, a simple Data Dictionary (DDIC) structure is assigned to each node. The data structure contains all fields that can be filled with information such as the freight order number, carrier, and so on. Double-clicking the data structure takes you to the DDIC (Transaction SE11) so you can see the structure.

Data Processing with the BOPF

Many
node elements are assigned to a node


 Data Processing with the BOPF

Many node elements are assigned to a node.

Figure 5 Node Elements

Node elements are used for the data processing part of the BOPF methodology. Determinations, actions, and validations three node elements responsible for built-in data processing.

Let’s look at this node elements in detail.

 

Determination

To add custom logic, a developer had to know exactly where in the code certain things happen. With the BOPF, this problem has been solved with determinations.

The framework itself calls determinations after one of the create data, read data, update data, or delete data (CRUD) methods is called.

Example: the determination for number drawing for our freight order. the following is defined: that a number is drawn only when the root node instance is created.

 

Figure 6 Triggering a determination

Figure 7 Determination Details

 

Actions

An action is program logic that is called externally, usually by a button on the UI. Processing a business object node according to a user’s input is done by actions.

Say, for example, we have put together a full truckload of various cargo items. We want to check whether the combination of goods on the truck is feasible or if some goods may not be transported together. Therefore, we want to execute an incompatibility check on the freight order, so we use the corresponding button on the freight order UI.

 

 

Figure 8 Action Details[VS1] 

 

Validations

A validation is also a piece of coding called and executed by the BOPF,
just like a determination or an action. The BOPF offers two different types of
validations: action validation and consistency validation.

Action
validations are associated with an action of the business object node and are
called before the action is called. The action validation checks whether the
action may be executed.

A
consistency validation, on the other hand, occurs after a change is made to a
business object node. Like determinations, consistency validations are not
directly linked to actions, but monitor changes to a node instance.

 

Reference:
Transportation Management with SAP® TM 2nd edition Rheinwerk
Publishing Bonn 2016

 



Get in touch with us







    *Your data will be processed by NAV IT Consulting in accordance with our data privacy declaration.