OBIEEintermediate
Session & Repository Variables
Distinguish repository (static) variables from session (dynamic/system/non-system) variables and how each is used in security, personalization, and dynamic filtering.
Variables are the mechanism that lets a single RPD and a single set of dashboards behave differently per user, per session, or per scheduled refresh — without duplicating content. Interviews probe this because misusing variable scope is a very common real-world bug source.
A repository variable is like the date printed on today's newspaper — same for every reader. A session variable is like the name printed on your hotel room key card — unique to you, generated the moment you check in.
Key Concepts
1
Repository variables are static or periodically-refreshed values stored in the RPD itself, evaluated once and shared across all users — think of a "current fiscal year" variable refreshed nightly by a scheduled initialization block, used consistently across every report that needs "this year" logic without hardcoding a value that would need RPD redeployment every year.
Repository variables
2
Session variables come in two flavors: system session variables (reserved names like USER, LOGLEVEL, DISABLE_CACHE_HIT, ROLES that the BI Server itself populates or expects) and non-system (dynamic) session variables, which are custom variables initialized per user login via an initialization block that runs a SQL query against a security or profile table, substituting :USER for the logged-in user's ID. These are the backbone of row-level security (VALUEOF(NQ_SESSION."REGION") in a data filter) and personalization (default prompt values, greeting messages).
Session variablessystem session variablesnon-system (dynamic) session variablesinitialization blockUSER
3
A key operational detail interviewers probe: initialization blocks have execution precedence and can depend on each other (e.g., a ROLES block might need to run before a region-lookup block that filters by role). Poorly ordered or overly expensive init blocks (running a slow query on every single login) are a classic cause of slow login times — a real production pain point worth mentioning.
execution precedenceROLES