Operating the RFC/BOR Generator

With code mapping, you can generate source code for OData operations by establishing a relationship between the interface parameters of a reuse unit and the properties of an entity set. This is done with the built-in mapping tool of the SAP Gateway Service Builder.

• For a function module or BAPI (Business Application Programming Interface), you can map the create, read, update, delete, and query operations separately for each entity set of your data model.
• For a search help, you can map the read and query operation for each entity set.
• For a CDS view, you map the whole entity set generating code for the read and query operations.

For a smooth mapping experience it is recommended to use the interface of the reuse unit as template for the entity types of the entity sets, which should be mapped. For a function module, these are the importing, exporting, and changing parameters in its interface.

The implementation process starts with the import of the interface of a function module. In contrast to code-based service implementation, service implementation via mapping can already be started prior to generating the runtime artifacts.

You usually start with mapping of the read and query methods, then the service is registered and tested. If the test is successful, you can then implement the CUD methods via mapping of appropriate function modules. The reason is that you usually test the CUD methods by reusing successful HTTP responses of read requests as input.

To import a function module interface, right-click Data Model and choose Import → RFC/BOR Interface. This opens the first step of the Create Entity Type from Data Source Wizard.

A function module usually provides only the functionality for one CRUD method. So you will use distinct function modules to map each CRUD method. But you can only choose one function module as template for the entity type. Therefore, the interface of this function module should provide a parameter as template for the entity type that is suitable to be reused for the other function modules.

The Create Entity Type from Data Source Wizard consists of the following steps:

1. In the first screen, you enter a name and select if you want to use a local or remote data source. For a remote data source, an RFC destination must be provided.
2. Using the value help, you select the data source to be imported.
3. When the option Create Default Entity Set is selected, the wizard creates an entity set called <Name of entity type>Set, for example, ProductSet.
4. In the next screen, you select the fields of at least one parameter, which should become properties of the entity type. It is also possible to assign the selected fields as a structure to one property of the entity type. This will result in a complex type based on the selected fields of the parameter.
5. Finally you choose the key field(s). Every entity type in OData must have at least one key field. It is also possible to rename the properties of the entity type since the proposed values are generated based on the ABAP field names: The underscores in the field names are removed and the name segments are merged in a camel case notation.
   Caution

   Only properties based on primitive types can be selected as key, not the ones based on complex types.

This wizard has some parallels with the Import from DDIC Structure Wizard. One of the major differences is that interface parameters can be assigned as structure to entity type properties. This might get handy in complex data models but could also be solved in other ways.

More important is the second major difference: You can choose remote-enabled function modules of other ABAP systems as data source. If you implement your OData service in one system and for any reason want to get data from another system, there is no better way than using RFC. By using this wizard, you can actually use the technical definition of DDIC types of another system to generate identical local types in your system. Remember that the DDIC itself is not remote-enabled, but the function modules are.

To map the query operation to a data source, expand the entity set under Service Implementation, right-click the GetEntitySet (Query) method, and choose Map to Data Source. In the Map to Data Source popup, select if you want to map a local or remote data source.

To map a function module, select Remote Function Module as Type and enter the name of the function module. A value help is available to ease finding the right function module.

Use Propose Mapping to automatically generate available mapping relations between the properties of the entity set and the parameters of the data source. If the entity type of the entity set was created based on the type of the parameter, the properties are completely mapped. You may generate the runtime artifacts and start testing the query operation.

If the entity type of the entity set differs from the type of the parameters, you may add missing mappings by dragging and dropping the parameter fields of the data source to the suitable entity set properties in the mapping table.

Export parameters are mapped as output showing an arrow pointing from the data source on the right to the entity set on the left. Changing parameters are also mapped as output but can be changed to input by choosing the arrows in the table. This is done if you want to provide data from the OData request to the function module.

Depending on the function module interface, additional features can be implemented by mapping suitable parameters. Many function modules offer a parameter to limit the number of selected data sets. This corresponds to the query option $top.

In our example, to map $top in the Data Source Parameter view on the right, expand the MAX_ROWS node. Select BAPIMAXROW and choose Set/Unset Max Hits.

BAPIs do not throw any errors but use a parameter called RETURN of type BAPIRET2 to inform the caller about errors. The mapping tool recognizes this parameter automatically and flags it as log. All messages provided via this parameter are now handled as errors in the generated code. If you want to change this or flag another parameter as log, you can use the Set/Unset Log button.

Function modules providing a list of data sets often define parameters to apply filters on the list in their interface. If such a parameter is defined as a range table, then the mapping tool automatically recognizes this and flags it as a range. If you want to change this or flag another parameter as range, you can use the Set/Unset Range button.

To map $filter, you must add the property of the entity set, which should be filtered, and map it to the filter parameter of the data source. In our example, you do this by following these steps:

1. Choose Append Row.
2. In the Entity Set property field, enter BuyerName by using the value help.
3. Drag and drop the data source parameter SELPARAMBUYERNAME from the right to the Data Source Parameter table field on the left.
4. Confirm the mapping of the range table n the popup.

This creates an input mapping showing an arrow pointing from the entity set on the left to the data source on the right.

To map the read operation to a data source, expand the entity set under Service Implementation, right-click the GetEntity (Read) method, and choose Map to Data Source. In the Map to Data Source popup, select if you want to map a local or remote data source.

To map a function module, select Remote Function Module as Type and enter the name of the function module. A value help is available to ease finding the right function module.

Use Propose Mapping to automatically generate available mapping relations between the properties of the entity set and the parameters of the data source. Please note that the mapping is not complete because to retrieve a single entity, you still need to specify the key field(s). In addition, the function module defines a parameter as mandatory. Luckily this is the key we must map anyway.

For the key field(s), one or more lines must be added and mapped (here: SoId):

1. Choose Append Row.
2. In the Entity Set property field, enter SoId by using the value help.
3. Drag and drop the data source parameter SO_ID → SO_ID from the right to the Data Source Parameter table field on the left.

This creates an input mapping showing an arrow pointing from the entity set on the left to the data source on the right. Now you may generate the runtime artifacts and start testing the read operation.

Mapping CUD operations to a data source follows the same principle as mapping read. First, expand the entity set under Service Implementation, right-click the method you want to map, and choose Map to Data Source. In the Map to Data Source popup, select if you want to map a local or remote data source.

To map a function module, select Remote Function Module as Type and enter the name of the function module. A value help is available to ease finding the right function module.

Use Propose Mapping to automatically generate available mapping relations between the properties of the entity set and the parameters of the data source. If the entity type of the entity set was created based on the type of the parameter, the properties are completely mapped as input.

It is often the case that the key is generated during creation of a data set. To provide this key to the requester, you must map the key field(s) as output (here: SoId):

1. Choose Append Row.
2. In the Entity Set property field, enter SoId by using the value help.
3. Drag and drop the data source parameter SALESORDERID → SO_ID from the right to the Data Source Parameter table field on the left.

Now you may generate the runtime artifacts and start testing the create operation.

Also for the update operation, use Propose Mapping to automatically generate available mapping relations between the properties of the entity set and the parameters of the data source. If the entity type of the entity set was created based on the type of the parameter, the properties are completely mapped as input.

To call an update module in ABAP, you must provide additional parameters with mappings. In our example, the SoId property must be mapped to three input parameters:

• Identify data set via SO_ID → SO_ID
• Pass data via SOHEADERDATA → SO_ID
• Document transfer via SOHEADERDATAX → SO_ID

The SOHEADERDATAX import structure is a convention for BAPIs. You tell the BAPI by passing an "X" in its components, which component of the SOHEADERDATA import structure is transferred. Not all fields are transferred because they are calculated by the function module.

For the delete operation, only the key field(s) must be mapped as input. Propose Mapping can be used or just drag and drop. The only output are the status messages in the RETURN parameter, which is automatically flagged as log.