QAFE

Tag Archives: Forms conversion

QAFE 3.3.0 & Forms Conversion 1.12.0 Released

QAFE 3.3

We’ve just released version 3.3 of the QAFE Engine.

One of the most important features in this release is the introduction of Client Side Events. Without changing any QAML code, you can make sure that the body of an event gets executed on the client-side, as in the browser (change the external.properties file and add the value “clientside.event.enabled=true”). The biggest benefit is increased performance because a server round-trip is not needed, resulting in a more responsive application. For example, Chrome Developer Tools shows that it’s far more efficient.

network-panel

Because the execution happens client-side, you can see that QAFE doesn’t use any network resources anymore.

Note: by default the value for clientside.event.enabled is false.

Another big feature is the usage of REST interface to invoke business-actions. The benefit is that other front-end technologies (such as AngularJS, Web Components, any AJAX supported UI library)  can use the same logic through REST-JSON.

  • The QAFE Engine is now less dependent on third-party software
  • We’ve done cleanup of dependencies, e.g. XML libraries
  • New and improved Forms Conversion wizards for the QAML Builder
  • Updated documentation on GitHub
  • Several bugfixes

 

Forms Conversion 1.12.0

QAFE Oracle Forms Conversion to HTML5 and QAFE Oracle Forms Conversion to ADF are also updated and now available for anyone who wants to modernize the Oracle Forms stack to JEE standard applications.

Highlights of this release:

  • Major improvements on script generation, where all the logic is collected from the Oracle Form
  • In ADF conversion, the summary page in the wizard also shows the explicit TODOs for ADF developers
  • Specific combinations of items are rendered correctly
  • Layout improvements by improving the algorithm
  • Several bugfixes

To get started with our latest release, download the software here.

Character encoding after conversion

In this blog post, I will discuss the results of an Oracle Form converted to both ADF and QAFE that include unicode characters, and how to properly display them.

In case of non-ASCII characters support, make sure that the file itself is properly encoded. We can rectify the encoding by e.g. opening a file, that has non-ASCII characters, in a text editor like notepad (for Windows).

With the file opened:

  1. Go to “File -> Save As” in the menu.
  2. Select the proper encoding in the dialog at the bottom of the window. UTF-8 in our case.
  3. Save the file with the new encoding and overwrite the old file.
figure1

Figure 1: Windows notepad save file dialog

Character encoding in ADF

If you don’t take sufficient action, converting an application that contains non-ASCII characters (such as Chinese or Russian) from Oracle Forms to Oracle ADF would be displayed as question marks. Our objective is to make these characters display properly when running the ADF application.

For the example I use in this blog, I have modified 3 buttons out of a simple Oracle Form  so that they contain non-ASCII characters, I then converted the application to ADF. Below is the result of running the form; note the 3 buttons with question marks in the top left.

figure2

Figure 2: The running application with non-ASCII characters in the buttons

Set-up JDeveloper to use correct encoding

Now that we verified the file encoding to be in UTF-8, we can proceed with setting up JDeveloper to use the proper encoding.

There are three ways to set-up character encoding in JDeveloper

  1. Preferences
  2. Default project settings
  3. Per-project settings

Preferences

In JDeveloper, in the menu, go to “Tools” and select “Preferences”. The preferences dialog shows up, with “Environment” being the default selection.

figure3

Figure 3: Environment settings in JDeveloper

In case of the demo application, the encoding is set to “Cp1252”. The application in question contains characters that are not available in that encoding, so we switch this value to something that does support it. In this case UTF-8.

With that done, all projects in the workspace now show “UTF-8” as the value for the Encoding field when you select Preferences from the Tools menu.

Default project settings

In JDeveloper, in the menu, go to “Application” and select “Default Project Properties…”. The default project properties dialog shows up.

figure4

Figure 4: Default Project Properties encoding

Select “Compiler” and change the “Character Encoding” dropdown value to UTF-8. All projects in the workspace show UTF-8 as the value for the “Character Encoding” field when you select “Default Project Properties” from the “Tools” menu.

Per-project settings

The encoding can also be set on project-level, when the encoding is specific to a certain project.

To do this, in the menu, go to “Application” and this time select “Project Settings…”. The project settings dialog shows up.

Select “Compiler” as shown in figure 3 and set the character encoding value to UTF-8. This encoding will now be taken into account for the current active project.

Last step

With all the IDE configuration properly set-up to use UTF-8, there is one final step to take. In XML based files such as JSF Fragments, jsf, etc. we need to modify the XML prolog (<?xml version=”1.0″?> by default) to use the correct encoding in XML. Change the prolog to <?xml version=”1.0″ encoding=”UTF-8″?> (added the encoding attribute). Change the question marks.

The result

figure5

Figure 5: The application running with unicode support

Character encoding in QAFE

When converting your Oracle Form to QAFE, the output is a QAFE project in Eclipse. Because Eclipse handles encoding settings differently, the steps are also different.

Character encoding in Eclipse

Setting up proper encoding support in Eclipse is, just like JDeveloper, mostly configuration.

In Eclipse, this is usually configured per workspace. But if wanted, there is also a finer control of what should be UTF-8 encoded.

Content type specific encoding

In Eclipse it is possible to assign an encoding to individual content-types. It can be CSS, Java source files, property files or any other type that Eclipse supports. To do this, go to: “Windows > Preferences > General > Content Types > Text > {Choose file type} {Selected file type} > Default encoding > UTF-8”.

figure6

Figure 6: Content type encoding

Character encoding per workspace

To enable a specific encoding per workspace (meaning all projects inside that, both existing and to be created), go to: “Window > Preferences > General > Workspace”. Select the “Other” radio button in the “Text file encoding” block, and choose the correct encoding.

figure7

Figure 7: Workspace wide encoding

The result

A few notes about the end result; In this case I changed the labels to use UTF-8, but it would work for any kind of display text, be it on buttons or text fields.

figure8

Figure 8: End result

ADF Entity Object Merging: The Why and How

When converting one or more Oracle Forms, including multiple Data Blocks representing the same database table, the QAFE conversion service accumulates and aggregates them to a single Oracle ADF Entity Object. This blog discusses the rationale behind this and how it is implemented.

Oracle ADF Entity Objects

Oracle ADF has a Model View Controller (MVC) architecture (1,2). In short; an MVC architecture splits up the responsibilities of an application in three parts: the models, views and controllers. Views are representations of data captured in a model e.g., a table, chart, etc. Models represent data e.g., in the form of domain objects, and update the view. The controllers implement the operations on the data and manipulates the models.

In this blog we focus on the models of ADF called Entity Objects. Specifically, cases where they represent tables in a Database (3). In those cases, The Entity Object attributes represent columns from the corresponding table.

Conversion of Oracle Forms Concepts to Entity Objects

Simply put, in Oracle Forms, Data Blocks represent tables in a database and the Items of a Data Block represent the columns of these tables. Which table a Data Block represents is indicated by the “Query Data Source Name” property of the Data Block. Similarly, which column an Item represents is indicated by the “Column Name” property of the Item.

However, in Forms, multiple Data Blocks could represent the same table (i.e. the item-sets of such Data Blocks could be overlapping subsets of all columns of the table in question). In addition, multiple Forms could have Data Blocks representing the same table.

In an MVC framework, one normally prefers a single model to represent some piece of data (e.g. a database table (3) ). The rationale behind this; a single model representing some piece of code means more maintainable, easier to extend and better readable code.

In retrospect, the QAFE conversion service accumulates all Data Blocks representing the same table and converts them to an aggregate Entity Object that covers all needed columns represented by the accumulated Data Block Items. How the aggregated Entity Objects are created during conversion will be discussed in a subsequent section.

Note: Oracle Forms Data Blocks of multiple Forms, representing the same database table, are only accumulated and aggregated to one Entity Object if all the Forms in question are converted as part of the same batch.

QAFE Entity Object Aggregation Rules

The rules by which the QAFE conversion service aggregates Data Blocks to Entity Objects are described by the following pseudocode:

 

Example

Figure 1 and Figure 2 show two different Forms. Both have a Data Block representing a database table named HSD_EMPLOYEES, but they represent different columns of that table.

Note that the Data Block name does not equal the table name, which is indicated by the “Query Data Source Name” property. Also note that the Data Block Item name does not equal the column name, which is indicated by the “Column Name” property. However, when the “Column Name” property is absent, the QAFE conversion service will take the Item name to represent the column name.

Figure 3 shows the result of the QAFE conversion service in JDeveloper.  Depicting only one Entity Object that represents the HSD_EMPLOYEES table, named EmpEO. The attributes of this Entity Object represent all columns used in the Forms of Figure 1 and Figure 2.

In conclusion; this example shows that the QAFE conversion service has identified that both Forms use a Data Block referencing a specific database table and aggregated their functionality in a single Entity Object.

Figure1

Figure 1: Oracle Form HSD0004F with block EMP representing a subset of the columns of table HSD_EMPLOYEES.

Figure2

Figure 2: Oracle Form HSD0016F with block EMP representing a subset of the columns of table HSD_EMPLOYEES.

after

Figure 3: Conversion result, shown in JDeveloper, with Entity Object EmpEO having attributes representing all columns of table HSD_EMPLOYEES used in both HSD0004F and HSD0016F.

 

References

  1. Wikipedia, Oracle Application Development Framework, 2015-02-16, https://en.wikipedia.org/wiki/Oracle_Application_Development_Framework
  2. Wikipedia, Model-view-cotroller, 2015-02-16, https://en.wikipedia.org/wiki/Model-view-controller
  3. Oracle, About Oracle ADF Entity Objects, 2015-02-16 http://download.oracle.com/otn_hosted_doc/jdeveloper/1012/bc4j/intro/bc_aeo.html

QAFE Forms Conversion 1.9.0

We’ve just released QAFE Forms Conversion version 1.9.

This release contains stability improvements and bugfixes. Below is the list with the most important changes.

  • Overall database script improvements to reduce manual work after conversion
  • Proper trigger scripts handling
  • Handling of Forms Built-ins
  • If an FMB uses another FMB as parent, this is now automatically processed
  • Wizard overview to show how conversion credits are spent
  • Downloadable Analytics reports
  • QAFE Forms
  • Generic scalable LOV handling and output (simple and with input parameters)

ADF

  • Improvements made on tabpanels rendering
  • LOV handling in ADF out-of-the-box (simple and with input parameters)

Additionally, we’re working on documentation to tackle possible manual work for Forms Conversion.

This release is available now and can be used with the QAML Builder. Download and install the software from here.

For any questions or remarks, don’t hesitate to contact our support team at support@qafe.com and stay tuned for our next update!

High Speed Oracle Forms Modernization

On your marks? Get ready… set… go! Answer this: How much time and effort goes into modernizing Oracle FMB’s to forms that are ready for any browser, any user, on any device? With QAFE you could be done in about 4 minutes.

QAFE Oracle Forms Modernization does most of the job for you. And it offers great extra’s:

  • Reuse 60-70% of the code
  • Apply filterrules to make the output cleaner (remove all no longer applicable / needed code). A new feature to improve the quality of the output code.
  • Use the output and edit/run directly in QAML Builder
  • Provide your styling (by means of CSS)
  • Bulk process Forms after a ruleset is defined
  • Forms Analysis for a better impact analysis

The end result – even without any manual code changes afterwards – is a set of working  data-aware applications. Logic in the Form is automatically placed in the new architecture on the correct level (in a Service Oriented Way).

Find out how QAFE Oracle Forms Modernization does most of the job for you. 

Where pieces of logic are not reusable, QAFE provides them as comments in the QAML code so that the developer can manually modify those bits. Also QAFE offers many additional features to enhance the forms, beyond what is currently possible in Oracle’s client-server infrastructure. And thanks to the automated modernization you have all the time in the world to make those enhancements.

Ready to instantly exceed the CIO’s expectations?

The automated Oracle Forms Modernization process is a QAFE application, for details on how to obtain a license for your (or your clients) business(es) please call + 31 70 319 5000, or contact us to find out how QAFE Oracle Forms Modernization does most of the job for you.

Oracle Forms 2.0

With QAFE, we have come up with a comprehensive solution to the growing demand for an effective and efficient strategy to migrate from Oracle Forms to the modern web. Making it possible to head both in the direction of Web 2.0 (think GWT and Adobe Flex, but also future standards) and move towards SOA. You don’t need to worry about the details. Thanks to QAFE, you can tackle the important tasks and ignore the fads.

  • No far-reaching investments necessary
  • Developers with basic XML, SQL/PL-SQL knowledge can immediately be productive
  • Great possibilities at a significantly lower licensing cost
  • Unlock Oracle Forms for all browsers on all devices from one single platform
  • Maximum ease and functionality for organizations, users, and developers

PS To increase the speed of development, we also have a wide range of tools which dramatically increase your productivity. Contact us here to find out how QAFE Oracle Forms Modernization does most of the job for you.

Forms Conversion at OBUG

On March 23rd OBUG (Oracle Benelux User Group) organizes OBUG Benelux Connect. The conference will take place at conference centre Papendal in Arnhem. If you happen to attend, make sure to look us up! Here is where you can find QAFE:

Benelux Connect 2010
Tuesday March 23
Break out session 48
Time: 14.30 – 15.15 h
Theatre 6

The topic of our Break out session will be Oracle Forms Conversion made easy.