A developer creates a new OData service (code, definition, implementation) in the backend and adds everything to a transport package. After transporting an OData service from DEV to QA in the backend, the service is not usable in QA as the system alias for the OData service is missing. While the service definition and implementation were transported, the important piece that enables to call the service is not part of the transport package. The developer publishes and creates the service and system alias LOCAL in SEGW using an SAP wizard. In QA the system alias LOCAL is not attributed to the new OData service.

This (partly) makes sense as the system alias might differ in each environment. In almost all cases the system alias needed here is LOCAL, as it is the GW backend. You might want to add the system alias manually. Depending on the system configuration, this is not possible as the system is closed. Basis can open the system and add the alias, yet, it is better to transport this configuration.

To transport the LOCAL system alias for the OData service from DEV to QA, it is needed to

1. Create a transport request
2. Add table entry for system alias configuration
3. Transport

Sorry for the German language in the screenshots, I forgot to change the logon language. I hope you can still figure out where to click in your SAPGui.

Create a transport request

Create a new workbench request.

Transaction: SE01

Provide the necessary transport information.

Description: GW alias
Target: QA

Add the table entry to the transport. Select the transport request (double click).

The details of the selected transport request are shown. As nothing was yet done, it is empty.

Add table entry for system alias configuration

In the detail view of the transport request, manually add the table entry for the system alias. Click on edit.

Add a new table entry. Click the add row button.

Add the following values for the columns / parameters:

Program ID: R3TR
Object type: TABU
Object name: /IWFND/C_MGDEAM

The table entry for the transport should look like this:

Click on the button in column Function. A new dialog opens. It is not very intuitive to know what to do here. The intent is to enter the table entry that should be added to the transport.

Double click on the first empty line. Add the entries for the table entry.

The values depend on your OData service.

Client: Your client, e.g. 100
Service ID: Technical service ID of the OData service

Note

The values can be looked ab in the table /IWFND/C_MGDEAM. Look at the table entries via transaction SE16. Open the details for the OData service entry. These are the same values that have to go in the above form.

Click OK and the entry is added to the list of objects.

In the transport organizer (SE01, SE09, SE10) the transport lists now the table entry.

Transport

Transport into your QA system. Go to the services maintenance transaction and validate if the alias is transported.

You might still have to activate the ICF node for the service to work.

ICF Node not activated (icon yellow)

Activate ICF node for selected OData service

ICF node activated (icon green).

Test

After transporting the system alias and activating the ICF node, the OData service is ready to be used. A simple test can be done via the Gateway client. Call the service definition and some information must be returned.