Development Approaches
SAP Gateway Service Builder supports different development approaches and life cycles to provide the developers maximum flexibility so they can fulfill changing development prerequisites and meet diverse requirements. When developers need a service to expose specific data, they can decide whether to define a completely new data model for the new service and integrate their own source code, or reuse and redefine existing services. If a project exists that could be applied to a similar use case, you can create a copy of an entire project and then make the minimal changes required. The Service Builder provides numerous ways of reusing existing data sources from an SAP Business Suite system, thereby accelerating the development process significantly.
In short, the Service Builder caters for all levels of development experience and development approaches tailored to saving time and increasing efficiency without compromising on quality. Whichever development approach you take, the appropriate set of ABAP classes is generated. This ensures that you retain maximum flexibility while optimizing or extending OData services.
Service Builder supports the following development phases for OData services:
Data Model Definition (Model Provider Class (MPC))
Service Implementation (Data Provider Class (DPC))
Service Maintenance
Overview
OData services require a data model definition (model provider class). In the case of client development projects, the development process invariably starts with a previously-defined data model (outside-in approach). Depending on your requirements, you can define a data model in the following ways:
Define new data model: provides maximum flexibility and requires manual definition of individual data model elements and their properties.
Subsequent development phases: Service Implementation, Service Maintenance.
For more information, see Defining a Data Model.
Import:
DDIC structure (ABAP Data Dictionary): reduces time required to create entity types and complex types in your data model.
Subsequent development phases: Service Implementation, Service Maintenance.
For more information, see Importing a DDIC Structure.
Data source (RFC/BOR interface): enables you to reuse existing RFC/BOR parameters to create entity types with ease. In this way, you can tap into a multitude of existing Remote Function Calls (RFCs) and Business Application Interfaces (BAPIs) from the Business Object Repository. After you have imported an existing interface definition, you can map the operations from same RFC or BAPI to obtain service operations you require without writing additional ABAP source code.
Subsequent development phases: Service Implementation, Service Maintenance.
For more information, see Importing a Data Source (RFC/BOR Interface).
Import Search Help: allows you to reuse existing Search Helps in a system as data sources to create new entity types.
Subsequent development phases: Service Implementation, Service Maintenance.
For more information, see Importing Search Help as a Data Source
Data model: allows you to reuse an existing data model. You can reuse a data model for more than one service.
Subsequent development phases: Service Implementation, Service Maintenance.
For more information, see Importing a Data Model.
Redefine service: enables you to redefine existing SAP Gateway services or services created from a framework within your SAP system landscape. For example, Service Provider Interface (SPI), SAP Business Information Warehouse (BW Query), Generic Interaction Layer (GenIL).
The Redefine service function enables you to reuse the diverse business objects and services that exist in your SAP system landscape. Furthermore, it connects existing service operations so you do not need to create an individual service implementation. Consequently, you can skip the service implementation phase.
Subsequent development phase: Service Maintenance.
For more information, see Redefining Services.
Include service: enables you to include an existing SAP Gateway service so you do not need to recreate its data model. For greater reuse, it allows you to combine one or more existing services in a new service. If you choose to include existing services, you do not need to perform the service implementation phase.
Subsequent development phase: Service Maintenance.
For more information, see Including a SAP Gateway Service.
In the service implementation phase, you define runtime artifacts (operations and methods) for data provider class. You can define runtime artifacts in the following ways:
Code-based implementation: The Service Builder generates the required ABAP classes based on the data model you define. Subsequently you can navigate directly from the Service Builder to ABAP Workbench where you can access the appropriate methods and write the source code for the various different service operations. SAP provides some code patterns for data provision and metadata definition.
Mapping operations to a data source: You define manual relations between the parameters of a data source object and the properties of an entity. You can map data sources of type Remote Function Call (RFC) and Business Object Repository (BOR). This function is designed for use in conjunction with the Import data source function (RFC/BOR interface) and enables you to map the RFC/BOR function to the service operations. Where possible, the Service Builder proposes an operation mapping for imported RFC/BOR interfaces.
For more information, see Including an OData Service.
Final development phase in the life cycle of an OData service is Service Maintenance and this must be carried out regardless of your chosen development approach. Service Maintenance entails registering and activating each service in an SAP Gateway system.
For more information, see Service Maintenance.