Coming from IAF via FastForms and later SQL*Forms, Oracle Forms Developer has been the main GUI development tool on the Oracle Database since version 6. There have been some changes in the product over the years where WebForms was the biggest change, moving from client-server to a web-server environment. It gave the users the possibility to implement a GUI environment over the Web, but the basics stayed the same. The Oracle Forms applications run in a JavaApplet (J2EE) called Jinitior, and have been built using the Oracle Forms Developer and the PL/SQL language.

Moving away from Oracle Forms requires some guts. Most organizations using Forms have large knowledge of the tool and the PL/SQL language, and don't move to a completely different environment in a short period of time. Languages such as Java are difficult to learn and hard to understand for developers not trained in the object-oriented language sets.

And there was APEX.

Oracle Application Express, in short APEX, was a new way of looking at PL/SQL GUI development using only a web browser. Developers could still be using their fast knowledge on PL/SQL and the Oracle Database, and since APEX version 3.2 (released on the February 27, 2009, a memorable day) we were able to convert Oracle Forms applications to APEX easily. This is what this book is all about.

Using the new possibilities in Oracle Application Express, we will find a new way to create APEX pages from our original Forms and Reports applications. We no longer have to build them from scratch if we want to generate the pages in APEX. Forms Conversion has made it possible to create APEX applications from our Forms and Reports applications in a fast and reliable way. But beware; we still have to do some work to make it all possible. In this book we will point out the steps you will have to take to create your applications using the Forms Conversion tool.

Every Forms and Reports application consists of a few elements, namely Forms modules, Menus, PL/SQL libraries, Object libraries, and Report modules. All these elements will be used in our Forms Conversion project. They will all be translated to their own specific APEX components during the conversion.

In the following diagram provided to us from Oracle, you can clearly see which steps need to be taken, and in which order, to create and execute a Forms Conversion project. As we can see, the main part of the project will be done in the Oracle Application Express Forms Converter.

With our Forms Conversion project, we will have to use different tools to create our APEX application. Of course, we will have to use APEX as it contains the most important piece of tooling we have got, the APEX Forms Conversion tool. But besides that we will have to use Forms and Reports Builder, the File Conversion Utilities, and the Forms2XML Conversion Tool.

In this book we will generally learn how to create suitable XML files, but most work in our Forms Conversion project will be done in APEX.

In order to generate an APEX application, we will have to do some steps. First, we will have to create our XML files from the different Forms components. After that, we shall create our Conversion project in Oracle Application Express.

The project page is the point where we will be really working on our Forms Conversion. Because of the possibilities it gives us, we will learn how to analyze and adjust our Forms components in order to generate an APEX application.

The following screenshot shows the project home page in the APEX Forms Converter. This page is used to control our project and it shows our progress in the project.

Using the project home page in the Forms Conversion part of APEX, we can easily scan our application components and see how we are progressing. This is the place where we do our metadata analysis of the XML files we uploaded and the ones our project consists of. We can see all the elements of our Forms Conversion project, so we have a point where we can control everything we need to do in our project in the project home page.

Even after generating our APEX application, we will have some other things to do. Because of the large differences between APEX and Forms, we will need to adjust some things such as the logic and the User Interface defaults. We will see how the APEX application we generated responds to users, and how we need to make some adjustments in order to create a user-friendly and stable application.

Web 2.0 has taken a leap in the last few years; interactive user interfaces and the possibilities of tying applications together are the cornerstones of Oracle Application Express. Modern Internet applications offer users the possibility to create and adjust their own information just as a desktop application would, but with the advantages of accessing the applications over the Internet. APEX offers a lot of these Web 2.0 components out of the box, such as interactive reporting and flash charts. With interactive reporting, the users can define their own reporting, meaning they have control over the filters, break points, and calculations done in these reports.

Both Forms and APEX are completely SQL and PL/SQL based, so the transition from Forms to APEX should be easy to learn. Both tools are declarative, wizard-driven, rapid development tools. With the use of the Forms Conversion tool, it will be possible to speed up the transition to APEX within your organization. The tool uses our knowledge of the Forms applications we convert to let us make the best choices possible.

Oracle Application Express and, therefore, the Forms Conversion Tool is a no-cost option on the Oracle Database. Because of this and the fact that we no longer need an Application Server, APEX is the choice to make if you want to convert your Forms and Report applications to a web environment.

The Forms Conversion in Oracle Application Express offers us numerous possibilities when generating APEX pages from our original Forms, Reports, and Menus. These possibilities are extensive and, when wisely used, offer reductions in developer effort. In doing so, our transition from Oracle Forms and Reports to Oracle Application Express should be quicker and easier all round.

Navigating and adjusting logic is possibly the largest possible advantage you can get from the Forms Conversion tool in Application Express. We get information from the metadata (which is in the Forms, Reports, Menus, and Libraries) and have the advantage of knowing about the logic and different components before we begin the conversion.

Forms Conversion in Oracle Application Express is not migration but a conversion, as the word literally means. We will generate a different kind of application, namely an Internet application instead of a desktop or a Web Forms application.

Remind yourself that Forms Conversion in Oracle Application Express is not a way to emulate or completely migrate your Forms applications. Your users will get a different kind of application, and hence a different user experience. We will generate an Internet application, which also means that a lot of the functionality we've got in Forms will return in a different way. Forms conversion in Application Express doesn't mean we will have a Forms emulator or a complete replacement for the functionality within the Forms and Reports applications; we will create an interactive web application.

The following screenshot is of the Oracle Forms we will be converting to APEX in this book. In this typical Forms application, 'Customers', runs within a Java applet and, therefore, is used as a true Forms screen. The application that is used here is the Oracle Forms 10g demo application. We will be using it for all the examples in this book. You can download all the necessary files at http://www.oracle.com/technology/products/forms/files/summit10gr2.zip.

Oracle Forms has a lot of functionality that users appreciate, such as the keyboard shortcuts for a lot of functions (for example, F11 to enter a query and Ctrl + F11 to execute it). For people who use these applications, this means they will have a fast-performing and reliable application. All of these native Forms functionalities will not be present in our generated APEX pages. Beware that these functionalities will not be generated during the conversion project. Instead, we will get a fully functional web application built in APEX.

Next, we will see what the application looks like when we have converted it to APEX. In the following screenshot, we see that one master-detail Form Customers has been converted to two APEX pages. The following screenshot shows the master data, which is the Maintain Customer page:

The following screenshot shows the detailed data, which is the Customer Details page:

We see here that the pages we create during the Forms Conversion project really are different from the original Forms screens. During a Forms Conversion project, we will have to bear in mind that we will create a different kind of application.

If you're planning a conversion project from Oracle Forms and Reports to Application Express, these differences must be communicated to your users.

The generated APEX pages will have their own advantages. For example, the menus you created in Oracle Forms will be generated as a home page in the new APEX application, complete with icons. In this way will have a new way of navigating through our application. Because APEX uses components that can be described as Web 2.0, the users will get an interactive application in return. And, of course, we can adjust these generated pages according to our taste in the end of the project.

Because the project isn't 'frozen' after the generation of the new APEX pages, we are able to redesign and tweak parts of the application that were not very good to begin with. By taking the Forms Conversion project as a starting point, at the end of the project we can adjust these generated pages according to our taste.

Oracle Forms and APEX have their differences. These differences are not only limited architectural and functional, but are also present in the naming of the elements on which the applications are built. The following table shows how Oracle Forms elements and Oracle APEX elements are related to each other:

As we can see, there are a lot of differences between the two development tools, Forms and APEX. This is not unusual because they both result in different types of applications.

In this book we will provide a lot of information, but because this book is written for developers and analysts who know both Forms and APEX, we will not go into the depths of everything. The following web pages can help you find out more about these topics:

In this book we will cover the basics and provide an insight on how to perform a Forms Conversion project using Oracle Application Express. We will go through some critical steps that need to be done to make such a project a success.

Of course, we will need to understand our original Forms and Reports application —how will our conversion project be generated and how does it work?

In Chapter 1 of this book, we learn how we can use our knowledge of Oracle Forms and Reports to our benefit. We will also learn how we can use the powers that are given to us in the Forms Conversion tool to determine various modules and iterations in our project. The original Forms and Reports application is central in this part of the book. This is because, like history, we will need to know our past in order to understand our future.

Chapter 2 shows us what we need to get things ready for our Conversion project. We need to gather all our original Forms, Reports, Menus, and Libraries so that we can generate the APEX project. We will need to get the XML sources by using the tools in the Oracle Developer Suite. Of course, we will learn to understand these newly created sources and what they mean to us. Before we can create our APEX applications using the Forms Conversion tool, it would be nice to design and implement the target database.

In Chapters 3 and 4, we can create ourselves a Forms Conversion Project. Uploading the XML files we just created will create a project for us. We will then learn to add more sources to the project in order to to finalize it (along with the iterations and modules which we defined earlier). The most important part in the Forms Conversion tool in Application Express is the project page and we will learn how to use it, adjust our project, and edit the settings in it.

The project plan is the main part of our Forms Conversion project. The generation is just a small part of the actual project. In what way do we execute our project and can we plan it in order to understand what we have to do? Chapter 4 of this book offers us some ways to judge the components we are about to convert into APEX. We learn some tricks on how to address and timeframe the development. It gives us an insight into what needs to be done and how we will do it.

At this point we will be able to browse the project page in our Forms Conversion project. Chapter 5 will show us how we use the project home page in order to get the logic in our project right. We can make annotations and assign logic to members of the project team who will be responsible for the conversion, and edit the applicability of the different components of our Forms Conversion project. In order to be ready for generation, we need information on our logic so that we can adjust it as needed.

Step-by-step, Chapter 6 will teach us how to generate the new APEX application out of the Forms Conversion project. The settings we applied earlier in our project are used to generate the Application Express application, and we will see how we integrate the menu structure from our Forms application in the new APEX application. Adding pages and choosing the user interface defaults are the additional steps we will take.

After we have generated our APEX application, we will need to review it. We will see what components and pages need further customization and in Chapter 7, we will learn how to do so. With a technical and functional review, we will see how the application works and performs. If we need to adjust logic, user interfaces, or processes in the new application, we will do so.

At the end of every project, we will need to deliver it to our users and production environments. Chapter 8 shows some of the main elements we will have to account for in order to deliver the application correctly. We will learn how to use our project plan in order to test the application and how we need to communicate the differences to our users. To make the new application a success in our production environment, we might integrate it with different modules of our project or with the existing applications. So we will learn what ways there are to do so. At this point we will have succeeded in converting our Forms and Reports applications to Oracle Application Express.

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text are shown as follows: "We will upload another Forms module, which is a _fmb.xml file."

Any command-line input or output is written as follows:

C:>cd C:\summit

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "To create a new project, click on the Create Project button."

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an email to <[email protected]>, and mention the book title via the subject of your message.

If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.