Common Errors Encountered
The error messages mentioned in this blog refer to the ones received in the Error Logs, Application Logs or at the Client level. Now let us look at the various problems.
Error Message at Client: While calling a service operation through REST client, you encounter RFC call ended with “System Failure” exception”
Error Analysis: This is a very common error while using the RFC tool in Service Builder. There can be many reasons for this error and error can be pin pointed by looking at the back-end error log. One other option is to go to your Data Provider Class (DPC) and find the place where RFC is called and put a external breakpoint and debug.
Common problems
Mandatory parameters are not supplied to RFC, Problem with RFC destination, Problem with the RFC itself (interface changed, not active etc.).
Error Message: at Client: In the context of Data Services an unknown internal server error occurred or DeSerialization of XML Failed via transformation ‘ID’
Error Analysis: This is a generic error at client side and there can be multiple reasons for it. This error is from the hub system and only way to check this error is to look into error log and application log in hub system.
Common Problems:
- property type errors (date, decimal/precision etc.)
- Date Property: Mark the date field as ‘nullable’ in your metadata. Clear the cache and rerun the operation. This solves the problem most of the times. This occurs if the RFC/Backend returns a date property as empty and GW parsers fail to convert it into a valid date value.
- For a date field, provide the ABAP type. Click on the ‘ABAP Type Editor’, select Category as ‘Internal Type’, Type Kind as ‘Date’. Save, Generate , Clear cache
Error Scenario: You have made changes to the data model. I.e. you have added and entity or added a new Function Import, but do not see in metadata.
Error Analysis: Metadata can be cached at Backend and also in the Hub system (can be deactivated as well, but not recommended). Once you make any change to the metadata, clear both caches using transaction code /IWFND/CACHE_CLEANUP and /IWBEP/CACHE_CLEANUP.
Error Message: at client: The specified HTTP method is not allowed for the resource identified by the Data Service Request URI
Error Analysis: For each http method you need to be aware of the right URI convention.
Common Problems:
For a ‘POST’ method URI should point to a Collection.
Example: …../sap/opu/odata/<NameSpace>/<ServiceName>/<CollectionName>
For a ‘PUT’ and ‘DELETE’ methods URI should point to an Entry.
Example: …../sap/opu/odata/<NameSpace>/<ServiceName>/<CollectionName>(<keys and values>)
If you are using a $batch, the request has to be a ‘POST’
Error Scenario: You are querying an OData service and you see that $orderby on query is not behaving as expected
Error Analysis: $orderby is not handled by Gateway framework; instead you need to handle it in your data provider class (DPC). Go to method iwbep/if_mgw_appl_srv_runtime~get_entityset in your DPC and read importing parameter IT_ORDERS and pass this info to your application.
Problem Scenario: I want to create/POST more than one entry at a time, but I get an error message when I try it.
Problem Analysis: OData does not allow you to POST more than one entry at a time, however there are alternatives. You can do a Batch update. See http://scn.sap.com/docs/DOC-29682 for more details. If you want to POST a parent and it children (example: Sales order and its line items, you can do a ‘Deep Insert’. See http://scn.sap.com/docs/DOC-22305 for details.
Problem Scenario: I am doing a ‘Deep Insert’ and I have implemented method create_deep_entity method. When I call method io_data_provider->read_entry_data, the child entries are not getting fetched into the ABAP structure.
Problem Analysis: The structure used in the method io_data_provider->read_entry_data has some special requirements. Let us say the code looked like this. (from scn blog on deep entity)
io_data_provider->read_entry_data( IMPORTING es_data = ls_so ). Here declaration of ls_so looks like this.
types: begin of ty_s_so.
include type z_salesorder_model_xx=>s_so_hdr.
types: SOItems type ty_t_soitem,
end of ty_s_so.
Here it is important to note that name ‘SOItems’ is the name of the navigation property inside sales order entity pointing to sales order items. Unless this name matches with the navigation property, child entries will not be fetched into ls_so.
Problem Scenario: Within Service Builder, Service Maintenance node is empty. You want to register your recently developed Gateway service into the Hub system, but see that Service Maintenance Screen node is empty and you do not see any Hub system there.
Problem Analysis: To do Service Registration on a Hub system, you can directly login to hub system and navigate to transaction /IWFND/MAINT_SERVICE. But if you want to do it from your backend system using the Service Maintenance node, then you need to maintain your Hub systems in configure backend through SPRO SAP NetWeaver Gateway Service Enablement Backend OData Channel Connection Settings to SAP NetWeaver Gateway SAP NetWeaver Gateway Settings in the Gateway hub system.
Problem Scenario: External Debugger not reached while debugging a Gateway Service
Problem Analysis: Ensure that you have set the breakpoint in the right backend system. Check your system alias of the gateway service to identify the right backend system. See below options if it you are sure about it.
- Clear your browser cache and try again. If this does not solve your problem see below point.
- Clear your metadata cache in hub and backend and try again. If this does not solve your problem see point.
- External debugger points are user specific. When you set an external debugging point check the message you get at bottom of the screen. That indicates the user for which the breakpoint was set. Now any call coming to this place in backend with this user, the breakpoint will be hit. If this does not solve your problem see below point
- Sometimes in development scenarios it is possible that you have a fixed RFC user set in the RFC destination’s logon options. In such a case the call to the backend will be through this RFC user, and not with the user with which you authenticated the Gateway service. In such a case, go toUtilities -> Settings -> ABAP Editor -> Debugging and set this RFC user here.
Error Message: While executing a query/read, encountered In the context of Data services and unknown error occurred
Error Analysis: This is usually problem with the properties involving Date, Time, UoM etc. There seems to be problem with RFC model importer in Service Builder.
Common problems: If your RFC/model has a date property, check that it is of type Edm.DateTime and Precision is 0. Service Builder usually gives a Precision as 8. After changing it to 0, generate the runtime artifacts again, clear the cache and run the operation.
Problem Scenario:
You want to copy an existing Netweaver Gateway Service or
You want to copy an existing Project in Service Builder or
You want to Copy/Rename an existing Project in Service Builder
Problem Analysis: All these functionality are supported starting from SP7 only.
Problem Scenario:
You are experiencing performance problems in a Netweaver Gateway Service. You are not sure if this is due to Gateway Hub, Gateway coding or Backend.
Problem Analysis: Starting with SP8, SAP provides URL parameters which can give time taken by each of the above components in an oData call. Read more about ithere.
Error Message: Syntax error in program /IWCOR/CL_REST_HTTP_HANDLER===CP
Error Analysis: This is usually solved by upgrading Basis to SP09. Also look at SAP notes 1551982, 1567128, 1560585 and 816861
Error Scenario: NW Gateway Service hitting a wrong client. You want the service to hit client 200, but it is hitting client 100, even though you had registered the service from client 200
Error Analysis: Unless specified explicitly, service will hit the default client, and in your case 100 seems to be the default client.
Solution: There are two ways to solve this problem.
- An SAP specific parameter ‘sap-client’ can be used. Example:https://<host>:<port>/sap/opu/odata/IWBEP/RMTSAMPLEFLIGHT_2/$metadata?sap-client=200
- Navigate to your service in Transaction SICF. Under Logon Data tab mention your client. Select “Alternative Logon Procedure” from the drop down and save your node.
Error Message: “RFC Error: Function module “/IWBEP/FM_MGW_READ_ENTITYSET” not found”
Error Analysis: This FM is called by the IWFND layer pointing to IWBEP layer as the RFC destination. This error message means that System Alias has been wrongly configured hence IWFND layer is pointing to a wrong system considering it as the IWBEP layer.
Solution: Check the System Alias used b the GW service. To find this goto Tcode /IWFND/MAINT_SERVICE and click on the service. On the bottom right box you see the system alias. Open this system alias in IMG (Double clicking opens it in some SPs) and review the settings. This blog explains you on how to configure System Alias based on your deployment scenario.
If you encounter a problem and it is not solved by above hints, then below are the various tools for you to use.
Error Logs
Let me start with two important Transaction codes which will give more information on most errors.
- /IWFND/ERROR_LOG: This provides error log in the hub system. From here you can navigate to a Gateway specific Application log or directly launch it using/IWFND/APPS_LOG.
- /IWBEP/ERROR_LOG: This provides the error log in your BEP/Backend system. Again you can navigate to Gateway specific Application Log by going to/IWBEP/VIEW_LOG.
Debugging option at browser Client: sap-ds-debug=true
This is a URI parameter which will help you to analyse your request better. Concatenate this parameter at the end of your URI.
Runtime tab in the response will provide you the program stack trace.
Trace your OData Request
You can trace each OData request at SAP. If you are on SP7, you can use the standard “Payload Trace” feature explained in the help.sap.com. Search google with ‘Payload Trace’ and ‘Gateway’
If you are on SP6 or below, you can use the standard ICM logging for this purpose. It is explained here in a blog by
External Debugging Point
Your last option would be to debug your SAP Gateway service by putting external breakpoints in the ABAP code.