All topics
28 / 60
Fusionadvanced

Application Composer and Sandboxes

Explain Fusion's declarative extensibility model built on Application Composer and Sandbox-based change isolation

Application Composer extends Fusion's data model and logic through a browser, without code. Sandboxes are what make that safe to do.

Sandboxes are like a document's 'suggested edits' mode combined with a separate draft copy: multiple editors (developers) can work on their own draft version in isolation, and only when an edit is accepted (published) does it become part of the master document everyone sees.

Key Concepts

1
What Application Composer adds.
    custom fields      on delivered objects
    custom objects     entirely new ones, with their own pages
    validation rules   Groovy expressions on save
    triggers           logic on create, update or delete
    object workflows   send an email, update a field, when a
                       condition is met
2
It covers what EBS split across flexfields, personalization and custom PL/SQL, in one tool.
3
A sandbox isolates the work.
    create a sandbox
        |  make changes -- only visible inside it
        |  test them, as a user, in the same environment
        v
    publish  -> everyone sees them
    or discard -> nothing happened
4
Other users continue on the unmodified application the whole time. That is what EBS could not do: a Forms personalization was live the moment it was saved, so testing needed a separate instance.
5
Publishing is close to one-way, and this is the part interviewers ask about.
6
There is no rollback. Once published, the change is in the environment, and undoing it means making further changes to reverse it.
7
Some changes cannot be reversed at all — a custom object with data in it, a field other configuration now depends on. So the lifecycle discipline matters:
8
  1. Create the sandbox
  2. Make and test the changes inside it
  3. Publish to a **test pod** first
  4. Only then publish in production
9
Several sandboxes at once need care. Two sandboxes changing the same object conflict, and the second to publish may fail or overwrite. Publishing frequently and keeping sandboxes short-lived avoids most of it — the same argument as short-lived branches.
10
What it does not do. Application Composer works on objects Oracle has made extensible, which is not all of them. A requirement outside that set is not a matter of finding the right screen; it needs a different approach, often an integration rather than an extension.
11
That constraint is deliberate. Everything built this way is metadata Oracle can carry through a quarterly update, which is the whole reason the tool exists in this form.
12
What the interviewer is probing.1. "What is a sandbox for?" Probing: the purpose. Stalls: "Testing." Moves up: isolating configuration changes until they are published, so an in-progress change does not affect live users.
13
2. "What can Application Composer change?" Probing: the scope. Stalls: "Anything." *Moves up:* custom fields, objects, relationships, groovy logic and layouts — but only in the applications that support it, mainly CX and some ERP areas.
14
3. "What is the risk with groovy scripts?" Probing: the engineering angle. Stalls: "None." Moves up: they run per record and can be slow, there is limited debugging, and they are not version-controlled like real source.
15
4. "What is the discipline around sandboxes?" Probing: the operational point. Stalls: "None." Moves up: short-lived and few — long-running overlapping sandboxes conflict and become very hard to merge.
Use cases:application-composersandboxgroovyfusion-extensibility