By redefining an existing Gateway service, you create a new service that inherits all of the functionality of the base service. This can be done without the need to write a single line of code.

 

 

Gateway Services Redefinition Process

The development starts with the creation of a new project. Data model definition and service implementation are performed in just one step by choosing Redefine → Gateway Service from the context menu of the data model folder.

 

After this step, you can remove fields from the redefined service or rename them. You might want to rename fields, for example, for the services generated from BW easy queries.

 

 

After the service has been registered in the back end, it can be extended.

 

Possible extensions include the following:

• Adding properties to an existing entity type
  Depending on the service implementation, it could be a case where no coding is required. With SAP NetWeaver 7.40 SP10, runtime support for this behavior called “Simple Field Extensibility” is planned.
• Adding additional entity sets
  This will require a code-based implementation.

 

Service Extensibility in Older Releases

The default behavior of releases up to SAP Gateway 2.0 SP08 was that as a result of a service definition, a second service with its own service URL was created. For example, the service ZEXTENDED_SRV is registered as a service extension of ZBASE_SRV.

 

 

The resulting two service URLs are as follows:

• …/ZEXTENDED_SRV
• …/ZBASE_SRV

 

Use of the extended service option prior to SAP Gateway 2.0 SP9 or SAP NetWeaver 7.40 SP8 is not recommended.

 

Service Extensibility — Calling Service URLs

 

As shown in the figure, calling the service URL .../EXTENDED_SRV to overwrite the extended service means that the EXTENDED_SRV service implementation is called while calling the service URL.

 

…/BASE_SRV still calls the original service implementation BASE_SRV.

 

Service Extensibility — One Service URL

With SAP Gateway SP9/SAP NetWeaver 7.40 SP8, the functionality of the service extension option has changed. When using the service extension now, the base service implementation is inaccessible. For example, you now would register the service ZEXTENDED_SRV as a service extension of ZBASE_SRV. This results in one service URL, …/ZBASE_SRV.

 

 

Service Extensibility — One Service URL Data Flow

The changed behavior is illustrated in the figure. No new service URL has been created. When calling the “old” service URL …/BASE_SRV, the service implementation EXTENDED_SRV is called instead since the framework detects that service implementation BASE_SRV has been extended by EXTENDED_SRV.

 

 

Adding Additional Entities

METHOD /iwbep/if_mgw_appl_srv_runtime~get_entity.
DATA lv_entityset_name TYPE string.
DATA lr_entity TYPE REF TO data.

lv_entityset_name = io_tech_request_context->get_entity_set_name( ).

CASE lv_entityset_name.
WHEN ‘<NewEntitySet>'.
…

WHEN OTHERS.
super->/iwbep/if_mgw_appl_srv_runtime~get_entity(
EXPORTING
…

IMPORTING
er_entity = er_entity ).
ENDCASE.
ENDMETHOD.

 

To redefine the generic read method: /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITY, perform the following steps:

1. Check for name of the new entity set
2. Call the method of base class for all other entity sets

Implementing Queries for Additional Entity Sets

1
2