As Ole Miss continues to expand its usage of SAP’s NetWeaver Gateway, we have learned a few useful tips and tricks towards debugging and refining our OData feeds. I would like to take this opportunity to share these, some of which seem blatantly obvious now.
Background
At the University of Mississippi we utilize the speed and portability of SAP’s NetWeaver Gateway on multiple fronts. Some of our more traffic-heavy “game changers” are the following:
- Official Ole Miss App ~ iPad Edition – An informational app which integrates with our backend SAP system to provide an interactive campus map, sports scores, calendar events, and directories which include people, departments, organizations, committees, policies, and more.
- Attendance Tracking System – A pilot program integrated with the SLcM Attendance Tracking package allowing the use of touch screen barcode scanners placed in classrooms.
- Admissions Counselor iPad App – An app used by traveling admissions counselors to view and update student records as they visit high schools for recruitment.
- A variety of web based solutions – Services that expose our backend SAP data on people, courses, departments, committees, to our public-facing website.
Common Mistakes
Selecting a valid “key” value to distinguish individual entries is one of the most common challenges we have faced with our services. You have the ability to set keys to whatever you like; however, there is not an immediate check to ensure that what you have chosen is, in fact, a well-formed key.
With many of our projects, a developer creates a gateway service for a long-standing SAP Remote Function Call (RFC) from which the original developer is no longer in the picture. The new developer wraps and deploys the service and passes it to the consumer for use.
Non-Unique Keys
For many of our Web-based implementations, PHP was used to consume the OData feed, and this is where errant behavior was noticed. The PHP OData library,when given a query feed without a truly unique key, will process the feed without a warning or error. The resulting dataset will have lost values for entries with matching keys. The non-key fields will be lost except for the first entry due to the consumption mechanisms of the PHP OData library.
NULL Value Keys
As is common with some older SAP implementations, longer text fields (i.e., notes) are split into finite character length fields and placed in a table return. In an effort to return information about our standing committees, we generated and began consumption of OData feeds to retrieve descriptions and memberships for display on our public facing website. Of the 200+ committees, queries for 99% worked as expected. However, in some cases, a Gateway error was occurring and was visible even viewing the XML feed directly in a web browser.
| Error Message: |
|---|
| /IWFND/COD/011 - The SAP system could not process your request. Contact your administrator |
/IWFND/ERROR_LOG is a very useful transaction for identifying any further details about the origin or conditions of an error. I recommend checking this first to try and discern the nature of the error.
Viewing the Error Context in the log, we were able to identify the called URI as a valid request. Our next step was to circumvent Gateway and run the RFC with the provided criteria directly. At first glance, the RFC appeared to be sending a valid response.
As part of the SAP NetWeaver Gateway system, classes are generated given your RFC and mapping decisions. At this point in debugging, it can be very useful to break into these, set breakpoints to trace the exact point of failure, and identify the culprit.
From the Object Navigator (se80), select “Class / Interface,” and search for your data model with a wildcard (*) on the end. You will see a list of related classes. For this case we selected the entry that ended in “_Q_D.” The “Q” represents Query, and “D” is the subclass that contains the methods we need to access. Navigate to “Methods,” “Redefinitions,” and open “/IWFND/IF_BEC_BOP~EXECUTE.”
The line “call function mv_rfc_name destination mv_destination” marks the start of the code where the outside SAP RFC is called and the return is mapped. Place a breakpoint somewhere prior, and step through watching, in particular, the value of “sy-subrc” and “ls_response.”
Within “ls_response,” we were able to identify that some returns included a table row with a NULL value. As this response was mapped in Gateway as a key, the mapping will obviously fail for some values and ultimately produce a run-time error.
For a quick, easy fix, we edited “/IWFND/IF_BEC_BOP~EXECUTE” following the function call and added in a check for a NULL line and removed it if it was found. A more long standing fix would be to wrap the RFC in SAP and return a string type to avoid dealing with a table query.
Conclusion
In dealing with any service issues, my first advice is to check the S_COR_ID-VALUE mappings and be sure they are non-NULL and unique for all cases. When in doubt, check the logs and use the debugger.
- SAP Managed Tags:
