Just a couple of days ago I found myself confronted with a little problem.

I was asked to update data in an SAP system from a web page.

Initially I found all sorts of approaches – writing a custom BSP, developing my own WebDynPro page, post the data into some database and import it from there later…  But every single one of these approaches seemed way to complex for the task at hand.

But I did find one technology that seemed almost too simple: A WebRFC.

So what is it?

A WebRFC is an almost forgotten option to call a simple ABAP RFC through a simple URL, with URL encoded parameters.

Why simple ABAP RFC?

Due to the URL encoding you are a bit limited in passing table parameters and complex data types (just to be sure – you can deserialize in your RFC but lets not go there.)

Does it work with every RFC?

Well – there is a specific interface you have to implement. But you can always wrap the RFC you wrote a year back in a new WebRFC.

Now that we are throught the executive summary – I will walk you quickly through a sample on how you can use a WebRFC to generate some JSON which you can consume in your HTML5 application (hopefully you are using the SAPUI5 library).

Step 1: Create a regular function module

Open SE37, create a new function module (in this case I name it Z_SAMPLERFC) and assign it to a function group (in case you don’t have one handy – you can create them in SE80).

There is no need to define it as remote enabled.

Step 2: Implement the right interface.

In order to make an RFC that can be used as a WebRFC it hast to comply to a defined interface.

Specifically we need to provide a couple of fields which will be populated by the WebRFC handler or provide it with our output.

There are two different sections of the interface, the table parameters as well as changing paramters.

So lets address the table parameters first.

If your system informs you during the interface definition that table parameters are obsolete, just acknowledge it by pressing ENTER 😉

Open the tab called TABLES.

Here we need to define 3 different table parameters:

QUERY_STRING LIKE  W3QUERY (QUERY_STRING is the name of the variable, LIKE is its typing and W3QUERY is its actual type)

This table will contain the content the key-value pairs passed as url parameters to the WebRFC. More on this later.

HTML LIKE  W3HTML

This table will be filled with our output later by the called function module and returned to the client.

MIME LIKE  W3MIME

If we where to return an image or any other binary data we can use the MEMI table as a vehicle to passt it back to the client.

Since we will be generating JSON later on we will not be using the MIME table but the HTML table.

Besides the actual payload going in and out of our RFC there is some meta-data that can be provided through the WebRFC interface. This happens using the a number of changing parameters.

They need to be defined on the “Changing” tab:

Specifically we need to define the CONTENT-TYPE for the http response by setting the CONTENT_TYPE field. We will set a default value for it, but it cold also be changed bynamically within the function module.

CONTENT_TYPE LIKE  W3PARAM-CONT_TYPE DEFAULT ‘application/json’

For MIME data its length has to be provided in the CONTENT_LENGTH variable, but since we are using HTML as the output table we can just leave it empty after defining it:

CONTENT_LENGTH LIKE  W3PARAM-CONT_LEN

The return code can be used to define whether the ITS session or the RFC connection are to remain open or get closed, after the call – the default value (0) which leaved the ITS session in place for later use, and terminate the RFC connection.

RETURN_CODE LIKE  W3PARAM-RET_CODE

Step 3:  Implementing some functionality behind the interface

As mentioned before WebRFC allows you to access your url parameters though the use of the QUERY_STRING table – which already breaks the parameters down for you as key-vlaue pairs.

In this first section of the code we get the value of a parameter called “_Name” into a variable called name.

DATA: name TYPE STRING.

SORT QUERY_STRING DESCENDING.

READ TABLE QUERY_STRING WITH KEY NAME = ‘_Name’.

name = QUERY_STRING-VALUE.

With the parameters available we can now do all sorts of ABAP magic … or for the sake of this post, just return it to the caller as a JSON array:

this second section of the code creates a new html document for us – again a table contrainign lines… and we fill it with a bit of JSON and write it into the table HTML which we created earlier.

So overall the code looks like this:

DATA: htmldoc LIKE LINE OF HTML.

CONCATENATE ‘{“results”: [ {“key”: “name”, “value”: “‘ name ‘”}, {“key”: “phone”, “value”: “911”}]}’ INTO htmldoc-line.

INSERT htmldoc INTO TABLE HTML.

The overall function should look very much like this:

FUNCTION Z_SAMPLERFC.

*”———————————————————————-

*”*”Local Interface:

*”  TABLES

*”      QUERY_STRING STRUCTURE  W3QUERY

*”      HTML STRUCTURE  W3HTML

*”      MIME STRUCTURE  W3MIME

*”  CHANGING

*”     REFERENCE(CONTENT_TYPE) TYPE  W3PARAM-CONT_TYPE DEFAULT

*”       ‘application/json’

*”     REFERENCE(CONTENT_LENGTH) TYPE  W3PARAM-CONT_LEN

*”     REFERENCE(RETURN_CODE) TYPE  W3PARAM-RET_CODE

*”———————————————————————-

DATA: name TYPE STRING.

SORT QUERY_STRING DESCENDING.

READ TABLE QUERY_STRING WITH KEY NAME = ‘_Name’.

name = QUERY_STRING-VALUE.

DATA: htmldoc LIKE LINE OF HTML.

CONCATENATE ‘{“results”: [ {“key”: “name”, “value”: “‘ name ‘”}, {“key”: “phone”, “value”: “911”}]}’ INTO htmldoc-line.

INSERT htmldoc INTO TABLE HTML.

ENDFUNCTION.

As always don’t forget to Check, Save and Activate the RFC.

Step 4: Activate the RFC as a WebRFC

Once that is done… remember the name of the RFC and launch SMW0 the Web Repository

From the Internet Release Menu -> Function Module (F7)

Put in the name of your RFC

and hit the open padlock icon to make it available in public.

Step 5: Call the RFC

http(s)://<your system>:<your port>/sap/bc/webrfc?_FUNCTION=Z_SAMPLERFC&_Name=<your name>

And you receive beautiful JSON back.

Step 6: Mind all the stuff not mentioned here

Make it real – of course you can add exceptions, return values and error handling, as well as input validation to your RFC – but this should help you get started – SAP ERP generating JSON using an RFC called through HTTP.

If you need to configure security for this service you can configure the service in SICF.

How much simpler can it get. 

Cheers!