We all know about adapter user-module for java adapters, e.g. File, JMS, JDBC, etc. But, what about for the HTTP adapter, which is an adapter in the ABAP stack?
In this blog, we will take a look at how we can write an user-module for the HTTP adapter.
Obviously, since HTTP adapter is an ABAP adapter, the user-module will have to be in ABAP code.
The concept is as follow. The HTTP adapter is a service in ABAP, which is named “adapter_plain”. We can examine this service with tx:SICF:
When we examine the details of this service, we see that this service executes the class, CL_HTTP_PLAIN_INBOUND.
Consequently, we can create another service, which also invokes this class. And, in addition, this service can invoke another class right before it. This additional class would be our user-module.
So, the steps would be the following:
- Create a “Z” class.
- Create a new service in SICF.
- Add two handlers to the service in the following order: the “Z” class and CL_HTTP_PLAIN_INBOUND.
Sample HTTP User-Module
For demonstration purpose, in this blog we will create an XML wrapper for the HTTP payload. The HTTP payload, which is non-XML, can contain any data. The user-module will wrap the non-XML payload with an XML element. This way, once in PI, we can use message mapping to decode the content of the payload.
1. Create the “Z” class in ABAP
- Enter tx:SE24 to create a class. I will give it the name: zcl_xml_wrapper
- For the interface, enter: IF_HTTP_EXTENSION
- With this interface, a method will automatically be available.
- Double-click on the method to enter the code, which will be the user-module. Below is a sample code to wrap the payload with XML:
method IF_HTTP_EXTENSION~HANDLE_REQUEST. DATA: wrap TYPE string, xmlWrap1 TYPE string, xmlWrap2 TYPE string, payload TYPE xstring, xml1 TYPE xstring, xml2 TYPE xstring, new_payload TYPE xstring, util TYPE REF TO cl_xms_part_util. if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_mand. payload = server->request->get_data( ). util = cl_xms_part_util=>getinstance( ). xmlWrap1 = '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><root><mydata>'. xmlWrap2 = '</mydata></root>'. CALL METHOD util->convert_string_to_xstring EXPORTING * CHARSET = 'UTF-8' in = xmlWrap1 RECEIVING out = xml1. CALL METHOD util->convert_string_to_xstring EXPORTING * CHARSET = 'UTF-8' in = xmlWrap2 RECEIVING out = xml2. CONCATENATE xml1 payload xml2 INTO new_payload IN BYTE MODE. server->request->set_data( new_payload ). endmethod.
- Save and activate the class.
2. Create a new service in SICF
- In tx:SICF, navigate to the “xi” node and right-click to create a new sub-element:
- Create a unique name for the service. In our test case, I use the name: wrap
- Provide a description for the new service and go to the “Handler List” tab. For the handlers, enter two classes. The first one is the one we created previously, ZCL_XML_WRAPPER. The second one is the standard class used by the service “adapter_plain”, CL_HTTP_PLAIN_INBOUND.
3. Test the user-module
The user-module can be tested using any HTTP test tool. The URL must be:
We used a standard test tool that has been featured on SDN in the past. It does not matter what service, interface or namespace are used. Even though in XI Monitor errors will occur due to no configuration in the Integration Directory, we are only interested the content of the payload to verify if the user-module was executed.
Using SXMB_MONI, we can examine the payload: