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
Available documentation for Netweaver (NW) Gateway addon
SAP NetWeaver Gateway documentation at help.sap.com
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.
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:
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)
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.sargeant2 ).
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"
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.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
38 | |
19 | |
13 | |
13 | |
11 | |
10 | |
10 | |
10 | |
8 | |
8 |