The sapnwrfc cookbook is a series of recipes showing the basic use cases and thus features of sapnwrfc.
These are generally of the form of a piece of code followed by an explanation.

The new SAP NW RFC SDK has two main advantages.
It contains inbuilt Unicode support,
so as soon as you need to work with wide characters,
then you must invoke

use utf8;

This will ensure that all expected strings passed in are utf8, which is the expected input format.

The second main advantage is that there is now support for nested/deep structures. this is where complex parameters or tables, can have variable length fields such as STRING/XSTRING, or contain nested complex types ie. other structures or tables.

Note that you only need to create one connection per system ($conn = SAPNW::Rfc->rfc_connect), which should be disconnected when no longer required ($conn->disconnect). Additionally, you only need to lookup the function definition once ($rd = $conn->function_lookup('NAME_OF_FUNCTION')) - this information is cached internally and is referred to repeatedly when creating each function call (must create a new function call per invocation $rc = $rd->create_function_call).

You can look at the test suites that come with the source code archive to see various examples of multiple connections, and RFC invocations ($rc->invoke).

And you can mix both of the above, to provide defaults from a file, and then override specific values.

YAML File Structure

The YAML file structure is a minimal keyword value arrangement, which can take any of the values allowed by the RFC library itself, but must be in lower case. For a full list of parameters, see the sapnwrfc.ini file found with SAP NW RFC SDK in the /demo directory.

When invoking an RFC, the parameter values are set or retrieved by name on the SAPNW::RFC::FunctionCall object. eg. RPY_PROGRAM_READ has an import parameter PROGRAM_NAME that is the name of the ABAP that you wish to retrieve the source code for. This is set like: $rc->PROGRAM_NAME("SAPLGRFC");

Table type parameters return an Array ref. Each row of the array contains a hash ref of the fields as key/value pairs.

Next step is to look at sending table entries as well. In just the same way that received table entries are array refs of hash references, so too are the out bound entries. Notice the table parameter OPTIONS below.

Changing parameters combine the characteristics of import and export parameters. You can set them before the call, and then retrieve a value from them afterwards. In the example below, COUNTER is set and then incremented within the RFC call.

Deep structures, and tables are any complex parameter that contains variable length field elements, such as strings/xstrings or contain nested structures within.

The guiding principal is that any structure field value of a simple ABAP type will be a Perl scalar value (int, float, string). Nested tables are array refs with rows containing hash refs of the field key/value pairs. Nested flat structure types are hash refs of field key/value pairs.

Unfortunately, there are no common RFC modules guaranteed to be in all SAP systems for me to be able to include a meaningful example here, other than STFC_DEEP_STRUCTURE and STFC_DEEP_TABLE, which contain the simplest example of structures that contain strings.

This is the basic formula for creating an RFC client connection, looking up a function definition, populating the parameters and executing the call. This example is the Perl equivalent to the standard rfcexec demo example that is supplied with the SAP NW RFCSDK written in C++.

RFC Server applications are where you can write a client program that any ABAP code running on the SAP R/3 server can call as a remote RFC.

This is a great mechanism for allowing SAP direct access to any Perl code of a 3rd party application.

The basic structure of an RFC server application is setting up the server connection, which registers the application in the SAP RFC gateway:

my $server = SAPNW::Rfc->rfc_register;

Don't forget that the connection parameters are different for server applications. The key ones are: tpname the DESTINATION name referred to in the ABAP application, gwhost - the RFC gateway host, gwserv - the service number on the gateway to connecto to (eg: 3301).

Construct the function definition that SAP can call. Give the RFC a name:

my $func = new SAPNW::RFC::FunctionDescriptor("RFC_REMOTE_PIPE");

Build the expected input/output parameters and add them to the function definition:

Set the callback function in Perl that will be executed. This receives one parameter - the SAPNW::RFC::FuncitonCall object, that contains the references to all the parameters that are passed in and must be passed back: