Providing the RFC
Components of a Lobster RFC
A function module provided in the Lobster Integration Server/Lobster_data has three components:
A RequestListener with configuration in file ./etc/sap.xml,
an interface definition of the RFC as XML file and
an implementation of the RFC as Lobster_data profile with a Message Input Agent.
The request that is sent by the SAP system is received by the RequestListener. If the request matches the name of the RFC and the interface definition, the data is sent to the processing profile via Message.
Listener Configuration in ./etc/sap.xml
The following XML section shows the configuration of a RequestListeners for the RFC MY_RFC. The first argument (here sap) has to match the defined SAP alias.
<Call name="addRequestListener"> <Arg>sap</Arg> <Arg> <New class="com.ebd.hub.datawizard.sap.DataWizardForwardRequestListener"> <Set name="functionName">MY_RFC</Set> <Set name="xmlFile">conf/MY_RFC.xml</Set> <!--Set name="messageServiceName">servicename</Set--> <Set name="messageContext">System</Set> <Set name="messageQueue">MY_RFC</Set> <Set name="datawizardProfile">MY_RFC</Set> <Set name="conversionType">XML</Set> <Set name="useResponse">true</Set> <Set name="synchronCall">true</Set> <Set name="clearTablesForResponse">false</Set> </New> </Arg></Call>The class com.ebd.hub.datawizard.sap.DataWizardForwardRequestListener will be provided with the SapConnectionService.
The functionName defines the name of the RFC, xmlFile is the path to the interface definition. The message queue is defined in parameters messageContext and messageQueue. The processing profile dataProfile has to be active and needs to have an Input Agent of type Message and the corresponding context and queue. The conversionType can have one of the values XML, CSV or FR and must match the document type of the profile. The messageServiceName is only necessary if you do not use the default message service. Usually this line can be removed.
If the response is to be used (useResponse), the call must also be synchronous (synchronCall). The clearTablesForResponse parameter is only relevant in cases where large amounts of data are passed as TABLES parameters in the request, but are not to be sent back in the response.
RFC Interface Definition as XML File
The interface definition is done in an XML file whose path is specified in the listener configuration in parameter xmlFile. The structure of the XML file is checked via the DTD file sap_rfc_configure_1_0.dtd, which must be available under the path ./etc/dtd/. The root element is called RFC and the name of the RFC is expected in the name attribute. It must match the functionName in the listener configuration.
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE RFC PUBLIC"-//EBD Integration//DTD SAP RFC Configuration 1.0//EN""http://www.ebd-entwicklung.de/dtd/sap_rfc_configure_1_0.dtd"><RFC name="RFC_name"> <!-- Further settings--></RFC>Section <!-- Further settings--> contains the definition of the
import parameters as simple fields or 'flat' structures,
export parameters as simple fields or 'flat' structures,
table parameters and
exceptions.
We assume that the basic concept of an SAP RFC interface (ABAP) is known. All parts of the interface are optional.
IMPORT Parameters
<INPUTPARAMS> <!-- Field definitions and/or structure definitions --></INPUTPARAMS>EXPORT Parameters
<OUTPUTPARAMS> <!-- Field definitions and/or structure definitions --></OUTPUTPARAMS>TABLE Parameters
<TABLES> <TABLE name="name" refname="tablerefname" description="description" tabletype="type"> <ROW> <!-- Field definitions --> </ROW> </TABLE> <!-- Further table definitions --></TABLES>Every TABLE definition contains exactly one ROW. One can imagine the ROW as a nameless structure. The values of a table then form a list of such composite structure values.
If multiple tables are defined with the absolute same structure, you should use the same refname. The refname can be created by using the prefix REF_ and name. The tabletype can have the values in, out or inout. Note: The class DataWizardForwardRequestListener can only have the value in.
Exceptions
<EXCEPTIONS> <EXCEPTION name="name" description="description"/></EXCEPTIONS>Field Definitions
<FIELD name="field_name" type="field_type" length="length" decimals="decimal_points" description="description_of_the_field"/>|
Field Type |
Meaning |
|
BCD |
Binary number format with decimal places, length and decimals are mandatory. |
|
BYTE |
Binary data (byte sequence), length is necessary. |
|
CHAR |
Character sequence with fixed length, length is necessary. |
|
DATE |
Date without time, format yyyyMMdd, length=8. |
|
FLOAT |
Floating point number, length and decimals are mandatory. |
|
INT |
4 byte integer. |
|
INT1 |
1 byte integer (careful). |
|
INT2 |
2 byte integer (careful). |
|
NUM |
Numeric value as character string, length is necessary. |
|
STRING |
Character string with variable length, not for STRUCTURE or TABLE. |
|
TIME |
Time without date, format HHmmss, length=6. |
For types where decimals has no meaning, the value is ignored. The types INT1 and INT2 should not be used because the JCo will report an incorrect length. Use NUM with length instead.
Structure Definitions
Structures in the import and export parameters are 'flat' structures, which means that a structure only contains fields, but no further structures.
<STRUCTURE name="STRUCT1" refname="REF_STRUCT1" description="description"> <!-- Field definitions --></STRUCTURE>Similar to the table definitions, multiple structures with absolutely the same structure should use the same refname.
Structure of the Example RFC MY_RFC
The example defines the function module MY_RFC that only expects one numerical value as import field NUMERIC_ID.
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE RFC PUBLIC"-//EBD Integration//DTD SAP RFC Configuration 1.0//EN""http://www.ebd-entwicklung.de/dtd/sap_rfc_configure_1_0.dtd"><RFC name="MY_RFC"> <INPUTPARAMS> <FIELD name="NUMERIC_ID" type="INT" length="4" decimals="0" description="Numeric ID"/> </INPUTPARAMS></RFC>Note about Data Types in STRUCTURE and TABLE
The term 'flat structure' refers to a composite data type composed of a sequence of simple fields. Each individual field must have a specific field length. The variable length type STRING is therefore not allowed for structures.
A TABLE parameter is actually a list of rows, with each row representing a flat structure. Therefore, the use of the type STRING is also inadmissible in the TABLE definition.
On the SAP side, we always recommend the use of repository types. The user has to ensure conformity on the Lobster side by using a suitable data type (preferably CHAR or NUM) with the length specified as defined in the SAP repository.
Example: If you use the repository type CHAR13 in SAP for an EAN, the field on the Lobster side has to be defined with the following attributes.
|
.... type=“CHAR“ length=“13“ .... |
Fields in STRUCTURE and TABLE definitions should have the same order as on the Lobster side.