Oracle Application Express Forms Converter

3 (1 reviews total)
By Douwe Pieter van den Bos
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

Although Oracle Forms remains popular, many developers now see Oracle APEX as a preferred technology. Oracle Forms to Oracle APEX conversion projects follow a well-defined procedure, but sub-procedures and complexities can arise that make such conversion projects a challenging job.
This book will take you through a real Oracle Forms to APEX conversion project. It explains all the elements of the conversion, from generating XML files to the deployment of a working APEX application. By the end of this book, you will have mastered the process of Forms conversion.

The book starts with the details of the Forms project, and prepares you for the conversion process. You will use the rwconverter and Reports Builder in Oracle Developer Suite to generate XML and other useful files. You will plan and define the business logic for your conversion project. You will use the Forms Converter in Oracle APEX to convert and customize your Oracle Forms applications. Finally, you will deploy your application.

With this book you will understand what a Forms Conversion project in Oracle APEX means, what needs to be done, and what steps are necessary in order to create a fully functional and meaningful conversion project. This book shows the best way to convert applications from Forms to APEX.

Publication date:
July 2009
Publisher
Packt
Pages
172
ISBN
9781847197764

 

Chapter 1. Understanding your Project

To understand what we will be doing in our Forms Conversion Project, we will have to know what the application that we are going to convert is all about. What does the application do, both technically and functionally? If we understand why we want to convert the application and how the application works and is built, we will be able to create a more successful conversion project. In this chapter, we will discuss the following:

  • What are the reasons for conversion?

  • What does the application do?

  • How is the application built?

  • What are the possible modules and iterations?

Reasons for conversion

Every conversion project has its own reasons as to why it's needed, or wanted. There are lots of different reasons why an IT department or the users want a conversion project from the Forms applications to Application Exchange (APEX). If we divide these reasons into functional and technical categories, we will be able to pinpoint how the converted application must work. In other words, if we understand the benefits the organization gets from moving from Forms and Reports to APEX, the choices we have to make in our project will be a lot easier.

Functional reasons

There are a lot of questions we will ask our users and functional departments in order to get the picture of the great 'Why'. To fully understand why we do this conversion project, we will have to investigate the problems, difficulties, or unwanted restrictions that users are having with the current application. If we want to create a good project plan, we will have to know which of these questions must be answered.

These underlying reasons for conversion must be seen as new functional requirements in the new application. In this way, we will be able to understand how the new application must function after conversion, how it has to look, and what it's supposed to do.

There are a lot of different questions that must be answered before we start our project. The following are a few examples of questions that we want to ask. Bear in mind that these questions are indeed examples and every situation will be different.

  • Does the converted application need to be accessed from outside the company's network?

  • Do the users need the application to be integrated in other web applications or extranet functionalities?

  • Will the application be accessible to the users other than those who use it now?

  • Is the conversion needed for the functionality that Oracle Forms doesn't offer?

  • Do users need to have more control over the information that is displayed in the application?

Some examples of functional requirements might be that the company needs to have some information in the application that is accessible on the Internet. Of course, Oracle Forms can be pushed towards the Web using WebForms, but there's a need for an Oracle Application Server to use this technology. This is a costly solution and we are still working with Oracle Forms. When we use APEX, we no longer need the Oracle Application Server, but rather just an HTTP server.

Another functional reason for conversion is layout, and this might be one of the most important ones. This is because when we use APEX, we can use the graphical layout the company uses for its web site, or intranet site and completely integrate the application.

There are, of course, a lot of reasons why we need to convert the application from Forms to APEX. These might even be requirements that will not be met during the conversion project, but requests for additional functionality that is easily or better build in APEX. In this case, we can use the conversion project as a technical solution to start developing in APEX.

Remember that the examples I stated here are just examples. This means that every organization and, therefore, application will have its own requirements to address.

Technical reasons

Besides functional reasons for conversion, we will also see a lot of technical advantages of a Forms conversion project. Conversion is, in a lot of cases, done with technical reasons. These can be lowering the stress on the application server by using APEX, or lowering the operational costs by getting the application server out of the architecture. But it's also possible that we just want to kick out the jInitiator of the user's PC, or we want an HTML-based application.

Like the functional reasons, there will be a lot of different technical reasons for conversion to APEX. Asking the right question to the right people in your IT department will make you understand why the conversion is done. The following are some example questions that you will have to ask before you begin doing the conversion project:

  • Is the conversion done to cut operational costs?

  • Do we need to convert the application in order to modernize our environment?

  • Is the conversion done because we need completely browser-based applications?

  • Do we need the conversion because we want remote development possibilities?

 

Reasons for conversion


Every conversion project has its own reasons as to why it's needed, or wanted. There are lots of different reasons why an IT department or the users want a conversion project from the Forms applications to Application Exchange (APEX). If we divide these reasons into functional and technical categories, we will be able to pinpoint how the converted application must work. In other words, if we understand the benefits the organization gets from moving from Forms and Reports to APEX, the choices we have to make in our project will be a lot easier.

Functional reasons

There are a lot of questions we will ask our users and functional departments in order to get the picture of the great 'Why'. To fully understand why we do this conversion project, we will have to investigate the problems, difficulties, or unwanted restrictions that users are having with the current application. If we want to create a good project plan, we will have to know which of these questions must be answered.

These underlying reasons for conversion must be seen as new functional requirements in the new application. In this way, we will be able to understand how the new application must function after conversion, how it has to look, and what it's supposed to do.

There are a lot of different questions that must be answered before we start our project. The following are a few examples of questions that we want to ask. Bear in mind that these questions are indeed examples and every situation will be different.

  • Does the converted application need to be accessed from outside the company's network?

  • Do the users need the application to be integrated in other web applications or extranet functionalities?

  • Will the application be accessible to the users other than those who use it now?

  • Is the conversion needed for the functionality that Oracle Forms doesn't offer?

  • Do users need to have more control over the information that is displayed in the application?

Some examples of functional requirements might be that the company needs to have some information in the application that is accessible on the Internet. Of course, Oracle Forms can be pushed towards the Web using WebForms, but there's a need for an Oracle Application Server to use this technology. This is a costly solution and we are still working with Oracle Forms. When we use APEX, we no longer need the Oracle Application Server, but rather just an HTTP server.

Another functional reason for conversion is layout, and this might be one of the most important ones. This is because when we use APEX, we can use the graphical layout the company uses for its web site, or intranet site and completely integrate the application.

There are, of course, a lot of reasons why we need to convert the application from Forms to APEX. These might even be requirements that will not be met during the conversion project, but requests for additional functionality that is easily or better build in APEX. In this case, we can use the conversion project as a technical solution to start developing in APEX.

Remember that the examples I stated here are just examples. This means that every organization and, therefore, application will have its own requirements to address.

Technical reasons

Besides functional reasons for conversion, we will also see a lot of technical advantages of a Forms conversion project. Conversion is, in a lot of cases, done with technical reasons. These can be lowering the stress on the application server by using APEX, or lowering the operational costs by getting the application server out of the architecture. But it's also possible that we just want to kick out the jInitiator of the user's PC, or we want an HTML-based application.

Like the functional reasons, there will be a lot of different technical reasons for conversion to APEX. Asking the right question to the right people in your IT department will make you understand why the conversion is done. The following are some example questions that you will have to ask before you begin doing the conversion project:

  • Is the conversion done to cut operational costs?

  • Do we need to convert the application in order to modernize our environment?

  • Is the conversion done because we need completely browser-based applications?

  • Do we need the conversion because we want remote development possibilities?

 

Understanding the functionality


The most important task in the Forms conversion is that we create an application that the user wants, and will be able to understand and use. In order to make the project a success, we will want to know what the application does and why. Maybe, we will be able to find a functional design that was written during the build of the application, but even if we do, we will need to use the application ourselves to know what it does.

Any application is built to serve a business process. In order to understand that process, we must take a deeper look into the application and the process it was built for. The sequence in which we examine the application and the process is completely reliable on the point of view we take. An (technical) engineer would first prefer to take a look inside the application and after that in the process, whereas an analyst will directly dive inside the business process. But because we are converting an application and not redesigning it, the original application will always lead our investigations.

The application

The application that we will be converting has a functionality that is needed by the users of this application. In the original functional design, we will be able to see a lot of these functions. We will have to wonder why the application is originally built as it is. The application was built with a reason and probably has a lot of functionality built in; however, we, as technicians, will not see it firsthand.

The easiest way to understand the application is to ask one of the main users to walk through the application with you. This user can show you how the different screens work and how the flow of the application is set up. The users control and look up information and data in the application. The context of this data is important for our project. If we do not understand what the information is used for, we may make mistakes in creating our conversion project. Every user has his (or her) own interpretation of an application. The best way to fully understand the functionality and, therefore, the business process, is to go through the application with a few different users. Everyone will give a part of the information you are looking for.

In the following screenshot, we see a Forms application that lets the user edit and control the information about the customers of his organization. As we can see, the user has a lot of functionality inside this single forms screen. The user can look up the customers, their address, credit rating, and can also edit this information.

We can look at all the screens in the application. If we do so, we will also have to take a look at the error messages the user gets, the different rights the user has in the screens and, possibly, which user is granted editing and adding rights in the application.

Business process

If you understand the functionality in the screens, it's time to look at the business process that the screens represent. The first thing we will have to look at is the way the user works, what is the user's role in the organization, and why does the user use the application in his or her work? For example, the user probably has some steps to go through if he or she wants to add a customer to the application. Can the user approve the credit rating himself, or is there a different role in the organization for that?

The following Forms screen shows us the Credit Rating field in the Customers screen. Only users who work for the finance department with the right privileges will be able to edit this information. Because of this role, the business process is covered by multiple departments in the organization and there are multiple roles in the application.

The original application does a lot of things. Following the order of the steps that have to be taken is very important for our conversion project. That's because if we know how the application works, we will know to build certain parts of it such as the screen flow and menu structures.

User interaction

User interaction in the original application is of the essence when we try to understand the application we will have to build. There are some large differences between a Forms application and the one built using Oracle APEX. This means that we need to understand which screens in Forms are most likely to be different. With Oracle Forms, users are used to interacting with their data quite fast. They're used to working with an application that accepts quick entry and even validation is done on the fly. Screens that interact with a user in this way will likely need some JavaScript and AJAX in order to have the same user experience in APEX.

The application does a few different things. Ask the users you interview about the steps he or she would take to do a certain task in the application. For example, if the user wants to add an order for a new customer to the application, he or she first has to create the customer, then the finance department has to approve the credit rating, and then he or she can add the order for this new customer in the order Forms screen. There are certain buttons in the application that take the user to the next step in the business process, and there is a menu that the user uses to get to the next stage of this process.

It's important to understand what the user wants in the application. When we know the required navigation and user experience, we can implement them in APEX.

User roles

We mentioned in the example that the finance department has to approve the credit rating of the customer before the order department can add a new order to this customer. Is the credit rating approved in the same application as the order department? Do the users have the same role in the database, or do we have to take account of some security layers in the application?

The best thing to do in this phase of our project is to make a list of the different business processes and what role the users have in these processes. If we have this list, we can design now and later correctly test our converted application.

 

Understanding the technicality


Like the functionality of the original application, we are about to convert to APEX and the technical aspects are just as important. As technicians, we will need to know the application and its engine. If we know the sources of this application, we will know what we have to do in our conversion project.

Components

In most Forms applications, we will have more than one Forms screen, and probably even more components of which we will have to take an account. These components are the base of the application and, therefore, the base of our project.

There are a lot of different components in most of the Forms applications. Think about Forms, Reports, Menus, and Libraries. Because we have a lot of different source files, we will need to look at all of these and understand what they do in the application. If we got the different components together, we will better understand how the application is originally built. In this way, we will know the actual size and complexity of the application.

It's always best to make a list of the different components that are in an application we will convert. When we make this list, we will make notes on what components contain which functionality and, approximately, how much work it will be to convert these components. These are the first set of steps to the project plan we will need to have.

Architecture

It's necessary to be familiar with the original architecture of the application. We need to know if the logic that is used in the Forms application is nested in the Oracle Database, or if the logic is all contained in the Forms application itself. Of course, all kinds of flavors are possible here, and so we need to take a look inside the Forms Builder.

If we have an application that contains a lot of code and logic within the PL/SQL libraries on the application server, we will have a lot more trouble converting it than if the Forms application simply calls stored procedures in the database.

In the following example, you see a Forms Builder look on the program units in a Forms application. Here, the procedure calls a Forms trigger that raises a 'Forms Trigger Failure' message. When we perform the Forms conversion, it will be better if we know what the different parts of the application do.

These architectural questions are very important to know before you begin your Forms Conversion project, mainly because a lot of time will be put in the recreation of logic. If the logic is right to begin with, the project will be smaller.

Forms builder

If we look at our different kinds of components—Forms modules, Object Libraries, Forms Menus, PL/SQL Libraries, and Reports Files—we will want to know more about them. How do they work and in what way are they built?

We will have an extensive look at the components in the Forms Builder and the Reports Builder if we have such components in our application. Take a look at the different pieces of information this gives us. We will learn how the screen is built, what triggers and program units there are, and with which properties the original application was built.

In the following screenshot, we can see the canvas of the Orders screen in Oracle Forms. As we can see, the application was built on one canvas with a few subcanvases. We got our MAIN canvas, which contains four subcanvases: the TREE canvas for navigating through the CUSTOMERS in the application, the CUST_SUMMARY canvas, CUST_STACKED canvas, and the CUSTOMER TAB canvas.

In the following example, we see that multiple are canvases possible in one Forms screen. They react like multiple regions in an APEX application without the MAIN canvas. If we know this before, we might be able to convert the application faster and with more insight.

If we look further at our CUSTOMERS Forms application, we will see that we are able to know the sources for the data which we use in our application. In the following screenshot, we see the properties of the S_CUSTOMER data block in the Forms application CUSTOMERS. As we can see, the data block is based on a SQL Query as usual. Surprisingly, the data source comes from the S_CUSTOMER table in the database.

The information we will gather in Forms Developer can also be found the moment we create a Forms conversion project in APEX. In the project page we will see the different data blocks, program units, and other important parts of the Forms application. But at this point, it will be extremely handy to know what we are dealing with.

 

Modules and iterations


When we create a Forms conversion project in APEX, we will be able to create different applications from one original Forms application. The reason we might want to do this is because we will be able to spread our resources and plan the project a lot better if we cut it into little pieces.

Modular design of the new APEX application will be possible at this point. If we are able to cut the project in different modules and iterations, we have the opportunity to create a reliable project. Every Forms conversion project will know its downsides. Some logic will be difficult to convert and we might need to rewrite it for the conversion project. But it's also possible that our project contains partly non-convertible Forms screens that we will have to build on our own. The parts that are non-convertible will be tracked during the project, so don't let this scare you away.

Remember that non-conversion mostly lies in the way a Forms screen is built. Canvases, Windows, Visual Attributes, and other Forms components will not be in the conversion to APEX because APEX can't use them. When we encounter these elements, we have to adjust the look and feel of APEX itself.

An example of this is that APEX cannot contain more than one tabular form in a page. This means that a basic master detail screen in Oracle Forms will be generated to two APEX pages.

Modules

Modules can be created on functional or technical bases. We can base the functional module on a business process, user role, or even on a logical separate part of the application. If we define the logical or functional modules, we can work with a small team on these modules and even put them in a separate iteration. If we want to cut the project in technical modules, the easiest way is to look at the components on which the application is built. Everything that is interconnected will be placed in one module. In this way, we will have different parts of the application separately. These different parts of the application can be connected to each other at a later stage.

Iterations

When we know the modules, we will create our Forms conversion plan. This is the time to think about the iterations our project will be in. If we have cut the application in functional and/or technical bits, we can combine these into an iteration plan. We will not go into the iterations planning here because we're talking about Forms conversion. But later in this book, we will learn how to combine different modules and iterations together in the technical sense.

Modules and iterations are necessary to keep the project conveniently arranged. The development plan for the project management will be a lot easier with the application divided into little bits. Technically, we will have more applications in the end than what we begin with, but we will combine them together when we deploy the application at the end of our project.

 

Summary


In this chapter we learned how our application was built. As we will need to make choices in the rest of our project, it helps if we know what the different parts of the application mean. We learned that we had to take the following steps to be ready for conversion:

  • We need to understand why we are performing a Forms conversion project. It can be for functional reasons (such as users who need the application outside the office walls) or for technical reasons (such as a need to get rid of the expensive Oracle application server). Of course, it's possible to have a combination.

  • To understand the functionality in the original Forms application, we need to take a look at the application itself, the business process it supports, the user interaction, and the roles the users have in the application.

  • On the technical side, it can be very helpful if we take a further look at the different components that are in the application, the architecture and how it's built, and the different components in Forms Builder.

  • When we know how the application is built, both functionally and technically, we will be able to define different modules in the new application that helps us define iterations for development. During the deployment of the application, we will combine these modules into one application.

About the Author

  • Douwe Pieter van den Bos

    Douwe Pieter van den Bos started working as an Oracle Developer using Oracle Designer and Oracle Forms. Soon he discovered the wondrous world of Oracle Application Express and was one of the first people in the Netherlands to be using this tool in real live applications. His first encounters with the development of APEX applications and, later on, his thoughts on web development and project management were written down on his own personal website, http://ome-b.nl. This web site became the only Dutch APEX related website and a knowledge base on everything APEX.

    Browse publications by this author

Latest Reviews

(1 reviews total)
this was not exactly what I thought it was; but it was educational
Book Title
Access this book and the full library for FREE
Access now