After working on several SAP projects, I have noticed a common trend consisting in a plethora of SEGW projects full of function imports that are generally misused or unnecessary. With my experience—and after delving into the SAP documentation—I have decided to write this blog to shed some light on function imports. I will explain what they are, what they are used for, when to use them and when to avoid using them, and will do so not only for SAP SEGW projects, but also for their equivalents within the more recent SAP RAP and CAP frameworks—since I am actively diving into these modern development approaches and working on business projects that leverage them. To make this more concrete, I’ll walk through a practical example, which I’ve made available on GitHub.
Let's clear up the confusion together. So, grab your coffee, and let’s dive in !
SAP SEGW Context
A function import in OData is a way to define and call custom operations in one’s service that goes beyond the standard data handling actions—like creating, reading, updating, or deleting records (CRUD). These standard actions are typically handled through the HTTP methods POST, GET, PUT/MERGE, and DELETE.
However, if you need to perform a more specialized task that does not neatly fit into the standard CRUD operations, you can create a function import in your data model using Service Builder. These custom operations can then be triggered using either the GET or POST HTTP methods.
But first, a small word of caution: these specific function imports are only to be used for actions that cannot be done with standard traditional CRUD operations. If the task can be handled through regular create, read, update, or delete, then a function import is not required.
Let’s look at an example to understand.
Example : Flight management system with CRUD and custom operations
Core CRUD operations :
These operations cover the basic data management needs for flight records
- Create: Add new flight (e.g., POST /flight with origin, destination, departure, arrival..).
- Read: Retrieve existing flight (e.g., GET /flight/{id}).
- Update: Modify flight (e.g., PUT /flight/{id} to adjust departure time).
- Delete: Remove canceled flight (e.g., DELETE /flight/{id}).
Custom operations :
These are business-specific operations that go beyond standard CRUD
- Print details: Generate and print comprehensive flight information (e.g., schedule, aircraft, and seating).
- Generate report: Create operational or statistical reports for flights over a specified date range.
- …
Custom operations are separated from CRUD because they encapsulate domain-specific behavior that cannot be addressed by simple data manipulation alone. While CRUD operations focus on creating, reading, updating, or deleting records, custom actions often perform calculations, trigger workflows, or apply business rules across multiple entities.
This distinction supports a cleaner and more maintainable architecture—where CRUD handles core data persistence, and custom operations handle the more nuanced logic of the application domain.
Implementation example
Below is an implementation example of how to call a function import defined in SEGW.
On the front-end, the function import is triggered via an OData request using callFunction(), for example: /sap/opu/odata/SERVICE_NAME/FunctionImportName(...).
On the back-end, it is handled by redefining the EXECUTE_ACTION method in the *_DPC_EXT class. Inside this method, the iv_action_name parameter is used to identify the specific function being called. Input parameters are accessed through the it_parameter table, and the corresponding backend logic is implemented accordingly.
Front-end code:
let oModel = this.getView().getModel();
let mParameters = {
FlightID: "12345"
};
oModel.callFunction("/PrintFlightDetails", {
method: "POST",
urlParameters: mParameters,
success: function(oData, response) {
MessageToast.show(oData.Message);
},
error: function(oError) {
MessageToast.show("Error printing flight details");
}
});
Back-end code : (Assuming we have previously defined the function import in the SEGW project and an ABAP OO class to manage the business object Flight)
METHOD execute_action.
" Check if the action name is 'PrintFlightDetails'
IF iv_action_name = 'PrintFlightDetails'.
" Retrieve input parameter
READ TABLE it_parameter INTO DATA(ls_parameter) WITH KEY name = 'FlightID'.
IF sy-subrc = 0.
DATA(lv_flightid) = ls_parameter-value.
ELSE.
" Manage error
ENDIF.
" Instantiate the flight manager class
DATA(lo_flight) = NEW zcl_flight( lv_flightid ).
" Call the method to update the flight status
DATA(lv_message) = lo_flight->print_flight_details( ).
...
ENDIF.
ENDMETHOD.
Conclusion
Function imports are a powerful tool, but like any tool, they must be used wisely. In SEGW, it is best to reserve them for operations that do not fit naturally into the CRUD. Misuse can lead to bloated, unclear services and unnecessary complexity.
In the next part of this series, I'll explore how similar use cases are handled in RAP and CAP - with a GitHub project to illustrate it all in action.
Stay tuned!
