All topics
1 / 60
EBSbeginner

Oracle EBS Architecture Overview

Understand the multi-tier architecture that underpins Oracle E-Business Suite R12

EBS is a Forms and PL/SQL application over a large relational schema, split across three tiers.

Think of EBS like a restaurant: the desktop tier is the dining room where customers place orders, the application tier is the kitchen staff and expediters coordinating the work, and the database tier is the pantry and recipe book that holds all the actual ingredients and instructions.

Key Concepts

1
    desktop tier     a browser: Forms, and OA Framework pages
    application tier Forms Server, HTTP Server, Concurrent Processing,
                     Admin Server
    database tier    the data, and thousands of PL/SQL packages
2
Why the split matters in practice. Each tier scales separately, and — more usefully — a problem belongs to exactly one of them.
3
    a slow concurrent program     -> application tier, concurrent manager
    a slow report query           -> database tier, SQL tuning
    a slow-loading form           -> application tier or the network
    a hung session                -> usually the database
4
Diagnosing an EBS issue starts by placing it on a tier, because the tools are different for each.
5
Most of the logic is in the database. EBS is not an application with a database behind it. The business rules are PL/SQL packages running inside Oracle, and the forms are largely a way to call them.
6
That is why so much EBS work is PL/SQL, and why performance problems so often end up as SQL tuning rather than middle-tier tuning.
7
The schema is organised by product family, with a schema per module:
8
    AP   payables          AR   receivables
    GL   general ledger    PO   purchasing
    INV  inventory         ONT  order management
9
An APPS schema holds synonyms to all of them, which is what application code connects as. That indirection is why nearly every EBS query works against APPS rather than the owning schema.
APPS
10
R12.2 and online patching. The significant architectural change was Edition-Based Redefinition, which lets a patch be applied to a second edition of the code while users continue on the first.
11
    run edition    what users are on now
    patch edition  where the patch is applied
    cutover        a short downtime to switch
12
Patching used to mean taking the system down for hours. Online patching reduces that to the cutover, at the cost of a considerably more complex patching process with its own file system and edition management.
13
What this means for customisations. Under EBR, custom code must be edition-aware, and the dual file system means changes have to be applied in the right place. A customisation that ignored this works until the next patch cycle and then disappears.
14
What the interviewer is probing.1. "Describe the EBS tiers." Probing: the foundation. Stalls: "Client and server." *Moves up:* desktop, application tier running forms, reports, concurrent managers and the web server, and the database tier holding schemas and the APPS schema.
15
2. "What is the APPS schema for?" Probing: the central concept. Stalls: "The data." *Moves up:* it owns no tables but holds synonyms and grants to every product schema, so code runs against one consistent namespace.
16
3. "What changed with R12 compared with 11i?" Probing: currency. Stalls: "The look." *Moves up:* the technology stack moved to Fusion Middleware, and functionally subledger accounting, multi-org access control and the ledger concept arrived.
17
4. "Where does the context file fit?" Probing: the operational detail. Stalls: "Nowhere." Moves up: it holds the environment configuration that AutoConfig applies, so manual edits to generated files are overwritten.
Use cases:architecturer12fundamentalsinfrastructure