Show TOC

Development ApproachesLocate this document in the navigation structure

SAP Gateway Service Builder supports different development approaches and life cycles to provide maximum flexibility so that you can fulfill changing development prerequisites and meet diverse requirements. If you need a service to expose a specific data, you can decide whether to define a new data model for the new service and integrate your 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 the project and then make minimal change as required.

The Service Builder provides numerous ways of reusing existing data sources from SAP Business Suite system, thereby accelerating the development process significantly. In short, Service Builder caters for all the levels of development experience and provides development approaches for saving time and increasing efficiency without compromising quality. Whichever development approach you take, appropriate set of ABAP classes are generated. This ensures that developers have maximum flexibility while optimizing or extending OData services in SAP Gateway. Service Builder supports the following development phases for OData services:

  1. Data Model Definition (Model Provider Class (MPC))
  2. Service Implementation (Data Provider Class (DPC))
  3. Service Maintenance
Overview
NoteThe following image contains links to more information.
SAP Gateway Service Builder In SAP Gateway Service Builder, you can define a new data model within your project to suit your exact service requirements based on the data you want to expose at runtime. In the Service Builder, you can reuse existing Search Helps in a system as data sources to create new entity types. Importing Data Model from File Importing a DDIC Structure Importing a Data Source (RFC/BOR Interface) Redefining Services Including an OData Service You can reference a Data Source in Service Builder and create a desired model. Development Approaches Mapping to a Data Source Service Maintenance
Data Model Definition
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:
  • Defining a 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 the same RFC or BAPI to obtain the service operations you require without having to write additional ABAP source code. Subsequent development phases: Service Implementation, Service Maintenance. For more information, see Importing a Data Source (RFC/BOR Interface)
    • 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.
    • Import Search Help: allows you to reuse existing Search Helps in a system as data sources to create new entity types. For more information, see Importing Search Help as a Data Source
  • 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 that 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 an OData Service

  • Data Source Referenced:enables you to fetch data model in the referenced data source via Reference option in Service Builder. Such Data model are not persistent in Service Builder instead when Service Builder is invoked they are fetched via reference unlike artifacts imported in other methods in Service Builder. Referenced model are always read-only.

    Sebsequent development phase: Service Maintena. For more information, see Referencing Data Source

Service Implementation
In the service implementation phase, you define the runtime artifacts (operations and methods) for the data provider class. You can define the runtime artifacts in the following ways:
  • Code-based implementation: The Service Builder generates 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 DDIC tables and views, and CDS views you can implement an OData service based on the Service Adaptation Definition Language (SADL). During the service implementation, you need to map the SADL model entities to the OData model properties using a mapping tool. For more information, see Creating OData Services Based on SADL.
Service Maintenance
The 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.
Related Information