Procedure Call Expression
A procedure call expression allows the execution of function modules as well as of methods of an ABAP OO class in the backend system. You can also use this expression to directly execute procedures that are stored in a database.
Note
The procedure call expression type is the renamed and extended successor expression type of the static method call expression that was offered in previous releases of BRFplus. The procedure call expression covers the full scope of the former static method call so that all existing static method call expressions from migrated legacy applications remain fully functional. However, it is not possible to create new static method call expressions.
You use this expression to take advantage of the full functional power offered by the ABAP programming language when processing BRFplus business rules. You can do so in order to access routines for data validation, data conversion, or any other kind of data manipulation regardless of the degree of complexity of such routines.
Values can be passed to the parameters of the called procedure with the help of a list of parameter mappings that are maintained for the expression. Once the called procedure has determined a result, it is returned to the result data object of the procedure call expression.
If the procedure that you want to execute is stored in a database (stored procedure), you can directly access this kind of procedure without having to define a wrapper method in an ABAP OO class manually. With that, you save programming effort. In addition, the number of steps in the execution path is reduced, thereby improving the performance.
Features
Supported Procedure Types
The following types of procedures can be assigned to a procedure call expression:
Function modules
Methods of ABAP classes
Database procedures
Interface Methods
It is possible not only to assign a class method to a procedure call expression, but you can also assign methods of a class interface that has been implemented by the selected class. To accomplish this, proceed as follows:
Choose a class.
Set the
Use Interface Method
flag.The
Interface Name
entry field is changed into editable mode.Use the value help (F4) to select from the interfaces that are implemented by the class.
In the
Method Name
field, use the value help to select from the implemented interface methods suitable for the procedure call expression.
Automatic Filtering of Suitable Methods
When using the BRFplus workbench for modeling a procedure call expression, the system automatically determines which methods of a given class can be used for the expression at all. Only these suitable methods are then offered for selection via the value help (F4).
Example
Only methods declared as public and static can be used. Such a method, however, is still not sufficiently qualified. For example, if the method signature contains a mandatory parameter whose type is determined dynamically or defined via indirection (for example, with the TYPE REF statement), it cannot be used for a procedure call expression because the exact type of that parameter can only be determined at runtime and is therefore unknown in the modeling environment.
However, if the same parameter is optional rather than mandatory, then the method itself can be used for the procedure call expression. In that case, the optional parameter remains unusable and is presented in a list of Unsupported Parameters
that you can check.
You can still enter a method that is not offered by the value help. In that case, using the check function for the expression makes the system trigger error messages that inform you of the reasons why the method cannot be used. It is then up to you to decide whether the method can be modified such that the system requirements are met. To see an overview of all methods of the selected class or interface that are currently not supported for a procedure call, choose Unsupported Methods
.
Parameter Mapping
Once you have assigned a method, function module, or database procedure to the expression, the system presents a list of the method parameters. The list contains all parameters that are either mandatory or not and have a type assigned that can be determined at design time. At the same time, this means:
Non-mandatory parameters whose type can only be determined at runtime are omitted because for these, no mapping can be done at design time. Such parameters are logged in the list of
Unsupported Parameters
.Mandatory parameters whose type can only be determined at runtime leads to the system qualifying the entire method as not suitable for the procedure call expression as described in section Automatic Filtering of Suitable Methods above.
From the list of parameters, you choose the ones for which you want to provide a value and associate them with a static value assignment or an expression of the appropriate data type.
Automatic Parameter Mapping
If the method or function module contains any of the following parameters, BRFplus performs an automatic mapping to the corresponding internal BRFplus objects:
Name | Type |
|---|---|
|
|
|
|
|
|
Note
Automatic mapping can only be done if the parameter names and types of the method or function module are exactly the same as given in the table above. In addition, the importing parameter for the trace object (IO_TRACE
) must be declared as optional.
For the same reason, there is no automatic parameter mapping for an assigned database procedure. This is because the internal representation of the data types used in the database differs substantially from the data types available in BRFplus. The system can therefore only offer a technical description of the database type in the parameter’s Description
field. Automatic mapping is not supported for procedure call expressions with a database procedure assigned.
Database Procedures
In a procedure call expression, you can directly call a stored procedure that resides in the database. This helps you saving additional programming effort, as well as improving the performance of database accesses because the number of execution steps is lower.
A procedure is always assigned to one of the various database schemas that may exist in the database. Therefore, a fully qualified definition of the procedure to be used consists of the name of the procedure plus the containing database schema. In the BRFplus workbench, the value help supports you in retrieving the desired procedure by offering matching procedures across the different schemas. In other words, although the schema is needed for identifying the database procedure, you don’t need to go too deep into the database internals to find the object you are searching for.
The database where the procedure to be called resides can either be the database that is associated with the system where you execute the expression, or it can be a database that is running in a different system within your landscape. In the latter case, you have to set up a secondary database connection. This can be accomplished in the scope of the application to which the procedure call expression belongs.
Note
Procedure call expressions of type Database Procedure
are currently only supported for the SAP HANA database.
Exception Handling
It is common programming practice to define exception handlers for ensuring safe and controlled system behavior in case of errors that may occur at runtime. If a procedure that you have assigned to a BRFplus procedure call expression contains one or more code lines where an exception is raised, the system presents these exceptions in the BRFplus workbench. It is then up to you to decide what BRFplus should do in case an exception actually occurs at runtime:
Propagated Exceptions
If any of the exceptions in this list occurs at runtime, the corresponding exception instance is propagated to the application that has called the BRFplus application. This calling application is then responsible for proper exception handling. By default, the system adds all exceptions that may be raised by a called procedure to this list.
Ignored Exceptions
If any of the exceptions in this list occurs at runtime, the corresponding exception instance is not propagated to the application that has called the BRFplus application. In other words, the exception is suppressed and BRFplus tries to continue processing as if nothing had happened. In this scenario, it is the responsibility of the BRFplus application designer to make sure that exceptions are ignored only if this is safe with respect to the processing flow.
CautionWhenever a called procedure raises an exception, this always means that the procedure processing is aborted immediately. There is no way to influence this elementary system behavior with the BRFplus exception handling options. From a BRFplus perspective, this means that the result value of the procedure call expression is initial, and the expression context remains unchanged.
End of the caution.
You control the system behavior by simply assigning the available exceptions to either of the two lists with the help of the buttons (Ignore Exception
and Propagate Exception
).