This documentation shows an easy example how to provide a JSON webservice. There is also an example how to consume a JSON webservice.
There are several ways how to implement a webservice. This example shows how to use the GFMC (Generic Function Module Call) of the EPO connector in order to expose a function module as a JSON web service on a SAP server.
¶ Function module Z_EPO_JSON_STRING
In this example, we implement an 'echo' webservice, which takes a string 'STRING' and an additional parameter 'REVERSE' to reverse the argument. The result is passed in the parameter 'RESULT'.
FUNCTION Z_EPO_JSON_STRING .
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(STRING) TYPE STRING
*" REFERENCE(REVERSE) TYPE FLAG
*" EXPORTING
*" REFERENCE(RESULT) TYPE STRING
*"----------------------------------------------------------------------
" string - webservice:
" return the string;
" if 'reverse' is not an empty string, reverse the string
DATA:
lv_reverse TYPE flag,
lv_char TYPE char1024.
" conversion to character in order to handle an string with spaces
lv_reverse = reverse.
IF lv_reverse IS INITIAL.
" simply copy:
result = string.
ELSE.
" reverse that string
" note: STRING_REVERSE does not handle strings..
lv_char = string.
CALL FUNCTION 'STRING_REVERSE'
EXPORTING
string = lv_char
lang = sy-langu
IMPORTING
RSTRING = lv_char
EXCEPTIONS
OTHERS = 0 " ignore errors
.
result = lv_char.
ENDIF.
ENDFUNCTION.¶ Parameters
For a clean interface, there are only importing and exporting parameters. We do not use: changing- / tables parameter and do not raise exceptions. The error handling should supply readable error messages into exporting parameter(s).
Note: usually, the importing/changing/tables/exporting parameters are mapped to separate JSON sub-objects. If there are only importing and exporting parameters, we can use a transformation in order to receive only importing parameters and to return only exporting parameters (see 'field mapping').
¶ JSON request and response
The import parameters 'STRING' and 'REVERSE' should be posted in such a JSON structure:
{
"string":"test",
"reverse":"X"
}
The result should be returned in such a JSON structure:
{
"result":"tset"
}
¶ SICF settings
In SICF, it is required to activate an element, which uses the EPO handler: activate the 'epo1soa' / 'jsonhandler'
..which uses the /EPO1/JSONHANDLER handler:
Logon data: supply the SAP-client and the language (otherwise, it would be necessary to specify the SAP-client as URL parameter). If there are multiple SAP-clients to maintain, it would be possible to define a separate SICF element for each client - or to specify the sap client as URL parameter (e.g. '?sap-client=100&sap-language=DE').
¶ EPO Connector Customizing
With the definition of a service / operation, the EPO framework will be enabled to make a function module accessible as a webservice.
Start the transaction /EPO1/EXC, which is an area menu
¶ Creation of number ranges for EPO Connector logging
If not exists, define two number range. For EPO services, we use the number range '00' for incoming services and '01' for outgoing services
Transaction /EPO1/EXC
- EPO Connector Configuration
- Maintain default number range /EPO1/NOR
Create the intervals '00' and '01'':
- 00: 0000100000000000 0000199999999999
- 01: 0000200000000000 0000299999999999
¶ Creation of the EPO Connector Service Name
Transaction /EPO1/EXC
- EPO Connector Configuration
- In: Maintain EPO Runtime service configuration
Create a new service 'EPOFMJSON_STRING_REVERSE':
Important fields:
- Direction of service: this is an inbound service (called from outside)
- Operation mandatory: requires a defined operation (otherwise, ANY function module could be called by this service - which is not nice on a productive system)
- Default operation: allowes us to omit the specification of the operation name as URL parameter
¶ Creation of the EPO Connector Operation
When using GFMC, the operation is mapped to the function module. Otherwise, the operation could also be mapped to another function module, using the menu entry GFMC: Change processing FM for given operation.
Transaction /EPO1/EXC
- EPO Connector Configuration
- Inbound Service Configuration
- In: Maintain EPO Runtime service configuration
Create a new operation 'Z_EPO_JSON_STRING'
Important fields:
- Number range object, Number range number: used to identify individual log lines
- Processing type: S - synchronuous, will be handled immediately
- Loggig of the EPO header (implicit), Message (in- and outgoing), Meta data (in- and outgoing)
- Processing FM: /EPO1/GFMC_JSON_PROCESSINGFM handles the JSON processing
- XSLT in: /EPO1/EXC_JSON_IMPORT_STRUC creates the 'IMPORT' JSON sub-object for input parameters
- XSLT out: /EPO1/EXC_JSON_EXPORT_STRUC removews the 'EXPORT' JSON sub-object from exporting parameters
- Field mapping: use the configurable field mapping (otherwise, all JSON field names will be in uppercase)
- Response format: t - using a transformation in order to create the JSON response
- Response strip: 1 - remove empty fields/table lines from the response
¶ the API path..
We want now to create the API path, which is used to invoke the service.
- the first part is the 'server' part and depends on the visibility / accessability of Your SAP system: host name and port
http or https, servername, port (if not the default port '80' for http, '443' for https)
- the second part is the service path in the SICF (or of the alias, if defined)
- the third part is the EPO service
- the last part is the EPO operation
Together we get something like
http://my.server.com:80/epo1soa/jsonhandler/EPOFMJSON_STRING_REVERSE/Z_EPO_JSON_STRING
¶ Field name mapping - /EPO1/FIELD_MAP
All the names of the JSON request / response has to be mapped to ABAP fields. To make the life easier, we will use the table /EPO1/FIELD_MAP in order to maintain the mapping. In our case, the field names are very simple, so a 'lowercase' format would be sufficient.
For this example, we will simply use the [lowercase] - mapping: every ABAP letter will be mapped to a lower-case JSON letter.
Note: when using the [camelCase] or [CamelCase] - mapping for inbound, use the camelCase - IMPORT - transformation /EPO1/EXC_JSON_IMPORT_STRUC_CC instead of /EPO1/EXC_JSON_IMPORT_STRUC. Otherwise, the 'IMPORT' - field name will be mapped to '_I_M_P_O_R_T' or 'I_M_P_O_R_T', which will not work.
Alternatively, You might map the INPUT field explicitely (possible, but not recommended):
¶ Static field mapping
Sometimes, it is more convenient to have the mapping information directly in code instead of relying on customiziation.
The contents of the field name mapping - /EPO1/FIELD_MAP can also be defined in code, but the conversion ABAP <-> JSON has to be called manually (using the methods /EPO1/CL_TOOLS=>ABAP_TO_JSON or /EPO1/CL_TOOLS=>JSON_TO_ABAP).
¶ further steps
¶ Reduce JSON Output Data
Sometimes, an universal webservice will provide several completely different data structures (e.g. user data, invoice data, material data, ..).
This can be done by defining a large structure, which can hold each of the data to be delivered. However, the 'other' structure elements should not be returned.
Or, some 'initial' fields should be removed from the response (e.g. date fields, character strings, ..).
There are 2 implementations, wich are controlled by the response format in the service configuration table /EPO1/CONFIGOUT:
- dynamically reduce the output structure (implicit, a transformation is used)
response format: 't', 'tb' or 'tbi'
- strip the generation of JSON elements (implicit, the function module /EPO1/EXC_ABAP_TO_JSON is used)
response format: '0', '1', '2' or '10'
Please note, that the output of those both methods differ in some details (mapping of field names with '/', number- or date formatting).
¶ Strip the output structure
Requirement: define one of the response formats: 't', 'tb' or 'tbi' Please note, that the stripping of output structures is limited to structures (und substructures); the inner content of a table cannot be stripped.
Define the export parameter ES_EPO1_ABAP_STRIP with the type /EPO1/EXC_ABAP_STRIP_STRUC. This structure contains all necessary parameters, which are used in the method /epo1/cl_tools=>abap_strip.
Meaning of the ABAP-STRIP - parameters:
- IT_KEEP: list of elements, which should be kept
- IT_STRIP: list of elements, which should be stripped (except, when listed in IT_KEEP)
- IV_STRIP_INITIAL: if 'X', remove all empty elements (structures, tables, primitive elements)
- IV_RECURSIVE: if 'X', recurse to all substructures
- IV_STRIP_EVERYTHING: strip all elements, except when listed in IT_KEEP
Note 1: elements and sub-elements are to be written as in ABAP (e.g. ELEMENT-SUB_ELEMENT-SUB_SUB_ELEMENT-...)
Note 2: the upper most element is the generated element 'EXPORT' for export parameters, 'CHANGING' for changing parameters and 'TABLES' for tables parameters. For simplicity, we expect, that only export parameters are used in a webservice - function module.
Note 3: it is not possible to change the contents of a table; only structure element might be stripped.
Example - export parameters of the function module for the webservice:
USER_DATA TYPE USR01
MATERIAL_DATA TYPE MARA
MESSAGES TYPE BAPIRET2_Tremove everything except the user data:
es_epo1_abap_strip-iv_strip_everything = 'X'.
APPEND 'EXPORT-USER_DATA' TO es_epo1_abap_strip-it_keep.
Note: usually, we know exactly, which data are to be returned, so this is the preferred way to strip output data. This will work even if the webservice is enhanced in the future by returning additional data.
remove all empty structures from export:
es_epo1_abap_strip-iv_strip_initial = 'X'.
Note: this is maybe the most universal setting; leaving only structure elements, which has been filled
remove every empty element (recursive):
es_epo1_abap_strip-iv_strip_initial = 'X'.
es_epo1_abap_strip-iv_strip_recursive = 'X'.
Note: this stripping might be useful, when very large structures are returned, where most of the elements are initial and does not need to be returned. So we can remove all of the unused data. If there are elements, which should be returned, even when initial - then simply add the names of these elements to the IT_KEEP list.
remove only the material data (complete structure):
APPEND 'EXPORT-MATERIAL_DATA' TO es_epo1_strip-it_strip.
remove only the material number from the material data (maybe useless.. just so show, how it works):
APPEND 'EXPORT-MATERIAL_DATA-MATNR' TO es_epo1_strip-it_strip.
¶ Strip the generation of JSON elements
Requirements:
- define one of the response formats: '0', '1', '2' or '10'
- check the checkbox 'Field mapping (even, if there is no customizing for field name mapping)
For details, please refer the section /EPO1/JSON_STRIP
¶ beautify the API path
As seen before, the API path contains the EPO service (which could be defined with a lowercase name) and the operation, which is always to be written in uppercase.
The easy part is the usage of another EPO service: go back to the configuration of the EPO service, create a lowercase/camelcase - servicename (e.g. stringReverse) and a new operation.
The next step is to map the new service/operation to Your function module:
Transaction /EPO1/EXC: navigate to the item 'GFMC: Change processing FM for given operation'
and create a new entry with Your new service name, choose a new (lowercase/camelcase) operation name and Your existing function module name, e.g.:
- service: stringReverse
- operation: reverse
- version: (leave empty)
- function module: Z_EPO_JSON_STRING
Now, Your function module is (also) available with the new API name.
old
http://my.server.com:80/epo1soa/jsonhandler/EPOFMJSON_STRING_REVERSE/Z_EPO_JSON_STRING
new
http://my.server.com:80/epo1soa/jsonhandler/stringReverse/reverse
Recommendation: keep only one service/operation, delete the unused operation and then the unused service (then, the 'old' path will not work anymore).
¶ use GFMC - special parameters
E.g. to read the request - http-headers, analyze the call path, etc., or to control the response. It is possible to specify HTTP headers and cookies.
Example:
...
*" REFERENCE(IT_EPO1_REQUEST_HEADERS) TYPE TIHTTPNVP
...
DATA:
ls_http_header LIKE LINE OF it_epo1_request_headers,
lt_path_elements TYPE TABLE OF string,
lv_path_element LIKE LINE OF lt_path_elements.
" get the absolute path
" use '~path_info_expanded' in order to get the relative path (starting after the SICF node name)
READ TABLE it_epo1_request_headers INTO ls_http_header WITH TABLE KEY name = '~path'.
SHIFT ls_http_header-value LEFT DELETING LEADING '/'.
SPLIT ls_http_header-value AT '/' INTO TABLE lt_path_elements.
¶ enhance the logging by using FKEY1..FKEY4
Especially, when there is a lot of log entries, the usage of the foreign keys may help to filter for / find the right line of interest.
When calling the webservice, simply supply some key fields of interest. Preferrably - use the same FKEY field for the same kind of value, if there are multiple webservices used for similar data (like order creation, order change, order read ..) they should put the order number each into the same FKEY field.
Example:
...
lo_json->call_service(
EXPORTING
is_request_data = ls_request
iv_fkey1 = CONV #( iv_order_number )
iv_fkey2 = CONV #( iv_position_number )
IMPORTING
es_response_data = ls_response
et_response_headers = lt_response_headers
es_callstatus = ls_callstatus ).
...