Providing the RFC (second configuration option)
As an alternative to the method described in section Providing the RFC, 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 Route. 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 in Lobster_data.
Limitation
This type of configuration necessarily requires a high availability of the SAP system. At the time of the start of Lobster_data and 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" RFC in Lobster_data. Subsequent interface changes within the SAP system will therefore usually lead to errors.