SAP RFC

• How it works
• Prerequisites
• Component fields
• Input payload
• Output
• Examples
• Commit and transactions
• Automatic parsing (autoParse)
• Extended records (USE_ET_DATA_4_RETURN)
• Error handling
• Observability in the Trace

The SAP RFC connector lets you invoke RFCs (Remote Function Calls) and BAPIs (Business APIs) of an SAP system directly from an integration flow, using JSON for both input and output.

It abstracts the complexity of the SAP binary protocol (handled by the JCo libraries): you describe the call as JSON, and the connector takes care of the connection, type conversion, and transaction handling. The connector replaces the legacy implementation available in Canvas mode.

IMPORTANT

The SAP RFC connector is controlled by a feature flag. To enable it for your tenant, contact Sensedia support.

How it works

The connector connects to SAP using the connection pool of an SAP RFC data source, executes the RFC or BAPI you specify (for example, RFC_READ_TABLE or BAPI_USER_GET_DETAIL), and automatically converts the result to structured JSON.

Prerequisites

• An SAP RFC data source configured for the target environment.
• The JCo driver files uploaded for your tenant (see the data source prerequisites).

IMPORTANT

The connector accepts only data sources of type SAP RFC. Pointing it to a JDBC data source results in a validation error.

Component fields

In the Source Code (YAML) view, the component uses the URI scheme saprfc:label with the dataSource, functionName, commit, and autoParse parameters:

Input payload

The payload is a JSON object made up of the standard SAP parameter blocks. Include only the blocks the function requires:

• importing: input parameters sent to the function.
• changing: parameters the function may modify (returned with any values changed by SAP).
• tables: table structures (arrays) sent to or read by the function.

Each field inside these blocks must use the exact technical name expected by the SAP function (case-sensitive).

NOTE

You can override the payload at runtime by setting the SensediaSapRfcPayload header in a previous step (for example, with a setHeader). When this header is present, it takes precedence over the step's Payload field — useful for building the payload dynamically.

Output

The response is always a structured JSON object:

• metadata.status: SUCCESS when there are no business errors; ERROR when there are type E messages in the SAP RETURN table.
• metadata.errors: list of error messages returned by SAP.
• exporting: the function's output parameters.
• changing: input parameters returned with any changes.
• tables: the function's output tables.

When a function returns no data (for example, a query with no results), the call still succeeds: metadata.status is SUCCESS and the corresponding table is an empty array ([]).

Examples

The examples below use standard SAP test functions and were validated against an SAP system.

Connection test (STFC_CONNECTION)

Function Name: STFC_CONNECTION

The response echoes the text in exporting.ECHOTEXT and returns server data in exporting.RESPTEXT.

Reading a table (RFC_READ_TABLE)

Function Name: RFC_READ_TABLE

• QUERY_TABLE: the SAP table to read.
• DELIMITER: the character used to separate the columns in each returned row.
• ROWCOUNT: maximum number of rows to return.
• FIELDS: the columns to read.

The response returns the field metadata (LENGTH, OFFSET, TYPE) in tables.FIELDS and the rows in tables.DATA, where each WA field holds the row content delimited by DELIMITER. To receive the output already structured into named fields, use automatic parsing (autoParse).

NOTE

By default, each row of the DATA table is limited to 512 characters. For records longer than that, see Extended records (USE_ET_DATA_4_RETURN).

Filtering rows (OPTIONS)

To filter the rows read from a table, add the OPTIONS table with a TEXT clause:

Listing users (BAPI_USER_GETLIST)

Function Name: BAPI_USER_GETLIST

Returns the matching users in tables.USERLIST and the total in exporting.ROWS.

User detail (BAPI_USER_GET_DETAIL)

Function Name: BAPI_USER_GET_DETAIL

Returns nested structures (such as ADDRESS and LOGONDATA) in exporting.

Commit and transactions

When Commit is enabled (commit=true), after the main function runs successfully the connector automatically executes BAPI_TRANSACTION_COMMIT in the same session, persisting the changes.

• Use commit=true for functions that write to SAP (e.g., a BAPI that updates a record).
• Use commit=false for read-only functions (e.g., RFC_READ_TABLE).

WARNING

With commit enabled, if a failure occurs after the main call but before the commit, the component ensures that no changes are persisted in SAP.

NOTE

Running a commit on a read-only function does not change the returned data. There is no automatic rollback; transactional behavior depends on the SAP function being called.

Automatic parsing (autoParse)

The autoParse parameter makes it easier to consume RFC_READ_TABLE responses. Without it, SAP returns the table records in the WA field in fixed-width positional format — requiring you to manually interpret the offsets and lengths of each column.

With autoParse=true, the connector uses the metadata in tables.FIELDS to automatically slice the WA field and produce JSON objects with named, typed fields.

NOTE

autoParse is applied only when the executed RFC is RFC_READ_TABLE and the response contains the FIELDS and DATA tables. For other RFCs, the response remains in the default format.

Before and after autoParse

Without autoParse, each record looks like this:

With autoParse=true, the output is:

The FIELDS table is removed from the response after parsing.

Type conversions

NOTE

Fields of type N (textual numeric) are kept as strings to preserve leading zeros in identifiers such as customer, material, and document codes in SAP.

YAML configuration

Extended records (USE_ET_DATA_4_RETURN)

SAP tables have a 512-character limit per row in the DATA field. For wider records, SAP provides the extended ET_DATA table. To use it, include the USE_ET_DATA_4_RETURN parameter with the value "X" in the input payload, and also set the DELIMITER:

IMPORTANT

For ET_DATA parsing to work, you must enable autoParse=true in the step and set DELIMITER in the payload. Without the delimiter, the ET_DATA content is not transformed and the response remains in raw format.

In ET_DATA mode, the connector uses the DELIMITER to separate the fields of each row instead of positional offsets. Type conversions follow the same rules as the standard autoParse. The final output assembles the objects in exporting.ET_DATA with named fields.

The ET_DATA flow is activated only when all of the following conditions are true:

• autoParse=true in the step;
• the executed RFC is RFC_READ_TABLE;
• importing.USE_ET_DATA_4_RETURN = "X" in the payload;
• importing.DELIMITER set in the payload;
• the SAP response contains exporting.ET_DATA and tables.FIELDS.

Error handling

SAP returns errors in the RETURN table, classified by type:

• Type E (Error) — a business error (e.g., a nonexistent table or invalid data). The flow continues, metadata.status becomes ERROR, and the message is added to metadata.errors.
• Type A (Abort) — a critical error. The connector raises an exception and interrupts the flow.

Observability in the Trace

When a flow with the SAP RFC connector runs, the following tags are automatically added to the execution span in Sensedia Analytics:

Use these tags to filter executions in the Trace Detail and diagnose connectivity or performance issues in high-volume environments.