Move From Theory to Practice with ABAP Extension Examples

By Karl Kessler, Vice President of Product Management, SAP AG  

Contributing Editor: John Yuva, SAPinsider

Within the main article, “Key Considerations for the SAP S/4HANA Cloud ABAP Environment,” we introduced the SAP S/4HANA Cloud ABAP environment. It provides ABAP developers with full ADT access to released SAP S/4HANA Cloud business objects and extension points.

In this companion piece, we take the theory introduced in the previous article, and examine some concrete extension examples using the tools.

Example Implementation of a BADI

In this example, we want to add custom field checks to managing purchase requisitions. For this purpose, we will provide an implementation for a BADI (Business Add-in) which was predefined by the purchase requisition application. Figure 01 shows the SAP Fiori screen to create a purchase requisition. For each line item of the purchase requisition, the end user must maintain quantity and delivery date (marked with a red rectangle in Figure 01). Our goal is to add a check for each field that triggers an error message when the quantity is more than 10 and the delivery date lies more than half a year in the future in order to better manage the overall resource consumption and timeliness of the process.

 

 

Logging on to SAP S/4HANA Cloud ABAP Environment

In the ABAP Development Tools for Eclipse (ADT), you create a new ABAP Cloud Project (see Figure 02). Besides the familiar logon options for SAP BTP ABAP environment, a new option has been added: the SAP S/4HANA Cloud ABAP environment. Here, you specify the URL of the SAP S/4HANA Cloud system instance for development. After successful authentication, the project explorer is displayed on the left (see Figure 03). As we want to extend a public extension point, we need to find the available BADIs in the SAP S/4HANA Cloud system. All extension points, public APIs, and released objects appear under the category “Released Objects” in the project explorer (see Figure 03). You can see the number of available artefacts in parentheses. To better organize this large list, you can configure the display of the tree, see the corresponding popup. We would like to navigate along the application component hierarchy; therefore, we choose it to be displayed in the project explorer (see Figure 04).

 

 

 

Locating the BADI for Purchase Requisition

You can drill down the application component hierarchy starting with Materials Management (MM) down to MM-PUR-REQ. Here you find the available enhancement spots. When you select the enhancement spot MM_PUR_S4_PR the various BADI definitions are shown, see Figure 04 on the right. Each BADI is called at a certain point in time, such as opening or closing the purchase requisition, when header and items are modified or when checking the input by the end user (MM_PUR_S4_PR_CHECK). We will provide an implementation of the check as discussed in the beginning. On the very right you can see technical properties of the selected BADI, such as the ABAP interface (IF_MM_PUR_S4_PR_CHECK) that the implementation class must support. You also find example class implementations for a quick start.

Provide the BADI Implementation

Next, we must provide an implementation for the chosen BADI. In Figure 05, you see that the chosen BADI has been implemented as ZBH_BADI_CHECK, with the corresponding ABAP class ZHB_CL_BADI_CHECK. This class contains the ABAP code. The implementation is set to active (see the flag on the right-hand side), meaning the methods of the class will be called when the purchase requisition application is executed.

 

Examining the BADI Implementation

Figure 06 shows the implementation of the class. The class must support the BADI interface, see the INTERFACES statement in the definition section of the class. The implementation section of the class contains one method called if_mm_pur_s4_pr_check~check. The code is straight forward.

First, the internal table with the purchase requisition items is accessed (READ TABLE) and then the field for the quantity is checked. If the quantity is greater than 10, an error message is composed (‘Quantity limit 10’) and appended to the internal table of messages. Likewise, the delivery date field is checked and if it exceeds a six-month period, a second error message is appended (‘Delivery date limit 180 days’).

 

Managing Purchase Requisitions

To see the effect of the BADI, we start the SAP Fiori launchpad and search for the purchase requisition application (see Figure 07) in the upper right.

In Figure 08, a new purchase requisition is created. The list of items appears in the middle of the screen. From here, we can pick the menu item to add a new material to be purchased. This leads to the purchase requisition item detail screen (see Figure 09). We pick the material code RM122 from the raw materials category. The fields such as plant, material group, and material type will be filled in automatically. If you specify a quantity greater than 10 (25 in the example here) the error message is sent (see Figure 10). If you specify a valid value (e.g., 10) the purchase requisition with a new number is created (10000668) (see Figure 11) and appears in the list of all purchase requisitions (see Figure 12).

 

 

 

 

Debugging

The strength of the SAP S/4HANA Cloud ABAP environment is that you have full access to all ABAP development tools, such as the ABAP Debugger. If you set a breakpoint in the BADI implementation, the debugger will immediately pop up (see Figure 13), allowing you to step through the ABAP code, examine variables and internal tables, inspect the call stack, and so on (see Figure 14).

 

 

Creating a Business Object Using a RAP Façade

Now, let examine how local APIs are implemented in the SAP S/4HANA Cloud ABAP environment. SAP S/4HANA Cloud business objects are represented as RAP business objects. You can call the local APIs with the RAP Entity Modeling Language. In Figure 15, we access the RAP facade of purchase requisitions with the MODIFY ENTITIES statement. The technical name is i_purchaserequisitiontp (“tp” stands for transactional processing). You can navigate to the RAP facade by pressing the control key. The definition of the RAP facade is implemented as a behavior definition (see Figure 16).

 

 

The API state (see lower half on the right) shows the business object can be used in local on-stack cloud development. The project explorer shows the location of the business object inside the application component hierarchy. In the outline, you see the associations that are exposed, such as the purchase requisition header and items, the accounting assignment, the delivery address, and the purchase requisition item text. You find the detailed documentation by clicking the first line. This will open the knowledge transfer document (see Figure 17). Here you can inspect the object structure, find detailed documentation including source code samples, authorization info, and the like.

 

Passing Parameters for the RAP Facade

Invoking the RAP facade goes linearly over the structure of the underlying business object. In Figure 15 you specify all fields of the purchase requisition header, such as its type (‘NB’) and then you pass all fields following the associations of the business object. In the example, one line item is created with the fields plant, requisition item text, quantity, base unit, price, currency, material group, purchasing group, and organization etc. In Figure 18, the other associations, such as accounting assignment and requisition item text, are passed.

 

Finally, during the commit phase (COMMIT ENTITIES) the keys are converted using a late numbering scheme. If you execute this program, a new purchase requisition is created that you can display in the SAP Fiori user interface (see Figure 19). If you drill down to the items, you can inspect all the data that you passed programmatically using the RAP facade, (see Figure 20). Again, you can use the ABAP debugger to control the execution in detail and monitor the late numbering process (see Figure 21).