Issues faced with SAP Gateway (GW by SE80 Method)
Below you will find an illustration of issues faced in SAP NetWeaver Gateway while creating services by the obsolete SE80 method. Although the SE80 method of generating gateway services is no more being used by projects; this document may prove useful to help resolve real-time issues for developers and customers still using this version.
The document discusses various issues already faced during Go-Live/Post Go-Live phase of the project and also elaborates a solution as to how the above shown Gateway Errors were resolved. Although SAP has provided us with the standard SAP Gateway Error Log. The messages are sometimes hard to decipher and do not indicate the action needed.
Please feel free to post your comments. And also, do correct me where you think I may have gone wrong. Reason being, this is just the start and there is always scope for improvement.
Issues faced with SAP NetWeaver Gateway and its Resolution – (SP05 and below versions)
Let’s start with most basic and common errors faced –
- SAP Netweaver Gateway has been deactivated
The above error occurs when Gateway is deactivated. To resolve this; navigate to transaction code ‘SPRO’, and expand the below shown nodes to activate SAP NetWeaver Gateway.
P.S – There may also be a case that an SAP System is having multiple clients and Gateway being activated on another Client. In such a case it is required to maintain the system alias of that client while creating services or the same error might again pop-up.
- No System Alias found for Service ‘Zxxxxxxx_xxxx’ and user ‘XXXXXX’
This is a kind of an error when service is generated according to Sdata standard instead of Odata. Although Sdata still is a type of service URL but if the front end developer is sending data in Odata format; its recipient has to be in Odata format only. And since in the above screenshot we configured a system alias for the OData service, the above error has popped up since no system alias corresponding to the Sdata version of the service was created. Services which contain “Odata” in their URL have better compatibility with OData standard and might introduce support for additional OData capabilities. The “OData” URL of a service is a feature which was added to Gateway SP3. “Sdata” is still available for backward compatibility. Bottom line is, if the service you are working with is available in “Odata” URL as well; use that instead of the “sdata” URL.
- No service found for namespace /SAP/, name Z****_P****_I****, version XXXX.
This common error usually occurs when the service is not properly transported. Under Development Environment such an issue never arises. But once the services are moved to another environment (say Quality/ Production), it is a possibility that the above message is registered in the error log. To resolve this we navigate to SPRO Transaction and expand to the below shown node.
Next, navigate to the Service and select transport.
Enter the relevant transport number and click on save. In SE10, you will now be able to see the newly added entry.
- Value ‘*XXXXX XXXX*’ violates facet information ‘maxlength=10’
This error is encountered when the Request Data attempts to be transmitted to the Backend with a data length more than what is set in the Gateway/RFC. This can be resolved by two methods –
a.) Increasing the data type length, so that it equals the length of the target data, that is actually being sent over through the gateway.
b.) Setting the Data Type length as ‘STRING’ in the RFC/Class and appropriate conversion be done in the Code; thereby avoiding the possibility of such an error being registered in the SAP.
- RFC call was not successful because of system failure ‘Unable to interpret 0,0 as a number.’
This error is encountered in two cases.
a.) When the Data being passed over the gateway is of a data type other than that what is set in the Back-end.
For e.g. – I_QUANTITY, an import parameter is set in the Code/Gateway of type QUAN 13 and data being passed is say ‘15*000’ (a user input).
b.) When the user parameters for a particular user are set in such a way (for e.g. ‘,’ to indicate ‘.’ In 15,000) that the Gateway Parameters fail to interpret the symbol. This is because in gateway we set a static data type.
We can maintain the user parameters by navigating to the SU3 Transaction Code.
- Invalid format (return table): Row Number X, Property Name ‘xxxx_xxx_xx’, Property Value ‘XX’
This error is encountered when the value returned by the service is not in the same format as expected.
For e.g. – N .Na.NaNa instead of a standard SAP Date. This throws an error at the gateway level. However, no error is logged in ST22 or relevant Dump Logger.
This error occurs when the data is stored in SAP in the above shown format. The data cannot be corrected but steps have to be taken to ensure that the data passed on to the BAPI is correct. The origin of such garbage data can be anything from the Front-end code to the Back-end code. There are no explicit steps to handle such data at Gateway Level. However, if the output format of the return table is made to be String or Char; then probably we can at least prevent from showing up an ‘HTTP request failed’ on the UI5 Frontend.
- Error while parsing an XML stream
This error is encountered when a special character is passed in a ‘READ’ URL. Standard SAP Gateway (SE80) version supports only up to 1 special character in the READ URL, in this case ‘:’ is already used, so if it was trying to pass another special character such ‘/’, then it throws a dump in the Error Log and ignores the other entered special character.
Actual Data in SAP was –
Thus, as we can see, the ‘/’ in N/A is caught as a special character; and throws an error log.
- RFC call was not successful because of system failure ‘User UK_XXXXX is already processing Purchasing docum’.
Usually such a message should pop up as an error/warning message on the UI5 screen. But if the standard BAPI being used does not facilitate sending such a message as an export parameter on the UI5 Screen and the document is being edited simultaneously by more than one person, then the gateway error log registers such a message and shows an ‘HTTP Request Failed’ on the UI5 Screen.
- Inconsistency in key field ‘i_process_order’.
A key field should never be passed blank through gateway. This setting can be done in the RFC against which the gateway service is made. If it is not necessary for that field to hold data at all times the service is called then it should be marked as optional. Or otherwise it should be made sure that this field always carries some value.
- No authorization to access Service ‘ZXXX_XXXXXX_XX_0001’.
This is a basis issue to do deal with. There are specific authorizations to access a Gateway Service. There may be required to incorporate separate roles from basis side to solve this issue.
- RFC call was not successful because of system failure ‘No authorization to log on as a Trusted System (L-‘
This is again a basis issue. Specific settings are done by the basis team to help resolve this issue.
- Invalid key predicate
This is encountered when the URL passed to call a gateway service is incorrect. By incorrect it is implied that a certain ‘key’ field is not passed in the URL which is considered as mandatory to contain data.
Below is a sample URL with an Invalid Key Predicate.
- Operation type Q does not exist in the Data Model
This is a type of error when a ‘Query’ URL is called instead of a ‘Read’. In SAP Gateway if it is known that the output contains a table of data, the gateway service at the development stage itself needs to support Query Operation. Here in the case shown above, maybe it was previously expected that output will be in the format of Input followed by single/multiple export parameters. But the URL was called with an expectation that a table will be passed on to the front end.
There can be two scenarios for the above –
a.) The URL for Query is called by mistake when it was intended to call a ‘Read’ Service.
b.) The Gateway service is made without proper knowledge of the expected output. At this point in time it is absolutely necessary to have proper co-ordination between the Gateway Developer and the ABAPer.
- Database Lock for Service ‘Z**********’ could not be set.
This situation was encountered when many users are accessing a particular service continuously. Although it did not seem to hamper any business functionality for the client, it was deemed as a potential hiccup to the UI5 application as a whole. Hence it was decided to turn on the Metadata Cache within the Gateway and since then the above issue never re-occurred. As a negative consequence of the same, it was needed to clear the gateway cache after each code drop into the production environment.
Note: Cache of only those services needed to be cleared that were transported with additional fields. That is, only those with changes to the existing ones. As a matter of concern, Each and every Service metadata cache is safe to be cleared after a code drop into Production Environment.
- RFC call was not successful because of system failure ‘Fill in all required entry fields’.
When a mandatory field (by mandatory field, we mean that the field should contain data) is missed out in the URL that is triggered, we have this entry being registered in the error log. To resolve this, it is required to check the URL again and the backend code again and ensure that all the mandatory fields contain proper data.
- Specify Positive Values Only
It is required that a quantity field cannot be passed as negative. It may also be the case that the value that is passed is being derived after multiple calculations in the front end and eventually the calculation results in a negative number as a result (scenario might be different) and thus leads to registering this error in the Error Log. The best solution to allow a negative number, is declaring the data type of the field being set to CHAR and then once the ABAP Code takes control of the parameters, it is converted to the required negative value within the code.
- Dereferencing of the NULL reference
This issue cropped up in the Production Environment and something which we had not expected. The root cause of this was, a change in the Backend Parameter, a change in the Gateway Service but the gateway service parameters not getting reflected in the production environment even after multiple transports. This was then resolved after clearing the Gateway Cache by navigating to the Transaction – /IWFND/CACHE_CLEANUP
Below are the steps to clear Gateway Metadata Cache.
1. Navigate to the Transaction /IWFND/CACHE_CLEANUP.
2. Use the F4 Help and enter the part of the Data Model whose cache needs to be cleared.
3. Choose the Gateway Service with type ‘PS’ (Public Solution).
4. Next after selecting the required Data Model press F8 (Execute).
5. Gateway Metadata Cache cleared successfully.
To conclude, most of the Gateway Error Log entries clearly explain what the error is; for the ones that do not, we can refer to the scenarios explained above and help resolve the issues. This document does not cover all the issues encountered but covers mostly those that posed a hindrance in the Production Environment. Hope this helps.
***********************END OF DOCUMENT***********************