Rules & Static Data Framework

One central place for every constant and rule your SAP system relies on.

RSDF replaces the dozens of half-forgotten Z* customizing tables and hardcoded values scattered across your codebase with one organised, searchable, transportable home — changeable without a transport, traceable through every program that uses it.

Why we need it → How it works
Why we need it

Every project leaves behind a graveyard of tiny Z-tables.

In any long-running SAP project, every change request adds another little customizing object — a switch flag, a value list, a single constant — and most of them quietly turn into orphans no one remembers in six months.

  • Dozens of custom Z* / Y* tables get created as configuration for individual customer programs — each in its own DDIC namespace, each with its own SM30 view.
  • Most of them hold one or two rows. A whole transparent table for a single boolean flag or a tiny value list — overkill, but the pattern keeps repeating.
  • They get lost in the documentation. After a year, nobody can tell what Z_OLD_CONST_47 is for, who owns it, or whether it's still used.
  • Hardcoded constants live inside the source. Changing a single digit means a development ticket, a transport, and a release — for what is functionally just a configuration value.
  • No way to ask "where is this used?" A value lives in a Z-table, but the program that reads it is on the other side of the system — and finding callers means a manual code search every time.
The idea

Move every constant and rule into one framework.

RSDF is one configuration object that knows how to store anything you used to throw in a Z-table — single values, ranges, structures, long texts, decision lists — and gives every entry a clean three-part path: Area / ID / Parameter.

Every program in the system that needs the value goes through one tiny class — ZCL_RSDF_SELECT — and the framework answers with whatever shape the value has. Because every caller passes the path as a literal string, RSDF can scan the entire codebase and tell you, with one click, exactly where any parameter is used.

How it works

One unique path. Three simple parts.

Every value in RSDF lives at a coordinate of Area / ID / Parameter — a path you can read out loud, search the code for, and explain to a new joiner in thirty seconds.

1

Area

The SAP module or development area — CENT, GUARD, PCP2, SYSTEM, ZMYHUB. The bucket your parameter logically belongs to.

2

ID

The object, task, process, or change request inside that area — for example the program name, the class, the FM, or the CR number. Groups several related parameters together.

3

Parameter

The actual value, holding any of: a single value, a sel-options range, a flat structure, a long text, or a list — with optional criteria keys for multi-row lookups.

Why teams adopt it

Less clutter. Clearer code. Changeable on the fly.

One home, no more Z-graveyard

Stop creating a custom DDIC table for every two-row constant. Every value lives at Area / ID / Parameter — visible to everyone, instead of buried behind a transaction code only the original author remembered.

Built-in Where-Used List

Right-click any parameter and ask "where is this used?" — RSDF scans the entire codebase with a REGEX over the literal call pattern and lists every program touching it. No more grepping or guessing.

Five shapes, one API

Single value, sel-options range, flat structure, long text, drop-down list — pick the shape that fits the value. One class, one set of methods, one place to look.

Editable in any system

Maintain values directly in DEV, TST, or PRD — and only push to a transport when you want them to flow elsewhere. A "Put to Transport Request" button bundles all related customizing in one click.

Versioned with diff

Every save snapshots the parameter — pick any two versions side-by-side and the framework shows what changed, including structure changes. Audit-friendly out of the box.

Access sequence search

Need a value that depends on multiple keys? RSDF supports stepwise fallback — exact match first, then progressively wildcards the last key — like a condition technique, but for any constant.

Who it's for

Anyone who maintains constants in an SAP system.

Devs stop building one-off Z-tables. Functional consultants get a place they can change values themselves. Auditors get a clean version history. Everyone wins a little.

👩‍💻

Developers

One class call instead of a new DDIC table per CR. Where-used lookup built in.

🧰

Functional consultants

Maintain values without filing a development ticket — even change them in production when needed.

🏢

System architects

One framework, one transport pattern, one naming convention — across every team and every domain.

📝

Master data & config owners

Self-document parameters with multi-language descriptions and a clean change history.

🛡️

Auditors & compliance

Every change saved, every version diffable — answer "who changed it and when" in two clicks.

🧹

Cleanup teams

Retire the Z-table graveyard one parameter at a time. RSDF tells you what's still in use and what isn't.

Want to see it in action?

Five real situations — one for each parameter type RSDF can store. An activation flag, an IDoc range filter, a structured replication config, an internal-to-external mapping table, and a multi-language email template. Every example shows the parameter setup, the ABAP call, and the value RSDF hands back.

See the use cases →

Ready to retire the Z-table graveyard?

See how RSDF organises every constant your system relies on into one navigable tree — with versioning, multi-language docs, transport bundling, and a real Where-Used List baked in.

See real use cases →