Skip to Content

With this blog we would like to introduce the new Service Builder in SAP NetWeaver Gateway and its various options for building OData services for SAP NetWeaver and SAP Business Suite data.

Why the need to build OData services?

OData is an evolving standard for RESTful service for exposing business data to any kind of app, whether it runs natively on a smart device or is a flexible, HTML based client. Now that OData also has entered the OASIS standardization process and with a growing number of software vendors endorsing it, it could become the Lingua Franca for bringing business data to any Internet device.

Consuming OData in any kind of app is fairly easy. OData SDKs are available for all relevant client technology and for the most important ones there are already dedicated developer tools, which help any kind of developer to jump-start his app development by consuming available OData services. To get started with OData consumption for SAP NetWeaver Gateway, SDN includes several toolkits for instance for iOS, Android, JSE, PHP or HTML5.

What easily gets overlooked is the fact, that nearly always the right OData service first has to be built before it can be consumed. The number of out-of-the-box OData services is and may remain limited. When you think about it, this quite logical, because OData services by nature are fine granular and mostly tailored to the use case. In that sense they are quite different from comprehensive Enterprise Services in A2A scenarios, where resources like bandwidth, memory and CPU power are less critical. Learnings from app development projects show that up to 50% of development time can go into building the right OData service.

Introducing the Service Builder

Gateway Service Builder (transaction “SEGW”) is available as of Release 2.0 Support Package 4/5 and it greatly accelerates the OData service development process. In many cases you don’t even need to write a single line of ABAP code – unless of course you prefer to do so. It is no longer mandatory that you have deep ABAP OO skills. And the development time for a new OData service can be reduced to hours rather than days.

In Service Builder you need to do 3 main steps to build an OData service:

  1. Define or import the data model
  2. Implement or generate the runtime logic for the service operations
  3. Activate and run the service

The picture below shows the various options that are covered in SEGW:

/wp-content/uploads/2012/09/1_135867.png

Step 1: Define the data model

First, when building a mobile or Web app you determine which SAPdata you need. Then you retrieve the data where they usually are: somewhere in the SAP Business Suite. We call this “outside-in approach”. Gateway Service Builder is optimized (but not limited) for this approach.

For the definition of a new data model you will find different options inside SEGW. You can define all elements of the OData service step by step using the various editors within the transaction. If your data model is similar to an existing data structure (like an RFC or BAPI) inside of the DDIC, you can also import that structure. Alternatively,  if you already have an existing OData model definition in  appropriate EDMX format, you can import that from a file. At any time, you can check the consistency of the data model and SEGW will show you existing issues and guide you there. Also, as soon as you have a valid data model you can already activate the service and display  the service document and the metadata in a browser.

/wp-content/uploads/2012/09/2_135868.png

Things become very interesting, when you have the right business framework in your SAP Business Suite landscape. If there is any data object available which contains the data that you are looking for, you actually can ask SEGW to generate an OData service from that object. Guided by wizards you simply select the data (entity types and properties) that you need and rename (“redefine”) them to make them look OData style. Redefinition is already supported for BW Easy Query, SPI, GenIL and BOL with thousands of well-defined business objects. With the redefine option you will also get the implementation of the service operations for free and can immediately execute the resulting OData service.

/wp-content/uploads/2012/09/3_135872.png

Step 2: Implement the service operations

Having the right data model definition you then need to provide the runtime logic for the different service operations, usually CRUDQ. Also for this Gateway Service Builder offers you several paths. For both the Model Provider Class (MPC) and the Data Provider Class (DPC) Service Builder always generates a base class, that will be overwritten during the next generation step,  and an extension class (name ends with “_EXT”), where you can put your own code extensions. You now can write the ABAP code for the service operations into the stub classes that SEGW generates.

But perhaps already one of the many thousand RFCs or BAPIs in the SAP Business Suite already does the right job. Then you can map the RFC or BOR operations to your data model. In that case SEGW generates the entire ABAP runtime logic.

As soon as you have a valid data model you can already activate the service and check out the service document and the metadata.

/wp-content/uploads/2012/09/4_135873.png

Step 3: Publish and run the OData service

Last step in the process is that you register, activate and run the OData services. Would be great to do all this from SEGW, right? This is how SEGW now behaves. Gateway lets you have various different deployment options and the service could be registered on the Suite backend but also in an Gateway hub. Therefore from SEGW you can navigate to the Activate and Maintain Service transaction on the right system and from there to all the other useful functions, like Service Explorer, Gateway Client and Error Log.

/wp-content/uploads/2012/09/5_135874.png

The truth is in the code

So far you haven’t seen a single line of code in this blog, right? Our objective with the Service Builder was to provide comprehensive support for building services in a declarative way or by re-using existing business objects in the SAP system. However, we know that there always are limitations to what can be declared and generated. Advanced OData features may need to be implemented manually or certain operations are not available in a redefined business object. Therefore the result of what you do in Service Builder will always end up in those ABAP classes mentioned above, which are based on the powerful OData Channel programming model of SAP NetWeaver Gateway. So, if you want to do some drill-down to understand what is going on during service execution or if, for whatever reason, you want to tweak the code, you can just go ahead and do it. This way you get great development support and still retain the freedom to decide the ideal development approach.

Building OData services has never been easier

Service Builder is a new transaction in available as of SP4 and and further enhanced in SP5 to make life easier for experienced ABAP developers  and SAP experts who are less into writing code. It is now available as part of the software component IW_BEP for SAP NetWeaver Gateway SP5 and can be deployed as an add-on to SAP NetWeaver 7.0 or higher. We will publish additional blogs in the coming weeks an months and drill down into special topics. In any case, try it out and let us know what you like or dislike about this new developer tool.

We can’t wait to hear your views and suggestions.

To report this post you need to login first.

34 Comments

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

  1. Johan von Reedtz

    Good overview. GW will be a very very useful tool going forward as long as licensing issues and authority (SSO etc) can be acceptable sorted out. Thanks Thomas for sharing.

    (0) 
      1. Johan von Reedtz

        Hi Andre,

        Thanks for pointing to this article. I have read it before I answered here. I think I understand the “SSO concept” on a higher level and the article explains in detail what SAP technology can be used here. So, from a strict technical view a have no major concerns at all.

        What I really meant in the previous comment is the “total picture” seen from a customer perspective and it is a lot about security and authorization. SAP customers in general IMHO have so far limited knowledge of Gateway and the use of it. I believe this aspect of GW must also be addressed by SAP (because no one else will and have enough knowledge to do so – only SAP can provide this…).

        See this thread in LinkedIn Gateway group: http://www.linkedin.com/groupItem?view=&gid=4554629&type=member&item=178545828&commentID=101208109&goback=%2Egde_4554629_member_178143211%2Enmp_*1_*1_*1_*1_*1_*1_*1_*1_*1%2Egmp_4554629&report%2Esuccess=8ULbKyXO6NDvmoK7o030UNOYGZKrvdhBhypZ_w8EpQrrQI-BBjkmxwkEOwBjLE28YyDIxcyEO7_TA_giuRN#commentID_101208109

        Best regards, Johan

        (0) 
          1. Kumud Singh

            Thanks Andre! It’s so nice of you as I’ve seen you’ve updated some of your old blogs with recent URL’s in comment section before anyone asking for correction.

             

            Regards,

            Kumud

            (0) 
  2. Syam Babu

    Hi Thomas,

    I am using SAP NW Gateway 2.0 system with SP04 but when I am creating project with SEGW Tcode it created Successfully, but the problem is menu option RFC/BOR Interface option is not available. If anything requires system patch level upgrade?

    (0) 
    1. Thomas Meigen Post author

      Hi,

      the generators are actually added in SP5 and my blog is not precise about this aspect. Thanks for highlighting this! I will fix it.

      Cheers…Thomas

      (0) 
  3. Uday M

    Hi Thomas ,

    very Nice Blog and Helpful …

    It would be helpful if you can provide any information for Posting/Inserting records using create operation in SEGW.

    Thanks.

    (0) 
    1. Thomas Meigen Post author

      Hi Uday,

      thanks! SEGW offers you various options to implement these operations. After defining the OData model in the Data Model part of the project, you need to navigate to the Service Implementation section. There for each Entity Set from the data model you need to either a) manually write the ABAP code for each of the service operations (create, read, update, delete, query) or you b) request the generation of the required code by mapping the entity type against an existing RFC, BAPI and so on. Posting as you want to do it maps against a Create operation in SEGW and at runtime is performed via HTTP-POST.

      All the required steps are documented in the SAP NetWeaver Gateway Developers Guide in the sections for Service Builder and OData Channel. In the Developers Guide there are also some cookbooks

      Hope that helps,

      Thomas

      (0) 
  4. govindu nagotla

    Hell Thomas,

    We are going to develope new SAP implementation based on SAP UI5 and NW GW .

    We have a very stringent timelines to complete the project .

    We have SAP UI5 team for the front end design ,who does not have ABAP knowledge and have a ABAP team for building the business logic .

    We want to follow the below development options – plz advice which is best option of the following .

    Option 1:

    -> SAP UI5 team will build the complete UI5 and also the OData modeling in SAP NW GWPA plugin in eclipse .

    ->ABAP team will import the above data models (xml files ) and implement the services in SEGW along with the Runtime artifacts (classes)

    Disadvantage – ABAP team has to wait for the Odata models

    Option 2 :

    ->SAP UI5 team concentrates only on UI5 screens design

    ->ABAP team will take care of the Business logic implementation in the form of RFC/BOR

    ->SAP UI5 team will build the Odata services based on the above RFC/BOR .

    I really appreciate your suggestions on the above development approaches .

    Regards,

    Govindu

    (0) 
    1. Ron Sargeant

      Option 1 – because the ‘disadvantage’ is not a disadvantage. You should not start coding anything until you have a data model. Bear in mind that a data model is not a provision service and does not take long to implement once the design abstraction is completed and validated.

      (0) 
    2. Thomas Meigen Post author

      Hi Govindu,

      I fully agree to Ron’s reply: Option 1.

      OData service development, even more so if the service is going to be used on some kind of mobile device, should be driven by the data demand for the UI. There is no point in exposing data, which are not required in the UI5 app. They would only consume precious resources on the device and on the network. Therefore just exposing everything contained in an RFC or other business object as an OData service is simply not recommended.

      Instead, define first the data model with all the entity types and properties, that the UI5 app will use, into an OData model and then ask the ABAP experts to build the right service. If you have the right RFC available, doing this with Service Builder should go fast.

      Cheers…Thomas

      (0) 
      1. govindu nagotla

        Hi Thomas ,

        Thank you so much for your time on replying to my questions .

        I think even though the RFC is exposing all the data but I should be able to select only the required data fields/functions from the RFC while designing/building the OData services in SEGW Right ??!! .

        If the above option is there then both teams (ABAP & UI team ) work independently …plz let me know your recommendation on this approach ..since we have a less time for the project delivery we are thinking about all these options .

        Also could you please tell me – How can we decide the no.of Odata services/entity types for the required business functionality ?

        whether we should identity the no.of Business functionalities required or no.of UI elements in the screen ?

        Thank you so much in advance .

        Regards,

        Govindu

        (0) 
        1. Thomas Meigen Post author

          Hi again,

          wether you model a service for a UI or pick the required field from an RFC does not make a fundamental difference: It is still what we call an “Outside-In” or demand driven approach to OData service definition. This is what we recommend for the reasons given above.

          The number of services that you will use should be determined by questions like “do you want to re-use a service for difference apps?” or “do you want to update parts of a service independently?” or “do you want to retrieve data from different systems or servers?”. This has to be decided case-by-case. OData itself does not impose any limitations here and by default a single OData service should suffice.

          Cheers…Thomas

          (0) 
  5. Martin Maruskin

    Hi Thomas,

    I tried to run Tcode SEGW in my SAP NW system but it is no available there. I’m have following components installed:


    GW_CORE 200

    IW_FND 250

    Do I need another Gateway component (e.g. IW_BEP) to install? Or I just need SP 04 or 05 of GW_CORE?

    Thanks in advance

    m./

    PS: my system is NW 731 based.

    (0) 
  6. Rajesh Suthar

    Hi,
    I am new to SAP, can anyone please help me how can i start this steps?
    where can i perform these steps?
    is there any offline tool or anything else?

    (0) 
    1. Ashwin Dutt R
      (0) 
        1. Syam Babu

          Hi Rajesh,

          ES1 system only for accessing SAP GW Services provided by SAP.

          We don’t have authorization to create/develop object development.

          Thanks,

          Syam

          (0) 
  7. Parth Jhalani

    Hi,

    The service implementation should be in the NW or at the ECC backend? As our BAPI exists in the backend and we are going to create Odata service in the front end, the service implementation classes are also created in front end (NW). Is this correct? I am getting confused?

    Thanks,

    Parth

    (0) 
    1. Kedar Tingikar

      Hi Parth,

      The right approach would be to create the Model based on your BAPI in the backend by importing the interface of the FM as entity in transaction SEGW.

      Once the model is created you need to register in the same in the Front end to which created the service  and append _SRV to your model name.

      Hope this helps.

      (0) 

Leave a Reply