Custom RFCs

This page provides guidelines and examples for creating custom RFC-enabled function modules for specific business requirements in SAP systems.

What are Custom RFCs?

Custom RFCs are function modules created by organizations to:

  • Implement business-specific functionality not covered by standard SAP RFCs
  • Provide simplified interfaces to complex SAP processes
  • Enable integration between SAP and non-SAP systems
  • Expose custom business logic for remote access

Custom RFCs typically:

  • Start with 'Z' or 'Y' prefix (following SAP naming conventions)
  • Are organized into custom function groups
  • Have the "Remote-Enabled Module" attribute set

Creating Custom RFCs

Prerequisites

Before creating a custom RFC, ensure you have:

  • Appropriate development authorizations
  • A clear understanding of the business requirements
  • Knowledge of ABAP programming and RFC concepts
  • Access to a development system

Development Process

  1. Design the Interface:

    • Define the purpose and functionality of the RFC
    • Identify the required parameters (import, export, changing, tables)
    • Define appropriate exceptions for error handling

  2. Create the Function Module:

    • Use Transaction SE37 to create a new function module
    • Set the "Remote-Enabled Module" attribute
    • Define the parameters and exceptions
    • Implement the function module logic
    • Add comprehensive documentation

  3. Test the Function Module:

    • Use the test function in SE37 to verify functionality
    • Test with various input parameters and scenarios
    • Verify error handling and exception behavior

  4. Transport to Production:

    • Include the function module in a transport request
    • Follow your organization's change management process
    • Test in quality assurance before production deployment

RFC-Enabling a Function Module

To make a function module callable via RFC:

  1. In SE37, select the function module
  2. Click on "Attributes"
  3. Check the "Remote-Enabled Module" checkbox
  4. Save the changes

Best Practices for Custom RFCs

Naming Conventions

  • Use a consistent naming pattern for custom RFCs
  • Start with 'Z' or 'Y' prefix (SAP naming convention for custom objects)
  • Include a meaningful description of the functionality
  • Example: Z_CUSTOMER_GET_EXTENDED_DATA

Interface Design

  • Keep the interface simple and focused on a specific task
  • Use clear, descriptive parameter names
  • Group related parameters logically
  • Provide default values where appropriate
  • Define meaningful exceptions for error handling

Parameter Types

Choose the appropriate parameter type based on the data flow:

  • Import Parameters: Input values passed to the function module
  • Export Parameters: Output values returned by the function module
  • Changing Parameters: Values that are both input and output
  • Tables Parameters: Internal tables passed to and from the function module

Error Handling

  • Define specific exceptions for different error scenarios
  • Include a RETURN parameter for detailed error information
  • Follow the standard SAP error structure (TYPE, ID, NUMBER, MESSAGE)
  • Log errors appropriately for troubleshooting

Security Considerations

  • Implement proper authorization checks
  • Validate input parameters to prevent injection attacks
  • Avoid exposing sensitive data unnecessarily
  • Consider using RFC destination trusted systems where appropriate

Performance Optimization

  • Minimize data transfer by selecting only necessary fields
  • Use appropriate database access techniques
  • Consider the impact of large data volumes
  • Implement pagination for large result sets

Documentation

  • Document the purpose and functionality of the RFC
  • Describe parameters and exceptions clearly
  • Include examples of how to call the RFC
  • Document any dependencies or prerequisites
  • Keep documentation up-to-date when changes are made

Example Custom RFC Implementation

Z_CUSTOMER_GET_EXTENDED_DATA

This example RFC retrieves extended customer data including sales history and credit information.

Interface Definition

FUNCTION Z_CUSTOMER_GET_EXTENDED_DATA.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IV_CUSTOMER_ID) TYPE  KNA1-KUNNR
*"     VALUE(IV_INCLUDE_SALES_HISTORY) TYPE  CHAR1 DEFAULT 'X'
*"     VALUE(IV_INCLUDE_CREDIT_INFO) TYPE  CHAR1 DEFAULT 'X'
*"     VALUE(IV_DATE_FROM) TYPE  DATUM OPTIONAL
*"     VALUE(IV_DATE_TO) TYPE  DATUM OPTIONAL
*"  EXPORTING
*"     VALUE(ES_CUSTOMER_MASTER) TYPE  TY_CUSTOMER_MASTER
*"     VALUE(ES_CREDIT_DATA) TYPE  TY_CREDIT_DATA
*"  TABLES
*"      ET_SALES_HISTORY STRUCTURE  TY_SALES_HISTORY OPTIONAL
*"      ET_RETURN STRUCTURE  BAPIRET2
*"  EXCEPTIONS
*"      CUSTOMER_NOT_FOUND
*"      INVALID_DATE_RANGE
*"      SYSTEM_ERROR
*"----------------------------------------------------------------------

Implementation Outline

FUNCTION Z_CUSTOMER_GET_EXTENDED_DATA.
  " Local variables
  DATA: lv_error TYPE char1.

  " Initialize return table
  CLEAR ET_RETURN.

  " Validate input parameters
  IF IV_CUSTOMER_ID IS INITIAL.
    lv_error = 'X'.
    APPEND VALUE #( TYPE = 'E'
                   ID = 'Z_CUSTOMER'
                   NUMBER = '001'
                   MESSAGE = 'Customer ID is required' ) TO ET_RETURN.
  ENDIF.

  " Validate date range if provided
  IF NOT IV_DATE_FROM IS INITIAL AND NOT IV_DATE_TO IS INITIAL.
    IF IV_DATE_FROM > IV_DATE_TO.
      lv_error = 'X'.
      APPEND VALUE #( TYPE = 'E'
                     ID = 'Z_CUSTOMER'
                     NUMBER = '002'
                     MESSAGE = 'Invalid date range' ) TO ET_RETURN.
      RAISE INVALID_DATE_RANGE.
    ENDIF.
  ENDIF.

  " Exit if validation errors
  IF lv_error = 'X'.
    RETURN.
  ENDIF.

  " Get customer master data
  SELECT SINGLE * FROM KNA1 INTO CORRESPONDING FIELDS OF ES_CUSTOMER_MASTER
    WHERE KUNNR = IV_CUSTOMER_ID.
  
  IF SY-SUBRC <> 0.
    APPEND VALUE #( TYPE = 'E'
                   ID = 'Z_CUSTOMER'
                   NUMBER = '003'
                   MESSAGE = 'Customer not found' ) TO ET_RETURN.
    RAISE CUSTOMER_NOT_FOUND.
    RETURN.
  ENDIF.

  " Get additional customer data from other tables
  " ...

  " Get credit information if requested
  IF IV_INCLUDE_CREDIT_INFO = 'X'.
    " Retrieve credit data
    " ...
  ENDIF.

  " Get sales history if requested
  IF IV_INCLUDE_SALES_HISTORY = 'X'.
    " Define date range
    DATA: lv_date_from TYPE datum,
          lv_date_to   TYPE datum.
          
    lv_date_to = COND #( WHEN IV_DATE_TO IS INITIAL THEN SY-DATUM
                         ELSE IV_DATE_TO ).
                         
    lv_date_from = COND #( WHEN IV_DATE_FROM IS INITIAL THEN
                           lv_date_to - 365 ELSE IV_DATE_FROM ).
    
    " Retrieve sales history
    " ...
  ENDIF.

  " Add success message
  APPEND VALUE #( TYPE = 'S'
                 ID = 'Z_CUSTOMER'
                 NUMBER = '000'
                 MESSAGE = 'Customer data retrieved successfully' ) TO ET_RETURN.
                 
ENDFUNCTION.

Testing Custom RFCs

Internal Testing

  1. Use Transaction SE37 to test the function module:

    • Enter test values for import parameters
    • Execute the function module
    • Verify the results in export parameters and tables

  2. Create a test program to call the function module:

    REPORT Z_TEST_CUSTOMER_RFC.

DATA: lt_return TYPE TABLE OF bapiret2.

CALL FUNCTION 'Z_CUSTOMER_GET_EXTENDED_DATA'
  EXPORTING
    iv_customer_id           = '1000000'
    iv_include_sales_history = 'X'
    iv_include_credit_info   = 'X'
  TABLES
    et_return                = lt_return
  EXCEPTIONS
    CUSTOMER_NOT_FOUND       = 1
    INVALID_DATE_RANGE       = 2
    SYSTEM_ERROR             = 3
    OTHERS                   = 4.

IF sy-subrc <> 0.
  WRITE: / 'Error:', sy-subrc.
ELSE
  LOOP AT lt_return INTO DATA(ls_return).
    WRITE: / ls_return-type, ls_return-message.
  ENDLOOP.
ENDIF.

External Testing

  1. Configure an RFC destination in Transaction SM59
  2. Use Transaction STRUST to manage certificates if using secure connections
  3. Test the RFC connection using Transaction SM59's test function
  4. Create a test program in the calling system to test the RFC

Troubleshooting Custom RFCs

Common Issues

  • Authorization Errors: Verify that the RFC user has the necessary authorizations
  • Connection Issues: Check RFC destination configuration in SM59
  • Data Format Problems: Ensure data types match between systems
  • Performance Issues: Monitor execution time and optimize as needed

Monitoring Tools

  • Transaction SM58: Monitor asynchronous RFC calls
  • Transaction STAD: Runtime analysis
  • Transaction ST22: ABAP dump analysis
  • Transaction SLG1: Application log

Versioning and Maintenance

  • Document changes to custom RFCs
  • Consider backward compatibility when modifying interfaces
  • Use version numbers in documentation
  • Create wrapper functions for major interface changes
  • Test thoroughly after modifications
Edit this page
Last Updated::
Contributors: Taylor Brazelton