Brief History of OA Framework How did OA Framework Evolve Why did OA Framework Evolve Why is it still evolving Changes in Fusion ….and its future

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 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 A pl/sql procedure builds HTML tags, and the resultant HTML is shown on the browser

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.

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

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.

So, what was biggest issue with AK Developer? Customers would change the Meta Data, only to find their changes wiped off when Oracles 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

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. Brief History of Self Service in EBS, its evolution and reasons for direction 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

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

OA Framework – Current Version Advantages Completely integrated within jDeveloper for design and development purposes. MVC Industry Standard Architecture Highly extensible architecture

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 cant 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 WELCOME FUSION Where these limitations will be overcome