Have you ever had to execute an RFC-enabled function module from outside the SAP system, for instance from a custom-developed Java application?
If so, then for sure you already know the SAP JCo (SAP Java Connector) Java library, and most probably you have also experienced some difficulties with it. For quite a long time I thought that using JCo is the only way of doing this, just because of the obligatory use of the RFC communication protocol. And finally, I have discovered a nice and smooth way to communicate with SAP “from outside” over HTTP, which means that you can establish the communication easier and more flexibly then ever before.
This blog refers strictly to calling RFC-enabled function modules. If you are interested in sending IDocs to SAP over HTTP, please refer to this blog:
It also assumes that your Internet Communication Framework (SICF) is configured properly, as the configuration of this framework is not the topic of this blog.
As a prerequisite, go to transaction SICF and locate the following service: sap -> bc -> soap -> rfc. Its description gives you some more details about the functionality: SOAP HTTP HANDLER FOR RFC-CAPABLE FUNCTION MODULES.
Now, right-click on that service and choose Test Service, and make sure that you allow SAP to open your web browser (in a popup that appears). Make note of the URL that is opened in the browser. Generally, this URL would look as follows: http://[hostname]:[SICF port]/sap/bc/soap/rfc?sap-client=[client]
Of course, in your particular case it will already contain a concrete host name, port number and client number.
Now that you know the communication URL, use an HTTP client to communicate with SAP. In this example, I will use the SOAP UI tool for this purpose, but it can be any application, including your custom-developed ones, of course. My goal is to execute BAPI_SALESORDER_GETLIST:
The screenshot below ilustrates the most important elements of the configuration:
- Communication method should be POST.
- The target URL for the HTTP call is equal to what we checked before when testing the service from SICF:
- One more thing that actually is not visible there, is the authentication. You have to use an SAP user name and password to authenticate your call. Of course, bead in mind the authorizations required by your particular function module.
- In the HTTP call content, declare two namespaces: the SOAP-specific namespace (SOAP-ENV above), and another one that I called RFCDEMO, but it is not the name, but the namespace “urn:sap-com:document:sap:rfc:functions” that really matters. Make sure to spell it correctly, as SAP will not accept any mistakes here. Furthermore, use the standard SOAP-specific structure: Envelope, Header and Body. And finally, in SOAP Body, use the name of the RFC-enabled function module as a node name (use the right namespace), and the parameters, equal to function module parameter names, as subnodes. It is important here that you have to declare Changing and Tables parameters (as empty tags) in the input structure. Otherwise, they will not be returned in the HTTP response. Also note that you do not have to type all the parameters, you can only use the obligatory / necessary ones (as per your requirement).
As a final outcome, you will receive the response from your RFC-enabled function module as the SOAP/HTTP Response.
What is really interesting, you can call several independent function modules without additional effort. You even get separate responses by default. Most importantly, you can use it to execute one particular BAPI and then perform a commit. For instance, if you had to create a sales order and commit it afterwards, you could use the following HTTP request:
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:RFCDEMO=”urn:sap-com:document:sap:rfc:functions”>
One more important thing to notice here is that whenever you have to pass an entry to a TABLES parameter, use the <item> tag to define an array line.
There are few more things to consider when using the approach described:
- In the examples above I only used standard BAPIs, but this will work equally well with any RFC-enabled function module.
- Unfortunately, just like with calling RFC-enabled function modules in the standard approach (from another SAP system, or over JCo), there is no monitoring tool to analyze these messages. The only status information you have is the response from the function module, that you get as the actual HTTP response. Moreover, you can also enable Logging and Debugging for such scenario. Please refer here for more details:
- In general, the solution described here should not be considered as an alternative to standard RFC processing, whenever SAP PI is in the landscape. It is safer to use RFC adapter, or encapsulate several BAPIs and additional logic in an ABAP Proxy. However, if you are not able to use SAP PI nor SAP BC for some reason, you might find my solution useful.