Brief History of OA Framework How it Evolved Why it

Download Report

Transcript Brief History of OA Framework How it Evolved Why it

Brief History of OA Framework
….and its future
How did OA Framework Evolve
Why did OA Framework Evolve
Why is it still evolving
Changes in Fusion
http://oracle.anilpassi.com
Brief History of Self Service in EBS, its evolution and reasons for direction
PL/SQL Web Cartridge
PL/SQL stored procedures build HTML tags and returned the HTML document. A
package named htp can be used to generate HTML tags.
API's within pl/sql package htp/htf were provided. Some examples are
htp.htmlOpen, htp.htmlClose, htp.headOpen, htp.headClose, htp.bodyOpen,
htp.bodyClose, htp.comment, htp.base, htp.title, htp.script, htp.formOpen,
htp.formClose, htp.formCheckbox, htp.formText etc
A pl/sql procedure builds
HTML tags, and the resultant
HTML is shown on the
browser
Disadvantages
Both static/dynamic Content & validations were programmed within the PL/SQL.
Presentation and data were within the same layer [much like java servlets]
Even the simplest possible change required changes to PL/SQL Code
http://oracle.anilpassi.com
To overcome some of the limitations
imposed by PL/SQL Web Cartridges
• Oracle introduced a metadata concept in form of
AK Developer
• Item properties like required/prompt/LOV etc
became configurable
• This meta data was stored in tables. The names
of these tables begin with AK_%
• Reduced the programming effort when making
minor changes to the application behaviour.
http://oracle.anilpassi.com
Brief History of Self Service in EBS, its evolution and reasons for direction
AK Developer with PL/SQL and other technologies
 In AK Developer Regions and Region Items can be defined using Screens.
 Important tables in AK Developer are AK_REGIONS and AK_REGION_ITEMS.
 “AK Developer” separates Data Layer from Presentation Layer.
 Regions within the screen and their fields can be defined using AK Developer.
Examples of Customizations to AK Developer are
Changing the prompt of the field
Making a fields Mandatory
Hiding/Rendering fields
Horizontal/Vertical alignments
Enabling Descriptive Flexfields by rendering ATTRIBUTE columns
Attaching an LOV to a field.
Uncheck this field
to hide it from
screen
http://oracle.anilpassi.com
Brief History of Self Service in EBS, its evolution and reasons for direction
AK Developer with PL/SQL and other technologies
There were different subset of technologies that were used alongside “AK Developer”.
HRMS with PL/SQL Cartridges, but referenced AK Metadata
iProc with "XML Regions that were mapped to AK Regions"
iStore with JSP pages that internally used AK Regions as Metadata.
Disadvantages of using AK Developer
Any changes made to Region Item AK_REGION_ITEMS properties like “Prompt”
or “Required” or “Displayed” etc were lost during subsequent patches, as Oracle patches
would reload the AK Definitions with their changes. Hence implementers had to reapply
the AK developer changes after Oracle patching.
For shared regions, the changes done to Region/Region Items were globally reflected in
all the screens/responsibilities that reused those regions/region items.
http://oracle.anilpassi.com
So, what was biggest issue with AK
Developer?
• Customers would change the Meta Data, only to
find their changes wiped off when Oracle’s
patches re-issued new AK Definitions
• This limitation was overcome by adding few
more tables to the AK Application. These tables
would store customers changes
http://oracle.anilpassi.com
Brief History of Self Service in EBS, its evolution and reasons for direction
OA Framework + [AK Developer as Meta Data] + Personalizations in AK
A combination of OA Framework + AK Developer.
This solution was delivered by Oracle to overcome the disadvantages whereby patches
undid the AK Developer Changes.
In this case, personalizations are allowed and are stored in AK_CUSTOMIZATIONS,
AK_CUSTOM_REGIONS and AK_CUSTOM_REGION_ITEMS.
Hence changes done to Prompt, rendering etc property were retained during
patches/upgrades.
Still there were Limitations and Disadvantages
AK Developer is standalone and is not integrated with jDeveloper.
Hence part of the design/development happens in jDeveloper and the rest in AK
developer
AK is a proprietary technology
Very limited number of item styles were supported
http://oracle.anilpassi.com
OA Framework with MDS [Meta Data Service]
[CURRENT TECHNOLOGY]

Regions are created as XML but then loaded into Database into JDR% tables.

Oracle made a provision to migrate all the AK Definitions to Meta Data Service,
that holds the structural definition of OA Framework pages into database tables

The meta-data is defined as XML at design time, which is latter loaded into
JDR* tables in the database.

Automatic migration path provided by Oracle to migrate AK Regions into
JRAD/MDS

Modules that were migrated from AK to MDS, will have profile option “FND:
Migrated To JRAD” set to Y at Application Level
http://oracle.anilpassi.com
OA Framework – Current Version
Advantages

Completely integrated within jDeveloper for design and development
purposes.

MVC Industry Standard Architecture

Highly extensible architecture
http://oracle.anilpassi.com
OA Framework – Current Version
Disadvantages

Declarative design of screens. What you see is not what you get for layout

No drag and drop for designing layout of the Page.

No out of the box integration with Webservices, for example you can’t
simply drag the Webservice control onto the page.

MDS [Meta Data Service] is still proprietary.
Not fully based on Open Standards as yet

Lot of coding is required, for example in Controller class. Screen
navigation logic & integration is neither designed nor visible in Business
Flowchart style
http://oracle.anilpassi.com