Providing RFC (second option)
As an alternative to the method described in section Providing the RFC (first configuration option), there is a second configuration option for the Lobster RFC, where the interface definition in the XML file and the parameter "xmlFile" in the listener configuration are omitted. Instead, the parameter "copyFromPeer" is used.
<
Set
name
=
"copyFromPeer"
>true</
Set
>
This second configuration type can also be used for RFC calls with response. Use the following additional parameters . Note: If "useResponse=true", you also have to use "synchronCall=true", because otherwise the caller would not wait for the response .
<
Set
name
=
"useResponse"
>true</
Set
>
<
Set
name
=
"synchronCall"
>true</
Set
>
In this case (RFC sends back a response), the following parameter can be used to ensure that the TABLE parameters are deleted before the response is generated in the profile's Response. Otherwise, the table lines from the request would also be sent back in the response. This is usually not desired.
<
Set
name
=
"clearTablesForResponse"
>true</
Set
>
When the SapConnectionServices is started, the configuration of the interface for the relevant request listener/Lobster RFC is not read and loaded from an XML file, but from the repository of the SAP system. Therefore, there must be an active RFC in the SAP system with the same name as defined in parameter functionName. The interface of the Lobster RFC thus becomes the mirror image of the RFC of the same name in the SAP system. The RFC in the SAP system does not be fully need to be implemented. The interface is sufficient.
So this method allows to specify the interface from the SAP point of view and saves the effort of developing the interface XML file.
Limitation
This type of configuration necessarily requires a high availability of the SAP system. At the time of the start of the SapConnectionService, the SAP system must be accessible.
In addition, you need to follow the conceptual approach that first the interface is specified, then the implementation in both systems takes place and then the interface is not changed any more. Subsequent changes in the interface of the RFC within the SAP system require a manual adjustment of the profile that implements the "mirrored" Lobster RFC. Subsequent interface changes within the SAP system will therefore usually lead to errors.
Response to SAP System
It is also possible to send a response back to the SAP system.
To do this, the class PassBackDataResponse must be used in phase 6.
The response (built with target structure and Integration Unit) must have the following format. Note: See sections "Analyse file for structure" and "XMLNoTemplateUnit".
Example (only fields)
<
RFC
name
=
"Y_IMP_TEST01"
>
<
OUTPUTPARAMS
>
<
FIELD
name
=
"E_RELT"
>S</
FIELD
>
<
FIELD
name
=
"E_MSG"
>Success</
FIELD
>
</
OUTPUTPARAMS
>
</
RFC
>
Example (only tables)
<
RFC
name
=
"Y_IMP_TEST01"
>
<
TABLES
>
<
TABLE
name
=
"TABLENAME"
>
<
ROW
>
<
FIELD
name
=
"NAME1"
type
=
"CHAR"
length
=
"10"
>Hello</
FIELD
>
<
FIELD
name
=
"NAME2"
type
=
"CHAR"
length
=
"15"
>World</
FIELD
>
</
ROW
>
</
TABLE
>
<
TABLE
name
=
"TABLE2NAME"
>
<
ROW
>
<
FIELD
name
=
"NAME2"
type
=
"CHAR"
length
=
"20"
>Foo</
FIELD
>
</
ROW
>
</
TABLE
>
</
TABLES
>
</
RFC
>
Example (both)
<
RFC
name
=
"Y_IMP_TEST01"
>
<
OUTPUTPARAMS
>
<
FIELD
name
=
"E_RELT"
>S</
FIELD
>
<
FIELD
name
=
"E_MSG"
>Success</
FIELD
>
</
OUTPUTPARAMS
>
<
TABLES
>
<
TABLE
name
=
"TABLENAME"
>
<
ROW
>
<
FIELD
name
=
"NAME1"
type
=
"CHAR"
length
=
"10"
>Hello</
FIELD
>
<
FIELD
name
=
"NAME2"
type
=
"CHAR"
length
=
"15"
>World</
FIELD
>
</
ROW
>
</
TABLE
>
<
TABLE
name
=
"TABLE2NAME"
>
<
ROW
>
<
FIELD
name
=
"NAME2"
type
=
"CHAR"
length
=
"20"
>Foo</
FIELD
>
</
ROW
>
</
TABLE
>
</
TABLES
>
</
RFC
>