Excerpt from the book SAP Gateway and OData by @carsten.boennen, @volker.drees, @andre.fischer, @lheinz, and @karsten.strothmann. Used with permission of SAP PRESS. All rights reserved.

 

This blog describes the high-level steps for creating services in SAP Gateway.

This blog will introduce the general steps in OData service creation and explain how the two methods for creating an OData service (service development and service generation) fit into this process. This explanation of the service creation process is somewhat simplified in an effort to explain it with distinct and sequential steps (a waterfall approach). In reality, some of the steps can also be performed out of order (an incremental approach).

This process consists of three main phases: data model definition, service implementation, and service maintenance. Depending on whether you go for service development or service generation, the individual phases of the service creation process can have different flavors. These flavors result in different paths that can be taken during the actual process.

Before you can start with this process, you have to complete the process of service definition as a prerequisite. This is the process of identifying what service to create and specifying its details. Ideally, you’ve done all of this together with the client developers so that you know exactly what data they require and how this works with the artifacts in the SAP Business Suite that will be the basis for your SAP Gateway service. After you have the service definition, you can start with the three development phases of the service creation process.

In the first phase, data model definition, you define the model your service is based on. That is, you define the required artifacts such as entity types, entity sets, associations, and other components that your service will use. After data model definition, you must generate the repository objects and register them in the SAP Business Suite system so that you can proceed with the next main phase, service implementation.

In the service implementation phase, the operations that are supported by the service are implemented. Here the different tracks for service development and service generation come into play:

  • For service development, operations that are supported by the service are implemented using ABAP coding.
  • For service generation, there are four paths depending on the type of generation chosen. If you use data source mapping, service implementation takes place by mapping the OData model to the methods of an RFC function module, search help, or CDS view. If you use redefinition, there is no service implementation step. You only have to perform the model definition step because the implementation of the service is generated based on the customizing that has been performed in the model definition step. If you reference a data source, there is again no service implementation step. Instead, you include one or more existing entity sets and associations of a CDS view into a data model. If you use Eclipse to create a CDS view by setting the OData.publish:true option, there is no service implementation step. Based on the CDS view definition, the implementation of the service is generated.

The third phase of the service creation process, service maintenance, publishes the service so that it becomes visible in the service catalog of the SAP Gateway system. In effect, this means that the created OData service can then be consumed.

The three phases—data model definition, service implementation, and service maintenance—are depicted below. Steps that are only performed in service development are marked with one color, and steps that are only executed in service generation are marked with a different color. Steps that have to be performed in both the development and generation of OData services in SAP Gateway are marked with both colors.

Although you can delineate the two methods of service creation (service generation and service development), it’s actually possible to mix these in a way that suits you best. For example, you can create an OData service where one entity set is implemented using the RFC/BOR Generator (service generation), while a second entity set is implemented using code-based implementation (service development). It’s also possible to generate a read-only OData service based on an SAP BW query and extend the same via code-based implementation so that it also supports updating business data.

As previously mentioned, the service creation process is presented here in a very structured and clearly sequential way. This waterfall approach allows you to easily understand what the different phases are for. In real-world projects, after you’ve understood how it works, you can adjust the sequence to what fits you best (within certain boundaries). The one exception to this rule is the service maintenance phase—this is almost always a one-time activity. As soon as a service is registered and activated (published), you don’t have to touch these settings anymore, even if the implementation and/or model definition changes.

Exception

Exception: The service publication is a one-time activity as long as you don’t perform major changes. Registering the service for additional SAP Business Suite systems, for example, is such an activity in which you have to go back to the service maintenance phase. Again, though, changes in the implementation of an already published service or in the data model can be used in the already published service without any further activities.

For all other phases, you’ll typically always follow an incremental approach: you build a service—or part of it—execute and test it, and then go back and refine that same service until it fits all of your needs.

During the creation of an OData service, you may change the model and/or the service implementation multiple times.

Furthermore, an approach often used in real-world projects is to perform the service implementation and the service maintenance in a different order. Performing the service maintenance with a service implementation stub before the actual service implementation allows you to browse metadata (service document and service metadata document), even if the service itself doesn’t yet have any functionality.

You’ve basically started with a service stub and can then fill this stub in an incremental way.

The figure below depicts the incremental service creation process. It’s based on the above figure and adds incremental steps to the original process. These incremental steps are displayed by the solid line arrows that depict potential transitions among the three phases of data model definition, service implementation, and service maintenance, which are symbolized by the horizontal boxes. The dotted line stands for the one-time activity of service publication as part of the service maintenance phase.

Excerpt from the book SAP Gateway and OData by Carsten Bönnen, Volker Drees, André Fischer, Ludwig Heinz, and Karsten Strothmann. Used with permission of SAP PRESS. All rights reserved.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply