In this blog I want to share some experience, I made with NW Gateway. You can find most of my information via popular search engines and via SCN, I just wanted to bring it together here.

Updates:

07/30/2013 – renaming a service and method in SEGW

02/26/2014 – provide Response Context to improve performance

Content

• NetWeaver Gateway documentation
• Caching aspects while testing
• Service analyzation & debugging
• Various tips
• Performance

Available documentation for Netweaver (NW) Gateway addon

SAP NetWeaver Gateway documentation at help.sap.com

Caching settings while testing / development

While your application is still in test phase it’s recommended to disable cache in all necessary systems (NW Gateway, possible middleware like SMP [SAP Mobile Platform] and your client). In Gateway you can deactivate cache via Customizing (transaction: SPRO). While you constantly test and extend your application/service this helps not to receive data which comes from cache. Even for performance test it’s better to deactivate caches to see how your application works under real circumstances.

You’ll find Gateway customizing setting here: Tx: SPRO >> SAP Netweaver >> Gateway >> OData Channel >> Administration >> Cache Settings

It’s also possible to create cleanup jobs or clean cache manually via transaction /IWFND/CACHE_CLEANUP and /IWBEP/CACHE_CLEANUP.

Service analyzation & debugging

Browser debugging

You can debug your ODATA services like you do it with any other website. In Google Chrome you have an build in developer tool which can be activated via menu: View >> Developer >> Developer Tools

Most important tabs in Developer Tools for analyzing your services are Resources, Network and Timeline.

Timing / Error analyzes for ABAP methods

SAP gives you the possibility to trace execution time for all methods which are called during your ODATA request. Just insert “sap-ds-debug=true” after the question mark in your URI. You’ll get the response and have several tabs to see more detailed information on your request. In tab Runtime you’ll see execution times for your ABAP methods. If you need this information permanently for documention propose you can download it as an HTML file on disk. Just change the URI parameter to “sap-ds-debug=download“.

          Example screenshot for URI parameter sap-ds-debug=true

If you get an error for your service call, you’ll see an additional tab in your browser “Stacktrace“.

URI paramter sap-ds-debug=true will also work in transaction /IWFND/GW_CLIENT.

Performance Trace in NW Gateway

SAP provides you also in NW Gateway an separate tool for analyzing ABAP method execution times. You can start this tool via transaction /IWFND/TRACES. The nice thing for this tool is, that you can easily configure the trace and click on your client through all pages of your UI5/native application. After that, look into traces transaction and see which service are called. And dive deeper in each service measurement.

To start a new measurement just follow these steps:

• right click on “Users & Request URI Prefix”, enter a user name _or_ an URI prefix
• configuration tab: set performance trace to value “Active”
• save configuration, this will active the trace for 2 hours
• call your URI via client
• refresh trace list
  

For further details, please look into the official documentation by SAP:

http://help.sap.com/saphelp_gateway20sp06/helpdata/en/9d/da3a2ceca344cf85568ae927e9858d/frameset.htm

          Example screenshot on performance trace in NW Gateway system (tx: /IWFND/TRACES)

Various tips

1) OData data types in URIs

Respect data types which need a identifier before actual content like Edm.Binary, Edm.DateTime, Edm.Guid, Edm.Time, Edm.DateTimeOffset.

For example when using a Edm.Guid type in a URI as a key, it has to be look like this: ServiceEndpoint(guid’xxxx-yyyy-…’). See all examples here:

http://www.odata.org/documentation/odata-v2-documentation/overview/#6_Primitive_Data_Types

2) Eclipse Gateway AddOn: services aren’t visible

mark every entity set as addressable which are considered as an ‘entry point’ for your client. All entity sets which are accessable via URI navigation, shouldn’t be directly addressable via a service URI to outside world (see comment by Ron Sargeant ).

3) POST & PUT payload for date properties

In my current setup, when I want to create or update an entity which has a date property (OData type: Edm.DateTime), I always have to provide attribute ‘m:null=“true”‘ in payload. Even if my date property has flag “nullable” set in transaction SEGW, I have to provide it with null value, anyway. Otherwise I received error: CX_SXML_PARSE_ERROR: Error while parsing an XML stream

So this tag doesn’t work for me:  <d:StartDate></d:StartDate> or  <d:StartDate />

I have to set payload as following:  <d:StartDate m:null=”true”>

4) rename a Service node and your method names

Renaming a service endpoint in transaction SEGW is very easy. Just go in folder “Entity Sets” and rename it. After you generate your runtime objects everything should work for the client with the new service name. But your methods in Data Provider Class (class *_DPC_EXT) isn’t renamed automatically.

To rename your method, you need to delete entity set in folder “Entity Sets“, save it and insert it again (copy properties first 😉 ). With this two steps you Association Set is gone, so please go to folder “Association Sets” and fill empty cells in column “Dependent Entity Set Name”. After new generation of your runtime objects you’ll see in SE80 that you’ve got new method names. You have to redefine these new methods and copy coding from your old ones into it.

5) get JSON response if format=json URI parameter didn’t work

Provide HTTP-header “ACCEPT=application/json”

Performance

Always keep in mind performance with OData and especially mobile clients. There are so many aspects regarding performance that I’m thinking to write a separate blog about this topic.

• a mobile device is limited to 5 HTTP request in parallel
• application cache on mobile device (e.g. safari) is only in program memory and not in flash memory,. That’s because it should not to destroy flash memory by huge amount of read/write requests >> better use web application cache (5MB available)
• use expand query via OData to save requests on slow networks (3G), but respect that response is bigger

for more info please take a look here:

– http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier.pdf

– blog about best practices on performance in Gateway with many Dos and Don’ts by David Freidlin

Provide Response Context to improve performance

When you’re using URI parameters like $COUNT, $INLINECOUNT,… Gateway framework provides you with build in functions, that you don’t have to count output table by yourself. But you can override these variables with your own data (see output structure ES_RESPONSE_CONTEXT). If you implement a special function to count the output vars, that could be faster, then the generic part. Maybe a faster access to the table with one select like SELECT count(guid) FROM table INTO lv_lines WHERE … ORDER BY guid. Though, you don’t really have to select real data from database, which isn’t needed in case of $count.

Sample coding, which could be used in GET_ENTITYSET method for your entity:

          IF io_tech_request_context->has_count( ) = abap_true.

             ” fast select with count >> actually don’t fetch any business data from database
             SELECT count(guid) FROM table INTO es_response_context-count  WHERE … ORDER BY

           ELSE.

             ” fetch all business data from database

             SELECT * FROM table WHERE…..

           ENDIF.

Please see method /IWBEP/IF_MGW_CORE_SRV_RUNTIME~READ_ENTITYSET for further details on GW handling for $count parameter:

G+ author page