The SAP standard function module HTTP_GET can be used to perform an HTTP GET Request from a target URL. The problem is that an RFC Lookup cannot be performed on that function module since it is not remote-enabled. The purpose of this PoC is to show the use(s) of remote-enabling this function module.
The exweb service which will be used is the Calculator web service (Add Operation) which can be found here: http://www.html2xml.nl/Services/Calculator/Version1/Calculator.asmx?op=Add
The service description for the HTTP GET is:
Take note that the request does not have an HTTP Body and that its parameters are all placed in the URL along with the GET method.
For simplicity, the remote-enabled function module will have to be created in your XI/PI system (after all, that is where the call takes place) and that it is also existing as a business system in your Integration Directory.
Once the function module HTTP_GET is executed in SE37, the service description above now translates into the values below:
And here is the response taken from the RESPONSE_ENTITY_BODY:
Now, the idea is to copy or reference this function module so that it can be imported in XI/PI. Here are the steps needed:
1. In the function builder screen, press Ctrl+F5 to copy this function module
2. Once the copy has been executed, go to the attributes tab and then change the radio button from Normal Function Module to
Remote-Enabled Module
3. Create a data type (data element) in SE11 that references the Domain CHAR400, the reason for this is that C400 is shown as the data type when the function module is executed in debug mode and that generics are not allowed in remote-enabled function modules.
4. Create a data type (structure) in SE11 with a component that references the data type created in Step 3. In this document, CONTENT is used
5. Go back to the copied function module and replace the all c with the data element created in step 3 and then reference the tables with those in step 4
Importing:
Exporting
Tables
6. Go to the source code tab and then paste the code below just after the last *”———————————————————————- line:
CALL FUNCTION ‘HTTP_GET’
EXPORTING
ABSOLUTE_URI = ABSOLUTE_URI
REQUEST_ENTITY_BODY_LENGTH = REQUEST_ENTITY_BODY_LENGTH
RFC_DESTINATION = RFC_DESTINATION
PROXY = PROXY
PROXY_USER = PROXY_USER
PROXY_PASSWORD = PROXY_PASSWORD
USER = USER
PASSWORD = PASSWORD
BLANKSTOCRLF = BLANKSTOCRLF
TIMEOUT = TIMEOUT
IMPORTING
STATUS_CODE = STATUS_CODE
STATUS_TEXT = STATUS_TEXT
RESPONSE_ENTITY_BODY_LENGTH = RESPONSE_ENTITY_BODY_LENGTH
TABLES
REQUEST_ENTITY_BODY = REQUEST_ENTITY_BODY
RESPONSE_ENTITY_BODY = RESPONSE_ENTITY_BODY
RESPONSE_HEADERS = RESPONSE_HEADERS
REQUEST_HEADERS = REQUEST_HEADERS
EXCEPTIONS
CONNECT_FAILED = 1
TIMEOUT = 2
INTERNAL_ERROR = 3
TCPIP_ERROR = 4
DATA_ERROR = 5
SYSTEM_FAILURE = 6
COMMUNICATION_FAILURE = 7.
endfunction.
Save and Activate.
7. Import the function module in your XI/PI system.
Now, there are two ways to use this function module:
1. Via Graphical Lookup, the steps needed to be followed are in this document:
Take note that the unused fields are deleted. So for our example:
Note: LookUp In 2 is for a proxy server.
And the result of the lookup below:
2. Via treating the HTTP GET scenario in which your receiving system uses an RFC Receiver
Sample request mapping:
Sample response mapping:
The actual response seen in SXI_MONITOR:
The HTTP Response Headers are placed on the Response Headers.
With that, this Proof of Concept ends. I hope that this document has been informative and leave it up to the developer to explore on error handling, the use of SSL (for https)… Have fun exploring!
Hi Mark, thanks for posting this example.
Could you also share your views on the pros and cons of this approach? (e.g. monitoring, error handling, troubleshooting)
Hello Aaron,
Here are some of the pros:
1. Requires little ABAP coding
2. Can be used in both graphical and udf/java mapping lookup
3. RFC Lookups can be monitored in CC monitoring, while in the RFC Receiver, this can be monitored normally.
4. An HTTP body is not needed since the call is made via RFC.
5. You can use fault messages for your application errors.
I would not say it is the cons, but rather a limitation. Please feel free to add more:
1. If you are using SSL, then an RFC destination is needed. Not sure how you can have dynamic values in your RFC destination
2. It is still limited to the 200-character limit that SAP has on URLs
That’s all I can think of for now 🙂