It is not trivial to find the coding, that hides behind an HTTP URL for the AS ABAP.
URLs on the AS ABAP need to be published and activated first of all in the service maintenance transaction SICF. Given the URL, you can browse the SICF to the service maintenance screen, lets take for example the implementation of the odata demo service /sap/opu/odata/iwfnd/rmtsampleflight.
The URL request to the AS is handled by program SAPMHTTP, which does a lot of the stuff around handling a HTTP request and in the end uses function module HTTP_GET_HANDLER_LIST to get a list of handler classes for all the nodes in the path to the requested service (You can use the FM to get the handler list for a given path, but the output is rather ugly). By looking into the handler list property of the service and its parent nodes in the tree you can find all handler classes, that potentially might apply for this service.
In this example, there is no handler present for the service rmtsampleflight itself, but in its parent node /sap/opu/odata, there is the handler class /IWFND/CL_SODATA_HTTP_HANDLER registered. In this case, this is the only class in all the nodes of the tree to our sample service and thus the only handler class that could possibly be executed. Nevertheless, there could be multiple classes e.g. several nodes in the path have a handler class, or even multiple handler classes are registered in a single node. The execution order of the handler classes seems to be in the following order: from the higher up nodes to the lower nodes in the path, in the numbered order of the handler list within a node (if there are more than one handlers per node). If there are more than one handler, then they will be executed one by one in the order just described, but every handler can control if the remaining handlers will be executed by the value the handler returns in the attribute flow_rc of the interface IF_HTTP_EXTENSION. You can jump to the implementation classes of the handlers by simply double click on the classname in the handler list.
So now that you know the handler class, how to proceed with the reverse lookup of the sicf service from here?
The good news is that for each request, the interface IF_HTTP_EXTENSION object method HANDLE_REQUEST is called for an instance of the handler class. This gives you an uniform entry point, from were you can go forward and dive into the coding. You can set breakpoints, that are triggered when you perform the HTTP request and nicely debug all the workings on the server.
The bad news is that there is no common implementation of what is happening at this point. Each handler class does things in its own way, so you are on your own from there on. By the way you also can write your own handler class, SAP provides some documentation about how to do that in the SAP help, just google for "sap Developing a HTTP Request Handler " and pick a more recent sap help site.
For the rmtsampleflight example this means that by debugging you can find out that the odata service is implemented by a complex framework: the Netweaver Gateway in package /IWFND/FRAMEWORK. With some patience you can find the tables where the metadata information about the odata services are stored and from those tables find which reports and thus transactions access them. But more efficient is in fact to look up Netweaver Gateway maintenance and find the transactions from SCN or the documentation. In this case transaction /IWFND/MAINT_SERVICE to manage and register odata services.
- SAP Managed Tags:
8 Comments
