Skip to Content

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.

sicf rmtsampleflight.png

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.

handlerlist rmtsampleflight.pnghandlerlist opu.png

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.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Jibin Joy

    Hi Christian,

      I followed this document to create my own request handler alone with ODATA Handler  but no luck it is calling only ODATA Handler .Even i deleted ODATA Handler from the list still it is calling /IWFND/CL_SODATA_HTTP_HANDLER .

      Can i have ur valuable suggestion to overcome this situation

    Regards,

    Jibin Joy

    (0) 
  2. Kanwardeep Singh Gill

    Hi,

    We need to use a custom request handler in SICF for an Odata service. We created a request handler by implementing HANDLE_REQUEST method of IF_HTTP_EXTENSION and assigned this request handler in the Request Handler List of the relevant node.

    However, when we call the odata service with the path http://<HOSTNAME&gt;:<PORT>/sap/opu/odata/<customer namespace>/<service>, the custom request handler is not getting triggerred.

    When we debugged HTTP_DISPATCH_REQUEST API,  we observed that there is already a request handler /IWFND/CL_SODATA_HTTP_HANDLER assigned at node Odata,

    The API HTTP_GET_HANDLER_LIST provides our custom request handler, however, it is not triggered because the request is already completed with /IWFND/CL_SODATA_HTTP_HANDLER.

    Awaiting a resolution or at least hints to resolve this problem.

    Thanks!!!

    (0) 
      1. Dave Price

        I was able to insert our CORS HTTP headers by adding my new pass-through HTTP handler class to the handler list of the odata node in SICF — thankfully the HTTP headers are persistent across the handlers in the list.

        I tried an internal alias and it seemed to work at first (it DOES run the handler list at the service the alias points to irrespective of higher-level nodes e.g. the odata node) because I got back my header updates with metadata when I pointed at the service, but when I tried queries SAP could not interpret the path to the query (the additional slash before the entity set query seemed to confuse it, it returned “No service found for namespace”).  Maybe it works better with an external alias, or I’m missing something.

        It’s really odd that SEGW adds the odata handler class to the handler list of the project service nodes since it never runs there (the HTTP handler at the odata node runs first, and doesn’t let any HTTP handlers run after it), and I’m not even sure it can run there.  Probably I’m missing something, I didn’t play around with it that much due to time constraints, since I’d already solved the problem at the odata level (which is more efficient than adding the handler to every project anyway anyway).  If I had more time I’d try removing the odata HTTP handler class from the odata node to see if the handler class could run at the project service node.

        Hope this helps someone!

        (0) 
        1. Kanwardeep Singh Gill

          We cretaed an external alias for our service application and we were able to query odata requests without any errors.

          Moreover, we assigned custom HTTP handler class at the service level. Also, ensure that you inform the framework to call the standard HTTP handler/IWFND/CL_SODATA_HTTP_HANDLER by passing a parameter in your custom HTTP handler which ensures that rest of the handlers are called after your handler class is executed.

          (1) 
          1. Dave Price

            Interesting, thanks for sharing.

            We also found we had to add some code to handle the preflight OPTIONS method, so now the custom class will return 204 and set the FLOW_RC parameter to zero to prevent additional handlers from running if it sees OPTIONS, but otherwise sets FLOW_RC to 2 for additional processing by the SAP Odata handler.

            A little surprising that the odata handler doesn’t handle the OPTIONS method as it doesn’t take much.  Possibly I am missing something or they handle it in a later service pack.

            (1) 
  3. sankara rao bhatta

    Hi,

    I see some standard SICF services that we use  in SRM where I dont any handler class listed. for example service “srm”. How do we debug these kind of services?

    thanks,

    sankar.

    (0) 

Leave a Reply