All topics
8 / 60
EBSintermediate

Application Object Library (AOL) and FND Tables

Understand the foundational metadata layer (AOL/FND) that powers menus, responsibilities, and security in EBS

AOL, whose tables are prefixed FND, is the layer underneath every EBS module. Users, responsibilities, menus, concurrent programs, flexfields, profile options and messages all live here.

AOL/FND is like the building management system of an office tower — it defines who has a badge (FND_USER), which floors and rooms that badge opens (responsibilities/menus), and keeps a common directory and notice board (message dictionary) that every tenant company (module) in the building uses.

Key Concepts

1
The tables to know.
    FND_USER                 application users
    FND_RESPONSIBILITY       responsibilities
    FND_MENUS / _ENTRIES     menu structure
    FND_FORM_FUNCTIONS       registered forms and functions
    FND_CONCURRENT_PROGRAMS  batch program definitions
    FND_REQUEST_GROUPS       which programs a responsibility may run
    FND_PROFILE_OPTION_VALUES
2
A responsibility is the access boundary, and it ties three things together:
3
    menu           which screens and functions
    request group  which concurrent programs
    data group     which schema to connect to
4
A user is granted responsibilities, and everything they can reach follows from that.
5
Which gives you the standard trace: "why can this user not see that screen?"
    user -> responsibility -> menu -> submenu -> function
6
Walk it in order. The break is usually a function excluded at the responsibility level — an exclusion rule that removes a function from an otherwise complete menu, which is invisible unless you look for it.
7
For a concurrent program the equivalent trace is user -> responsibility -> request group -> program.
8
The services AOL provides to custom code.
    FND_GLOBAL      session context: USER_ID, RESP_ID, ORG_ID
    FND_PROFILE     read a profile option with hierarchy resolution
    FND_FILE        write to the concurrent request log or output
    FND_MESSAGE     translatable messages from the Message Dictionary
9
    FND_FILE.PUT_LINE(FND_FILE.LOG, 'Processed ' || v_count || ' rows');
10
FND_FILE is how a concurrent program produces a log at all. DBMS_OUTPUT goes nowhere in that context, which is a common first mistake.
FND_FILEDBMS_OUTPUT
11
FND_GLOBAL is what makes auditing work. Every EBS table carries CREATED_BY and LAST_UPDATED_BY, and custom code is expected to populate them:
FND_GLOBALCREATED_BYLAST_UPDATED_BY
12
    :new.last_updated_by := FND_GLOBAL.USER_ID;
13
Code that hardcodes a user id, or leaves these null, breaks the audit trail that the rest of the application maintains.
14
The Message Dictionary holds messages in FND_NEW_MESSAGES rather than in code, so they can be translated and changed without a recompile. Custom code that hardcodes English error text is the thing this exists to avoid.
FND_NEW_MESSAGES
15
What the interviewer is probing.1. "What does AOL provide?" Probing: the purpose. Stalls: "Tables." Moves up: the shared framework — users, responsibilities, menus, concurrent processing, profiles, flexfields and lookups — that every module uses.
16
2. "Name the tables you would query for a user's access." Probing: hands-on knowledge. Stalls: "The user table." Moves up: FND_USER, FND_USER_RESP_GROUPS, FND_RESPONSIBILITY_TL and the menu and function tables beneath them.
17
3. "What are the WHO columns?" Probing: the standard. Stalls: "Audit fields." Moves up: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE and LAST_UPDATE_LOGIN — custom tables are expected to carry them too.
18
4. "Where do you find concurrent request history?" Probing: the practical skill. Stalls: "The screen." Moves up: FND_CONCURRENT_REQUESTS joined to FND_CONCURRENT_PROGRAMS_TL, which is how you analyse runtimes across weeks.
Use cases:aolfndsecurityresponsibilitiesfoundation