Real situations

One use case for every type RSDF can store.

Five everyday SAP needs, each solved with a different RSDF parameter shape — single value, range, structure, table, and long text. Each one shows the parameter setup, the ABAP call the program makes, and the value the framework hands back.

1 Use case Variable

Pricing engine · class ZCL_PCP2_RETAIL_PRICE

"Switch on the optimised pricing path — without a transport."

The pricing team has rewritten the retail-price determination logic with a new SQL JOIN that runs three times faster than the old sequential reads. Both code paths still ship in the build — the optimised one is gated behind a single flag, so the team can flip it on per environment, watch the metrics, and roll back instantly if anything breaks.

The old way: hardcode lv_use_join = 'X'. in ABAP and request a transport every time you want to change it. Or build another tiny Z_PRICE_FLAG table that no one will remember in six months. With RSDF the flag becomes one parameter — flippable in ZRSDF in PRD, no transport required.

Area PCP2 — Price Card
Object / Task PERFORMANCE_CHANGE — Changes for Performance Improvement
Parameter DETERMINE_RETAIL_PRICE_JOIN_ON
Type Parameter (single value) · ref. SYST-FLAG · no criteria
DATA(lv_use_join) = zcl_rsdf_select=>get_value( iv_area = 'PCP2' iv_objid = 'PERFORMANCE_CHANGE' iv_parid = 'DETERMINE_RETAIL_PRICE_JOIN_ON' ). IF lv_use_join = 'X'. determine_retail_price_v2( ). " optimised JOIN path ELSE. determine_retail_price_v1( ). " legacy sequential reads ENDIF.
lv_use_join (CHAR1)
'X'    →  optimised path enabled in this environment
Area PCP2 ID PERFORMANCE_CHANGE Parameter DETERMINE_RETAIL_PRICE_JOIN_ON Type P · single value
Behind the scenes
  1. No criteria → exactly one row. Without a criteria structure, the parameter holds a single value. Calls always return the same answer for that environment.
  2. Per-system rollout. The same parameter exists in DEV / TST / PRD. Flip it on in DEV, observe, transport when ready — or change it directly in PRD via ZRSDF_EDIT, no transport needed.
  3. Default fallback. If the parameter is missing or unset, get_value returns blank, so the legacy code path is the safe default.
2 Use case Range

Outbound IDoc · function module Z_MYHUB_ARTICLE_OUT

"Only let beverages, food, household and health out through the partner IDoc."

MyHub pushes article master data to a downstream partner system via outbound IDoc. The partner only handles four article types (ZBEV, ZFOO, ZHHL, ZHEA) — wines, fresh, non-food private brand, and seasonal lines must be filtered out before send. The list of allowed types changes once or twice a year as the partner grows.

The old way: an IF mtart NOT IN ( 'ZBEV' OR 'ZFOO' …) chain in code, or another Z_ALLOWED_MTART table. With RSDF, the allowed list is one parameter of type Selection Options, holding a sel-options range with SIGN/OPTION/LOW/HIGH rows — readable directly into a standard ABAP RANGES table and used in an IN clause.

Area ZMYHUB — MyHub Communication Portal
Object / Task IDOC_ARTICLE_OUT — Outbound article IDoc
Parameter ALLOWED_MTART
Type Selection Options (Range) · ref. MARA-MTART · no criteria
DATA(lt_allowed) = zcl_rsdf_select=>get_range( iv_area = 'ZMYHUB' iv_objid = 'IDOC_ARTICLE_OUT' iv_parid = 'ALLOWED_MTART' ). IF ls_mara-mtart NOT IN lt_allowed. " article type is excluded — skip this IDoc RETURN. ENDIF.
lt_allowed (TT_RANGE_MTART)
SignOptionLowHigh
IEQZBEV
IEQZFOO
IEQZHHL
IEQZHEA
AreaZMYHUB IDIDOC_ARTICLE_OUT ParameterALLOWED_MTART TypeS · sel-options
Behind the scenes
  1. Multi-row range, single API call. Each line in the parameter becomes a row in the returned RANGES table — the maintenance UI even shows a Multiple Selection popup so functional users can add ranges, exclusions, and pattern matches naturally.
  2. Patterns and exclusions are free. Add a row with SIGN=I OPT=CP LOW=Z* to allow every Z-prefixed type, or SIGN=E OPT=EQ LOW=ZSEAS to exclude one specific type from a wider include — the same semantics as a standard ABAP RANGES table.
  3. Empty-on-error fallback. If the parameter is misconfigured and iv_raise_error is off, get_range returns "exclude all" so the IDoc stays safely empty rather than flooding the partner.
3 Use case Structure

Replication job · program ZSYS_REPL_TO_CMI

"All my replication thresholds in a single record — different per environment."

A nightly background job replicates master data to the central CMI system. It has four knobs: how many records to send per batch, how many retries to attempt on failure, the RFC timeout in seconds, and the email address to alert when a batch fails permanently. The right values for DEV (small batches, chatty logging, dev-team mailbox) are nothing like PRD (big batches, terse logging, on-call rotation).

The old way: four separate Z_* constants, or a Z-table with four columns. With RSDF, the four knobs sit in a single flat structure parameter — keyed by environment (SY-SYSID) — so one get_structure call returns the whole record at once.

Area SYSTEM — Global System Parameters
Object / Task RFC_SYSTEMS — RFC Systems
Parameter TO_CMI_SETTINGS
Type Structure · self-described data structure · criteria SYSID
Data structure fields MAX_BATCH_SIZE (INT4) · RETRY_COUNT (INT2) · TIMEOUT_SEC (INT4) · NOTIFY_ON_ERROR (CHAR60)
DATA(ls_cfg) = zcl_rsdf_select=>get_structure( iv_area = 'SYSTEM' iv_objid = 'RFC_SYSTEMS' iv_parid = 'TO_CMI_SETTINGS' is_cri_data = VALUE #( sysid = sy-sysid ) ). replicate_master_data( iv_batch = ls_cfg-max_batch_size iv_retries = ls_cfg-retry_count iv_timeout = ls_cfg-timeout_sec iv_notify = ls_cfg-notify_on_error ).
ls_cfg (ZS_TO_CMI_SETTINGS) — for SY-SYSID = 'PRD'
FieldValue
MAX_BATCH_SIZE10000
RETRY_COUNT5
TIMEOUT_SEC120
NOTIFY_ON_ERRORoncall-myhub@example.com
AreaSYSTEM IDRFC_SYSTEMS ParameterTO_CMI_SETTINGS TypeU · structure
Behind the scenes
  1. Self-described data structure. No DDIC reference is needed — the data structure is defined inside RSDF (Field Name + Reference table + Ref. field per row), generated on the fly, and round-tripped to the caller as a fully typed structure.
  2. Criteria does the routing. Each environment (DEV, TST, PRD) is a separate row keyed by SYSID. The same call from different systems returns different settings.
  3. Functional changes only. Doubling the batch size or pointing the alert email to a new mailing list is a field edit in ZRSDF. No build, no test cycle, no developer needed.
4 Use case Table

Outbound IDoc mapper · class ZCL_MYHUB_DOCTYPE_MAPPER

"Translate our internal codes to whatever the partner expects."

MyHub speaks ZSO1, ZSO2, ZRTN internally — sales orders, returns, free-of-charge orders. The downstream partner expects ORD1000, ORD2000, RET3000. Every outbound document needs the internal code translated to the partner code, with the mapping changeable by functional consultants when the partner contract evolves.

The old way: yet another Z_DOCTYPE_MAP Z-table that "lives somewhere" and "is owned by someone, probably". With RSDF, the mapping is one parameter with criteria (INTERNAL_DOCTYPE as the key) and a value structure holding the partner code plus optional validity dates — readable in one get_table call, or one row at a time via get_structure with criteria.

Area ZMYHUB — MyHub Communication Portal
Object / Task IDOC_OUTBOUND — Outbound IDoc Processing
Parameter DOCTYPE_MAPPING
Type Structure · criteria INTERNAL_DOCTYPE · multi-row
Data structure fields EXTERNAL_DOCTYPE (CHAR10) · VALID_FROM (DATS) · VALID_TO (DATS)
" full table — useful for warm caches or admin overviews DATA(lt_map) = zcl_rsdf_select=>get_table( iv_area = 'ZMYHUB' iv_objid = 'IDOC_OUTBOUND' iv_parid = 'DOCTYPE_MAPPING' ). " or one row at a time, by key DATA(ls_row) = zcl_rsdf_select=>get_structure( iv_area = 'ZMYHUB' iv_objid = 'IDOC_OUTBOUND' iv_parid = 'DOCTYPE_MAPPING' is_cri_data = VALUE #( internal_doctype = iv_doctype ) ).
lt_map (TT_DOCTYPE_MAPPING)
Internal (Key)ExternalValid FromValid To
ZSO1ORD10002025-01-019999-12-31
ZSO2ORD20002025-01-019999-12-31
ZRTNRET30002025-01-019999-12-31
ZSO3ORD30002026-04-019999-12-31
AreaZMYHUB IDIDOC_OUTBOUND ParameterDOCTYPE_MAPPING TypeU · multi-row
Behind the scenes
  1. Criteria turns one parameter into many rows. In RSDF, "table" isn't a separate type — it's a structure parameter with a criteria field. Each row in the Data ALV pairs criteria-key values with the value structure next to them.
  2. Two ways to read. Use get_table to load every row (good for caching all mappings in memory for a batch run), or get_structure with a VALUE #( internal_doctype = … ) key to fetch exactly one row.
  3. New mapping, no transport. The day the partner adds ZSO3 → ORD3000, a functional consultant adds the row in PRD via ZRSDF_EDIT. The next outbound IDoc picks it up on the next run.
5 Use case Long Text

Notification framework · class ZCL_MYHUB_NOTIFY

"One welcome email, four languages, zero re-deploys."

When MyHub onboards a new business partner, an automated welcome email goes out — and it has to land in the partner's preferred language. The wording is approved by Marketing and changes a few times a year (legal disclaimers, support phone numbers, a new on-boarding URL). The placeholders — partner name, account number, logon URL — are filled in by ABAP at send time.

The old way: hardcoded strings buried in a class, or a Z-table with a CLOB column nobody dared to touch. With RSDF, the template is a Long Text parameter with criteria LANGU — one row per language, fully editable in ZRSDF with the long-text editor, multi-language descriptions baked in.

Area ZMYHUB — MyHub Communication Portal
Object / Task NOTIFICATIONS — Outbound notifications
Parameter NEW_BP_WELCOME_MAIL
Type Long Text (CHAR10000) · criteria LANGU · ref. T002-SPRAS
DATA(lv_body) = zcl_rsdf_select=>get_value( iv_area = 'ZMYHUB' iv_objid = 'NOTIFICATIONS' iv_parid = 'NEW_BP_WELCOME_MAIL' is_cri_data = VALUE #( langu = ls_bp-spras ) ). REPLACE ALL OCCURRENCES OF '&BP_NAME&' IN lv_body WITH ls_bp-name1. REPLACE ALL OCCURRENCES OF '&BP_NUMBER&' IN lv_body WITH ls_bp-partner. REPLACE ALL OCCURRENCES OF '&LOGON_URL&' IN lv_body WITH lv_url. cl_bcs=>create_persistent( )->set_body( lv_body )->send( ).
lv_body (CHAR10000) — for ls_bp-spras = 'D' (German)
Sehr geehrte Damen und Herren von &BP_NAME&,

herzlich willkommen als neuer Geschäftspartner mit der Nummer
&BP_NUMBER& in unserem Lieferantenportal.

Bitte melden Sie sich unter &LOGON_URL& an, um Ihre
Stammdaten zu vervollständigen. Bei Fragen wenden Sie sich
bitte an support@example.com.

Mit freundlichen Grüßen
Ihr Demo-Team
AreaZMYHUB IDNOTIFICATIONS ParameterNEW_BP_WELCOME_MAIL TypeL · long text
Behind the scenes
  1. One parameter, one row per language. The criteria field LANGU references T002-SPRAS, so the maintenance UI offers a proper language F4. EN, DE, FR, IT each get their own long-text entry.
  2. Long-text editor built-in. Click the value in the Data ALV and a full-screen editor opens — paragraphs, line breaks, special characters all preserved (CHAR10000 per entry).
  3. Placeholders are intentional. RSDF stores the text as-is — the calling program owns substitution. This keeps the framework dumb and the language-specific template free to use whatever placeholder convention the program likes.

Five shapes. One central place.

Every example above used the same path syntax, the same ZCL_RSDF_SELECT class, the same maintenance UI, and the same Where-Used List. The only thing that changed was the shape of the value — and RSDF handles all five out of the box.

Back to overview