Skip Headers
Oracle® Application Express Application Migration Guide
Release 3.2

Part Number E12509-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Overview of the Migration Process

Whether converting from Oracle Forms or migrating from Microsoft Access, Oracle Application Express Application Migration is an effective tool to start your conversion project. This section outlines the tool's capabilities and provides important information that should be reviewed before starting a conversion project.

This section contains the following topics:

Why Migrate to Oracle Application Express?

Oracle Forms modernization projects are often undertaken to convert legacy applications to the latest Oracle Database version and enable developers to satisfy user demands for greater user interactivity and Web 2.0 capabilities.

Microsoft Access presents organizations with a myriad of manageability issues. Often simple applications grow in size and complexity and become mission critical. These same applications are often scattered throughout the network making maintenance, backups, security, and access increasingly costly and inconsistent. One key reason for migrating from Microsoft Access to an Oracle database is to consolidate the data and build common applications based on a single data source.

Migrating to Oracle Application Express provides a robust, scalable, secure application development tool that takes full advantage of the Oracle database. Oracle Application Express requires only a Web browser and no client software for development, deployment, or runtime. The resulting Web pages are rendered as hypertext mark-up language (HTML). The Oracle Application Express development environment provides many out-of-the-box features, such as interactive reports and flash charts, and enables developers to rapidly deploy Web application that greatly enhance user interactivity.

Before Starting the Conversion Process

Before starting a conversion project, it is important to learn how to build applications with Oracle Application Express. The first step is to install Oracle Application Express within an Oracle Database instance. Oracle Application Express requires an Oracle database that is release 9.2.0.3 or later. To learn more, see Oracle Application Express Installation Guide. To learn how to build applications based on existing Oracle database tables, review Oracle Database 2 Day + Application Express Developer's Guide.

The Oracle Application Express development environment utilizes wizards within a declarative environment and enables you to easily extend components using SQL and PL/SQL. You can further extend the Oracle Application Express framework by incorporating JavasScript and Asynchronous JavasScript and XML (AJAX). To learn more, see "Implementing Business Logic".

Evaluating Whether to Convert or Build an Application from Scratch

Thanks to how quickly you can build a new application with in Oracle Application Express, it may seem quicker to build an application from scratch rather than loading the source application definitions into an Oracle Application Express conversion project and then generating an initial design.

When compared with developing an application from scratch, converting an existing application provides many benefits. Once the source files for the original application are loaded into the Oracle Application Express project, all developers can review the pertinent information without needing to refer back to Oracle Forms or Microsoft Access. There is no need for developers to become familiar with the source tool development environment.

Having the forms, reports, and queries loaded into a conversion project also provides an easy way to review the functionality and application logic provided in the old application. Even if these components are not used to generate an Oracle Application Express application, you can view, copy, and reuse the underlying SQL.

When converting from Oracle Forms another major benefit is the ability to track the conversion to ensure you fully implement all the business logic within the new application. By utilizing annotations within the conversion project, you can assign priorities, resources, and add notes or tags to any component. Completion progress can also be tracked to provide low-level project management capabilities.

Understanding What Oracle Application Express Application Conversion is Not

When you convert an application to Oracle Application Express, you do not simply load the source files, press a few buttons, and magically generate a completed application. The conversion capabilities are designed to provide an initial design that you then must enhance and expand to fully replicate the original application. The generated applications use the same Create Application wizard that you use to build applications based on existing Oracle tables or views. However, instead of needing to specify the generated pages, these are determined from the information loaded into the conversion project. For more information on how various source components are generated, see "Oracle Forms Generation Capabilities and Workarounds".

Once you have generated the initial design, you can take full advantage of the rapid application development capabilities available in Oracle Application Express to enhance the generated pages. Built-in wizards also enable you to quickly expand your new application by adding new pages and links as necessary.

Key Differences with Oracle Application Express

Understanding some of the key differences between Oracle Application Express and Oracle Forms or Microsoft Access will greatly assist you in redeveloping your applications

Topics in this section include:

Stateless Web Applications

Oracle Application Express does not maintain a constant state between the client (that is, the Web browser) and the database, but performs stateless transactions. A database session is only utilized when requesting or submitting a page. Because Oracle Application Express is stateless between the start and the end of a logical transaction, (for example, when updating a record) it is imperative to use optimistic locking rather than pessimistic locking.

Oracle Forms and Microsoft Access use pessimistic locking whereby the record is locked when a user requests a record for update. This lock is maintained until the record is completed (or committed) or canceled (or rolled back). One of the key reasons for not using pessimistic locking within a stateless Web application is that if a user closes their Web browser or looses their connection in the middle of a transaction, the record would remain locked.

Once form pages are generated by the Create Application or Create Page wizards, Automatic Row Fetch and Automatic Row Processing processes are generated which incorporate the MD5 checksum validation to enforce the optimistic locking. Before the record is sent to the database to be updated or deleted the MD5 initially created is compared to the MD5 value of the current database record to ensure they are the same. If they differ then the database record has been updated since it was queried and an error displays to the user.

One consequence of an HTML application is that a rendered page does not perform actions such as validations or hiding and showing fields as the user interacts with the page. Validations are performed when the user submits the page for processing. However, you can change this default behavior by utilizing JavaScript and AJAX. The time needed to load a page is influenced by the transmission speed and the speed with which the Web browser renders the page. Therefore, it is not advisable to attempt to completely replicate the client-side interactivity within a HTML application as the weight (or size) of the page will adversely affect page performance. As a best practice, only implement critical client-side actions.

Evaluating User Interface Design

Oracle Forms and Microsoft Access use different underlying technologies to present screens to users. In contrast, Oracle HTTP Server renders HTML through a Web browser. As a consequence the design of screens and items is markedly different.

When thinking about screen design, some screen layouts commonly used in Oracle Forms are not readily reproducible in Oracle Application Express. Oracle Application Express renders a complete HTML page and does not support the concept of windows and canvases. Oracle Application Express also has a limitation of one tabular form per page. Therefore, it is important to understand that it may be difficult to exactly reproduce the screen layouts of the source application. This also presents opportunities to redesign some of the key business processes and potentially streamline them or include addition paths to provide greater flexibility.

For example, a common layout in Oracle Forms, such as a master-detail-detail form, can be redeployed using a master form with reports for each of the detail views that link to separate pages for editing these details. These same detail pages can also be accessed from elsewhere in the application very easily.

Oracle Forms often uses the same screen for both querying records and then updating a single record at a time. This is achieved by performing a query directly on the form used for updating a single record. Oracle Application Express does not support the notion of Enter Query and Execute Query. Therefore, the conversion project generates an interactive report where records can be queried with a link to a form for editing a single record.

Oracle Application Express does not support coordinate positioning of fields on a page out-of-the-box, but uses HTML tables to set out elements such as labels and items. Items can be specified with attributes (such as New Line, New Field, Column Span, and Row Span) to determine how items are located within the HTML table.

About Business Logic Replication

One of the major facets of converting from either Oracle Forms or Microsoft Access is replicating the business user interface specific logic. It is important to separate business logic from logic for manipulating the user interface. Given the differences in user interface implementation, the majority of the associated logic from the original application will no longer be relevant. Oracle Application Express uses processes, computations, and validations to implement business logic. Some logic can also be replicated by utilizing default and source values within the Oracle Application Express item definition.

The key to ensuring your new application performs correctly is to understand how and when each of these functions operates. The ability to add conditional logic to any component within Oracle Application Express (including regions, items, branches, processes, computations and validations) also provides extensive flexibility when replicating the original business logic. For more information, see "Implementing Business Logic".

Creating an Oracle Application Express Migration Project

In an Oracle Forms conversion project, the data structures are already defined in an Oracle Database and do not necessarily need to be migrated. However, with Microsoft Access the data structures and data must first be migrated across to Oracle using SQL Developer. For more information on how to migrate data structures "Migrating a Microsoft Access Application".

Once the data structures are correctly implemented into a schema accessible to Oracle Application Express, then the basic process for conducting a conversion is to load the source application files into a project. The project is designed to show all the applicable components and provide the ability to generate an initial application design. After reviewing the project components and selecting the valid screens, reports, and items to be included, you can generate an Oracle Application Express application. With both a Forms Conversion project and an Access Migration project, some components loaded into a project cannot be generated. To learn more about generation capabilities and workarounds, see "Oracle Forms Generation Capabilities and Workarounds".