ORACLE FORMS & REPORTS 11.1.2.2 INFORMATION AND FINDINGS

UPDATED: June 3, 2014

INTRODUCTION

Oracle has just recently released an updated version of Oracle Forms 11gR2 versioned as 11.1.2.2. For what we have seen on Oracle’s website and Oracle Support, the following has been updated in the latest version of Oracle Forms 11gR2 (11.1.2.2):

·         Many bugs have been fixed (See Oracle Support ID 1612530.1 for a list of the bugs fixed)

·         Only Oracle WebLogic Server (WLS) 10.3.6 is supported

·       The operating system support is the same as 11.1.2.1 except for the following:

o   AIX 6.1 must be Update Level 7 or higher

o   AIX 7.1 must be Update Level 1 or higher

o   Windows XP is no longer supported with Forms 11.1.2.2

o   NOTE: Currently no support for Oracle Forms (any release) with Windows 8

·       JDK support:

o Using Java 6 – JDK 1.6.0_35+

o Using Java 7 – JDK 1.7.0_40+

·         Internet Browser support:

o   Internet Explorer: 8, 9, 10, 11 (IE 11 is only supported if Oracle Patch 18277370 is applied)

o   Firefox: 24+

o   Google Chrome: 29+

o   Safari: 5.x

·         Database support (No changes from Forms 11.1.2.1):

o   10.2.0.4+

o   11.1.0.7+

o   11.2.0.1+

o   12.1.0.1+

·          OAM support (No changes from Forms 11.1.2.1):

o   Oracle SSO 10gR3 (10.1.4.3+)

o   Oracle Access Management 11gR1 (11.1.1.5+)

o   Oracle Access Management 11gR2 (11.1.2.0.0)

o   Oracle Internet Directory (OID) 11gR1 (11.1.1.5+)

o   Oracle Virtual Directory (OVD) 11gR1 (11.1.1.5+)

·          This version is released as both a base installation and a patchset (Oracle patch 17882900) installation meaning that Oracle Forms 11.1.2.2 can either be installed as a separate installation or as a patch to an existing 11.1.2.0 or 11.1.2.1 installation.

·          On the Oracle Forms download page, there are no more downloads for Forms 11.1.2.0 or 11.1.2.1. Only Forms 11.1.2.2 can be downloaded from OTN.

For more information regarding Oracle Forms 11.1.2.2 certifications, please review Oracle’s certification matrix for Forms and Reports 11.1.2.2: http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen

SIMILARITIES/DIFFERENCES TO FORMS 11.1.2.1

After successfully installed and configured Oracle Forms & Reports 11.1.2.2 in both our Windows 7 64-bit and Oracle Linux 6.4 64-bit test environments, we found that there are no major functionality changes that we could detect. In our test installations, we worked with Oracle WebLogic Server 10.3.6 using JDK 1.7.0_45 (this was the latest JDK available for download as of January 8, 2014 when the test installs were performed). Based off the installation and configuration, we have noticed the following:

1.       The installation of Oracle Forms and Reports 11.1.2.2 (as well as running config.bat/sh) is identical to installing 11.1.2.1. The same steps are involved.

2.       Environment files and formsweb.cfg work the same. In order to use the latest JRE (since we were using JDK 7 in our test), we had to configure the jpi parameters in formsweb.cfg.

3.       Similar to Forms and Reports 11.1.2.1, we still receive the “REP-52262: Diagnostic output is disablederror when we try to run reports. In previous releases of Oracle Forms & Reports 11gR1 and 11gR2 (11.1.2.0), using the default setting in rwservlet.properties would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in 11.1.2.1 and 11.1.2.2, the default settings act the same as using <webcommandaccess>L0</webcommandaccess> in the file. To fix this, we had to manually add the parameter <webcommandaccess>L2</webcommandaccess> into rwservlet.properties and restart WLS_REPORTS before we could view generated reports. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this. URL: https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings/

4.       Patching your Forms 11.1.2.1 installation to 11.1.2.2 requires little effort. All that is required is to shut down all WebLogic servers associated with Forms 11.1.2.1, OPMN, and Node Manager. Running the patchset install and starting everything up afterward is all that is required.

a.       NOTE: When running the installer, make sure to select “Install Software – Do Not Configure”.

b.      NOTE: If you have an Oracle Database installed on the same PC/server where you are upgrading Forms and Reports, the database, TNS listener, and DB Console will need to be shut down as well in order to prevent a possible error during the upgrade.

5.       The OHS bug which occurred in many Oracle Forms 11.1.2.0 installations that was fixed in 11.1.2.1 is also fixed in 11.1.2.2. The bug was the case where you had to rollback and re-apply an Oracle patch to fix an issue where OHS would lose connectivity with the WLS_FORMS server after a report was run. URL: https://pitss.com/us/2012/10/08/how-to-fix-apache-bridge-error-bug-in-forms-11gr2/

6.       The Reports Builder bug where it crashes when viewing the Data Model in 64-bit machines has NOT been fixed with Forms and Reports 11.1.2.2. Fortunately, applying the fix as mentioned in https://pitss.com/us/2012/10/10/reports-builder-11gr2-crashes-when-viewing-data-model/ will still fix the problem. NOTE: If this was fixed manually in Forms 11.1.2.1 and you patch the install to 11.1.2.2, you do not have to redo this.

7.       Oracle Forms & Reports 11.1.2.2 is backwards-compatible with Oracle Forms & Reports 11.1.2.1. We tested this by successfully opening up or loading a form in either an 11.1.2.1 Forms Builder or PITSS.CON saved in either Forms Builder or PITSS.CON using Forms 11.1.2.2. This means that if you are working with someone who is using Oracle Forms 11.1.2.2, you are able to use your PITSS.CON or Forms Builder using Forms 11.1.2.1 without any problems. NOTE: Forms 11.1.2.2 is not backwards-compatible with Forms 11gR1.

8.       In Oracle Forms 11.1.1.6, 11.1.2.0, and 11.1.2.1, there was a bug where you were unable to edit any configuration files or logging information for OHS within Enterprise Manager as mentioned in https://pitss.com/us/2013/10/18/unable-to-edit-ohs-configuration-files-in-enterprise-manager-for-forms-11-1-1-6-or-11gr2/. This bug has been fixed in Forms 11.1.2.2 (as well as 11.1.1.7 if you are using Forms 11gR1).

9.       All Oracle jar files (frmall.jar, frmwebutil.jar, and any other jar file which starts with “frm”) have been updated with the permissions and codebase manifest attributes needed for the later Java JDK and JRE updates. Before you decide to upgrade your JDK and JRE to the latest version (Java 7u45 or higher) in your Forms and Reports 11.1.2.0 and 11.1.2.1 environment, it is best to upgrade to Forms and Reports 11.1.2.2 first (and WebLogic 10.3.6 if you are using 10.3.5). For any custom jar files used in Forms and Reports, they will still need to contain the permissions and codebase manifest attributes (and signed with trusted certificates). Please see https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/ for more information.

10.   Like earlier releases of Oracle Forms and Reports 11gR2 (11.1.2.0 and 11.1.2.1), WebUtil for Forms 11.1.2.2 uses Jacob 1.14.3. No changes to the Jacob DLLs are required.

11.   If you have Forms and Reports integrated with Oracle Access Manager (OAM) 11g, no changes are required on the OAM or OID side. Simply upgrading Forms from 11.1.2.1 (or 11.1.2.0) to 11.1.2.2 is all that is needed to log into your Forms application using OAM.

12.   When configuring Oracle Forms and Reports 11.1.2.2 (using config.bat or config.sh) and you are integrating with OAM, you will still get an error when connecting to the OAM domain even if all information is entered correctly. This bug that was first seen in Forms 11.1.2.1 and 11.1.1.7 has NOT been fixed in 11.1.2.2. You will need to run config.bat or config.sh using the –novalidation flag to work around this error. NOTE: Be very careful when running the configuration wizard if you use the –novalidation flag as the wizard will NOT perform any tests or checks to see if anything entered is valid or invalid. More information can be found at https://pitss.com/us/2013/04/12/forms-and-reports-11gr2-configuration-fails-at-access-control-step-with-oam-2/.

 

Other than what we mentioned above, we did not notice any other major differences. We also setup a test PITSS.CON 12.2.2 environment to run in Oracle Forms & Reports 11.1.2.2. The newest PITSS.CON version, 12.2.2 (as of January 8, 2014), works well with Forms 11.1.2.2. Everything works the same as it did in Oracle Forms 11.1.2.1.

Updated: May 15, 2014

Due to the latest Java security patches beginning with JRE 1.7.0_25 and higher (especially JRE 1.7.0_45), all jar files have to be updated with the codebase and permissions attributes (and also the Application-Name attribute starting with JRE 1.7.0_45 although not mandatory at this time). For any jar files supplied by Oracle, please install Oracle Patch 16837591. NOTE: Do NOT update the Oracle jar files yourself! PITSS will not be held responsible if the Oracle jar files are tampered with. For steps on how to install the patch, please review our KB article at https://pitss.com/us/2013/09/26/how-to-fix-missing-permissions-manifest-and-missing-codebase-manifest-warnings-in-oracle-forms-using-jre-1-7-0_25-or-higher/.

To update any custom-made jar files (or even jacob.jar) to include these parameters in the Java code, you may follow these steps:

NOTE: In this example, MIDDLEWARE_HOME is C:\Oracle\Middleware (/oracle/middleware) and the ORACLE_HOME for Forms/Reports is C:\Oracle\Middleware\as_1 (/oracle/middleware/as_1)

  1. Navigate to %ORACLE_HOME%\forms\java ($ORACLE_HOME/forms/java).
  2. Create a new file called mymanifest.txt using a text editor.
  3. Add the following values into the text file:
    1. Permissions: all-permissions
    2. Codebase: *
    3. Application-Name: OracleForms
    4. image
    5. IMPORTANT: Please add a line below the Application-Name attribute. Otherwise, this attribute will not be added to the manifest file!
  4. Save and close the file.
  5. In Command Prompt (Windows) or your SSH client (Unix), echo your PATH environment variable to make sure your JDK is in the PATH. Example: C:\Program Files\Java\jdk1.7.0_45\bin;… If it is not there, update the PATH variable as follows (using JDK 1.7.0_45 as an example):
    1. Windows: set PATH=C:Program Files\Java\jdk1.7.0_45\bin;%PATH%
    2. Unix: export PATH=/oracle/jdk1.7.0_45/bin:$PATH
  6. Make sure you are in %ORACLE_HOME%\forms\java ($ORACLE_HOME/forms/java) and run the following command:
    1. jar –ufm name_of_jar.jar mymanifest.txt
    2. Example: jar –ufm jacob.jar mymanifest.txt
  7. Repeat step 6 for any other custom-made jar files.
  8. Resign any jar files you have updated in steps 6 and 7.
  9. Restart WLS_FORMS
  10. Close all browser windows and start a new browser window. Launch your Forms application.

If successful, you should no longer see the “Missing permissions manifest…” and “Missing codebase manifest…” errors for your custom-made jar files.

Source: Oracle Support note 1583119.1

NOTE (Added December 17, 2013, modified June 3, 2014): PITSS.CON 12.2.2 has been released. The newest PITSS.CON release contains the fix to the problem which consists of all PITSS.CON jar files signed with trusted certificates. PITSS.CON 12.2.2 functions successfully with Java JRE 7 Update 60. Please contact PITSS to upgrade your PITSS.CON version to the latest release. See the “Resolution” section near the bottom for more information.

For the most part, there is not much of a difference between Java 7u45 and 7u40 when it comes to running non-PITSS.CON related Forms applications.

However, when we try to run PITSS.CON using JRE 7u45, we get two Java security warnings similar to the ones you get when using JRE 7u40 with only minor differences:

clip_image001

However, after clicking “Run” in both Java security warnings, PITSS.CON remains at a gray screen indefinitely. When we go to the Java console, we receive Java-related errors due to unsigned jar files:

clip_image002

In conclusion, PITSS.CON will not run at all with the latest Java runtime 7u45. The Internet browser will remain at a gray screen indefinitely:

clip_image004

With the latest Java release, additional security measures have been taken with older Java releases. All Java updates before 7u45 are presented with the following message when they are used with PITSS.CON (or other Forms applications which uses Java during runtime):

clip_image005

This message will appear for all Java 7 Runtime updates prior to 7u45. Clicking “Update (recommended)” will update you to Java 7u45 where clicking “Later” will keep you at the same Java Runtime level you are currently using.

Oracle has made the current Java 7 update the recommended update to have. Due to this, they have added extra security settings to older Java 7 runtimes. Due to this, we have experimented with the following Java 7 runtimes with PITSS.CON and have made the following conclusions from our analysis:

Java 7 Update 21 and older

No problems occur. Everything runs fine in PITSS.CON (the PITSS.CON Editor comes up) regardless of the security settings in the Java Control Panel. NOTE: If you are using Java 7 Update 21 and the PITSS.CON Editor does not work, please see our knowledge base article https://pitss.com/us/2013/10/09/unable-to-open-pitss-con-editor-when-using-java-runtime-7-update-21-or-higher/ which addresses this issue.

Java 7 Update 25

With the default Java console settings, PITSS.CON does not come up at all after receiving many blocked Java application errors such as:

clip_image006

clip_image007

In the Java console (see screenshot below for an example), if we change the Security settings from High (recommended) to Medium, PITSS.CON comes up like normal, but we get a new message (see screenshot below the Java Control Panel screenshot):

clip_image008

clip_image009

Fortunately with JRE 7u25, we’re also given an option to have the warning above to not appear again. However, changing the security settings from High to medium is not recommended as it could present possible security risks if an end-user runs anything with Java outside of PITSS.CON or his/her Forms application.

Java 7 Update 40

We receive the same warnings as we do with Java 7 update 25. We also get the following message:

clip_image010

However, PITSS.CON is able to be used. The only difference is that the PITSS.CON Editor does not work.

When we change the Java Control Panel security settings from High to Medium, we get the original Java security warnings along with this new message:

clip_image011

The end result is that this is similar to using the Medium security settings in the Java console as what is done with Java 7 update 25. When we click the check box and click “Run”, PITSS.CON runs perfectly, including the PITSS.CON Editor. The only difference is that the warning message will always appear and you do not have the option to not have it appear again.

Java 7 Update 45

As mentioned at the top of the page, PITSS.CON does not work at all regardless of the Java Control Panel security settings.

Resolution

PITSS.CON Version 12.2.2 has been released on December 17, 2013. Please upgrade to the latest and greatest version of PITSS.CON which contains all PITSS.CON jar files signed with trusted certificates. After upgrading to PITSS.CON 12.2.2, PITSS.CON will run on the latest Java 7 JRE (including the JRE 7 Update 60).

After upgrading to PITSS.CON 12.2.2, instead of Java security warnings, you will see the following Java notification:

image

This time, PITSS.CON is now signed with a trusted publisher. To eliminate this message from appearing, simply check “Do not show this again for apps from the publisher and location above”.

NOTE: If you have already deployed jacob.jar in %ORACLE_HOME%\forms\java, you will need to replace it with the one in the PITSS.CON directories. You can do this by:

  1. Copy jacob.jar from C:\pitsscon\PitssJava to %ORACLE_HOME%\forms\java
  2. Restart WLS_FORMS

PITSS.CON Releases Affected: All PITSS.CON releases up through 12.1.3 (version 12.2.2 is the first version where the Java security warnings will no longer appear).

 

You might run into an ADF Mobile deployment error below:

Cannot run program “… platform-toolsaapt”

CreateProcess error=2, The system cannot find the file specified.

The cause of the error was that the “Android SDK Tools” was updated from Rev. 21.1 to Rev 22. 

 

The reason Rev. 22 causes the error is more on the side of JDeveloper. It moved appt.exe to a different directory, however you can’t configure JDeveloper where to find this executable.

To fix the issue, take your SDK version back to Rev. 21.1, by extracting the Rev 21.1 zip. You will have to re-install the Android APIs, but it shouldn’t take long to get re-setup. However, if you want use Rev 22, copy the contents of %SDK_Home%/build-tools/android-4.2.2 to%SDK_Home%/platform-tools.

Until Oracle changes how JDeveloper can find the binary, you can use this workaround!

 

Update (05/21/2013): Per Chris Muir, ADF Product Manager, this issue has been officially logged at Oracle as a bug 168376554. You can monitor the status of this bug in My Oracle Support (http://support.oracle.com) – as long as you have access to viewing Oracle Bugs.
Source: https://blogs.oracle.com/onesizedoesntfitall/entry/adf_mobile_deploying_to_android

There have been many cases where attempting to run a form from Forms Builder (purposes of debugging, testing, etc.) will never load the form in the web browser. The page seems to load indefinitely. The URL in the web browser appears to be strange, e.g. http://localhost:51254/X3mJODZxuhNaw9heH7GByuTd1amw3HKIb1pCfGIfIUOKtYXu

image

To fix this problem, click into the address bar where the URL is and press the Enter key. This will run the form every time.

NOTE: This issue has been seen with 10g (10gR2), 11gR1, and 11gR2 Forms Builders.

 

If you are new to JDeveloper and ADF, then it is recommend to read the book, “Quick Start Guide to Oracle Fusion Development: Oracle JDeveloper and Oracle ADF” http://www.amazon.com/Quick-Start-Oracle-Fusion-Development/dp/0071744282. It covers all of the basic areas of JDeveloper and ADF including the topics discussed below.  

While you can define a lot of application logic via JDeveloper/ADF declarative components, most logic that you need to add needs to be coded in Java. This is where AM, VO, and EO implementation classes and managed/backing beans come into play.

Every application has business logic and user interface logic. Web Development in general has fallen into a standard way of developing this logic. By which seperates application objects into four basic layers: Data Services, followed by Model, View, Controller (MVC).

  • Data Services: Database, Web Services, XML Data, etc…
  • Model: Place for queries, C.R.U.D. operations, and any additional business logic
  • View: user interface objects
  • Controller: Determines how user interface objects interact with one another.


Especially in an object oriented world that programming has become, separating your application logic and objects and making them reusable is key to a well structured and maintainable application. The MVC application architecture allows you to accomplish such a goal.

Before we talk about what and how you would use java implementation classes of each Model layer object (AM, EO, VO), you need to understand the use and significance behind each object.

Entity Objects (EO) are the source code representation of a database table. This is ultimately the layer that executes the insert, update, and delete commands against the database, however, an entity view object will need to present the EO.

View Objects (VO) are read-only database queries or updatable view objects that represent an EO. All VOs are what are ultimately exposed as data controls in your Application Module – so that you can generate tables, forms, and other data-bound objects in your JSF pages.

Application Module (AM) are what allow the ADF application to expose VOs and any other custom java business logic to a JSF page. For example, so you have a an employees database table, by which you have setup an EO and VO to work with that table. You can add the VO to your AM as a data control, so that you can generate an Employee insert or update form on your JSF pages. Basically Application Modules are the glue that allows your JSF Pages to view data of a view object.

You can generate implementation classes on all three of these objects (EO, VO, and AM). When it comes to implementation classes, AM and VO Implementation classes are used the most often. Keep in mind these are very basic examples, you can do so much more with these classes:

  • EO: Unless you need to change how records are literally inserted, updated, or deleted, there is almost no need to use these. Once you start getting familiar with how the EO, VO, and AMs work, you’ll understand.


  • VO:
    • ViewObjectImplementation Class: This gives you a comprehensive ability to change how your ViewObject is defined, how it queries an entity object or database, and how it functions in general.
      For example, say you want to set a bind variable that is used in your View Object Query. ViewObjectImplementation classes give you the methods to set those bind variables.
    • ViewObjectRowImplemtation Class: This gives you the ability to change how the data of your view object attributes are set and retrieved.
      For example, say you have a Project Task table where you have a Start Date, End Date, and Task Duration column. You want Task Duration to be  (Start Date – End Date). RowImplementation Classes allow you to calculate (Start Date – End Date) and set the Task Duration Column.

  • AM:
    • Application Module [Implementation] Class:  This gives you comprehensive access to all of the data controls (View Objects) that you added to your AM. In addition, if you need to add any custom business logic, this is the recommended place to “initiate” that logic.
      For example, you can write a custom procedure to move data around or do advanced calculations in your Application Module Implementation class and expose them as a Data Control, so that you can use the data control on your JSF pages.
    • There are additional classes like “Client Interface” and “Client Class”, however all you need to know about these, is that they allow you to expose custom methods written in your Application Module Implementation class as a data control.



This article was written to quickly address, on the high level, many questions surrounding the use of implementation classes. More in-depth and comprehensive examples will be written in the PITSS knowledge base in the days to come.

UPDATE (6/26/14): The next Java 7 update 7u60 (1.7.0_60) has been released as of June 2014. This is the recommended Java runtime to use which contains the most recent security patches. This KB article has been updated to reflect the latest Java SE 7 patch released by Oracle.

In recent weeks, Oracle continues to find new security vulnerabilities with each version of Java (JDK, JRE, etc.). Each new JDK/JRE release contains new patches which patch any possible vulnerabilities which have been discovered. When Oracle Forms and Reports 11g first came out, only JDK/JRE 6 was supported as Java 7 was not released at the time. Due to this, many older versions of Oracle Forms 11g do not have support with JDK/JRE 7 according to Oracle’s certification matrix. At the same time, there are more recommendations which advise of applying the latest Java patches which would upgrade the JDK and/or JRE to version 7 even if the Forms environment is not supported with it. For anybody who might be considering the use of the latest version of Java 7 to be protected from newly-discovered security vulnerabilities, this leads to some common questions:

  1. Will my environment be supported?
  2. How do I start using Java 7 with Forms if I am using a version which does not support the use of Java 7?
  3. If I upgrade to a supported environment, do I need to make any configuration changes?
  4. What is new to the latest Java update?

1. Will my environment be supported?

To answer the first question, it is important to know which Oracle Forms environments are supported with Java 7 and which are not. Oracle Forms as well as all Oracle Fusion Middleware products utilize Oracle WebLogic Server as the application server environment starting with 11g. In order for a Forms 11g environment to be supported with Java 7, the Oracle WebLogic Server version MUST be 10.3.6 (the latest version of WLS (WLS 12c is NOT supported with Forms 11g) as of April 16, 2013). If you are using an older version of Oracle WebLogic Server and you wish to start using the latest version of Java, WLS must be upgraded to version 10.3.6. After verifying your WebLogic Server version, you will need to verify the version of Oracle Forms you are using.

The following Oracle Forms versions are supported to use Java 7 if using WLS 10.3.6 (using the latest update currently released):

  • 11gR1
    • Oracle Forms & Reports 11.1.1.6
    • Oracle Forms & Reports 11.1.1.7
  • 11gR2
    • Oracle Forms & Reports 11.1.2.1
    • Oracle Forms & Reports 11.1.2.2

The following Oracle Forms versions are NOT supported to use Java 7:

  • 11gR1
    • Oracle Forms & Reports 11.1.1.1
    • Oracle Forms & Reports 11.1.1.2
    • Oracle Forms & Reports 11.1.1.3
    • Oracle Forms & Reports 11.1.1.4
    • Oracle Forms & Reports 11.1.1.5
  • 11gR2
    • Oracle Forms & Reports 11.1.2.0

2. How do I start using Java 7 with Forms if I am using a version which does not support the use of Java 7?

After verifying your Forms version, if you wish to start using Java 7 with Forms and you are using a Forms version which does NOT support using Java 7 (this leads to the second question mentioned above), both the WebLogic Server and Forms/Reports installations will need to be upgraded. The following list contain upgrade paths which you can take to upgrade your installation to an environment which supports using Java 7:

  • 11gR1 (If you are also using Oracle Portal and/or Oracle Discoverer)
    • Oracle Forms & Reports 11.1.1.1 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.1.6 or 11.1.1.7
    • Oracle Forms & Reports 11.1.1.2 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.1.6 or 11.1.1.7
    • Oracle Forms & Reports 11.1.1.3 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.1.6 or 11.1.1.7
    • Oracle Forms & Reports 11.1.1.4 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.1.6 or 11.1.1.7
    • Oracle Forms & Reports 11.1.1.5 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.1.6 or 11.1.1.7
  • 11gR1 (If you are only using Oracle Forms and Reports)
    • Oracle Forms & Reports 11.1.1.1 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2 (latest version of Oracle Forms)
    • Oracle Forms & Reports 11.1.1.2 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2
    • Oracle Forms & Reports 11.1.1.3 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2
    • Oracle Forms & Reports 11.1.1.4 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2
    • Oracle Forms & Reports 11.1.1.5 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2
  • 11gR2
    • Oracle Forms & Reports 11.1.2.0 –> Upgrade to WLS 10.3.6 and Forms & Reports 11.1.2.2

3. If I upgrade to a supported environment, do I need to make any configuration changes?

Let’s say that you are now using either Oracle Forms version 11.1.1.6/11.1.1.7 (latest 11gR1 versions) or 11.1.2.2 (latest 11gR2 version) after upgrading from an older version. If you were to start running the application right now, it is guaranteed that each client will either continue or install Java Runtime Environment 6 (version 1.6.0_25 for example). This leads to the third question mentioned earlier. Some minor changes will need to be made in formsweb.cfg (located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_11.1.#\config). More specifically, the jpi parameters will need to be updated.

Once formsweb.cfg is open in a text editor (make a backup first), go into the default section first. You will need to look for these four parameters:

  • jpi_download_page
  • jpi_classid
  • jpi_codebase
  • jpi_mimetype

These parameters are still configured to use JRE 6. To have each client start using the latest version of Java, the following updates will need to be done (comment out the old ones as backups):

  • jpi_download_page=http://java.sun.com/products/archive/j2se/7u60/index.html
  • jpi_classid=clsid:CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA
  • jpi_codebase=http://java.sun.com/update/1.7.0/jinstall-7u60-windows-i586.cab#Version=1,7,0,60 (NOTE: This will prompt IE browsers to use only the latest JRE 7)
  • jpi_mimetype=application/x-java-applet;jpi-version=1.7.0_60

Be sure to apply the above changes in each section in formsweb.cfg which you are using for your environment. After saving the changes in formsweb.cfg, it is also recommended to recompile your forms, menus, libraries, and reports. After this is done, you should be able to start testing your application.

NOTE: If you are now using Forms/Reports 11.1.2.1 or 11.1.2.2 and you receive REP-52262 errors when running reports, please see https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings for more information.

NOTE: If you run into any issues installing or running your Forms application using JRE 7, manually installing the latest Java runtime may help fix the problem especially if the browser is unable to install it automatically. More information can be found here: https://pitss.com/us/2013/02/20/how-to-manually-install-a-jre-for-running-oracle-forms-on-a-client-pc

4. What is new to the latest Java update?

Starting with Java 7 update 21 (7u21 or 1.7.0_21), more user-friendly Java warnings appear due to either unsigned Java code (Jar files, JavaScript (New to JDK 7u21) or if jar files are not signed with a trusted certificate (e.g. X.509). Examples are shown here:

Updated JRE 7u21 Security Warning

The above screenshot appears if a jar file is not signed with a trusted certificate. Unless told specifically by the owner of the jar file (or if you are running a Forms application in a DEV/TEST environment using self-signed certificates), it is strongly recommended not to run them. If the publisher is known and you trust the publisher, you can click the checkbox next to “I accept the risk and want to run this application”. If you do not want to have the warning appear again for the same publisher, click “Show Options” and place a check box next to “Do not show…”, and it will not appear again. It is recommended NOT to do this in production! NOTE: Starting with Java 7 Update 40, you no longer have the option to click a check box to not have the warning appear again.

Java 7u21 Unsigned code warning

The above screenshot appears if a jar file either contains unsigned code or a mix of signed & unsigned code. It is recommended to click “Block” when this window appears. NOTE: If this message appears when launching PITSS.CON, click “Don’t Block” as this appears due to the fact that GIFs are used for the PITSS background and logo which cannot be signed.

Also, the Java Control Panel no longer has the settings for “Low” and “Custom”. Only “Very High”, “High” (default), or “Medium” can be used.

More information can be found at Oracle’s press release on Java 7u21 at: http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html.

To view the list of the 42 security vulnerabilities patched in Java 7u21, please review: http://www.oracle.com/technetwork/topics/security/javacpuapr2013verbose-1928687.html

For more information on working with the latest Java security features introduced in 7u25, 7u40, and 7u45, please see the following articles:

How to Fix the Missing Permissions and Codebase Manifest Warnings for Oracle Forms jar files: https://pitss.com/us/2013/09/26/how-to-fix-missing-permissions-manifest-and-missing-codebase-manifest-warnings-in-oracle-forms-using-jre-1-7-0_25-or-higher/

How to Fix the Missing Permissions and Codebase Manifest Warnings for Custom jar files: https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/

Using PITSS.CON with the latest Java 7 Updates: https://pitss.com/us/2013/10/17/unable-to-run-pitss-con-with-java-runtime-7-update-45/

 

Sources:

Oracle Certification Matrix for Forms, Reports, and other Fusion Middleware products for 11gR1: http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xls

Oracle Certification Matrix for Forms and Reports 11gR2 (11.1.2.0): http://www.oracle.com/technetwork/developer-tools/forms/oracle-forms-11gr2certmatrix-519680.xls

Oracle Certification Matrix for Forms and Reports 11gR2 (11.1.2.1): http://www.oracle.com/technetwork/developer-tools/forms/oracle-forms-111210certmatrix-1886127.xls

Oracle Certification Matrix for Forms and Reports 11gR2 (11.1.2.2): http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen

Oracle JDK 7u21 Update Release Notes: http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html

Oracle JDK 7u45 Update Release Notes: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html

Oracle JDK 7u60 Update Release Notes: http://www.oracle.com/technetwork/java/javase/7u60-relnotes-2200106.html

ORACLE FORMS & REPORTS 11.1.2.1 INFORMATION AND FINDINGS

INTRODUCTION

Oracle has just recently released an updated version of Oracle Forms 11gR2 versioned as 11.1.2.1. For what we have seen on Oracle’s website and Oracle Support, the following has been updated in the latest version of Oracle Forms 11gR2:

·         Many bugs have been fixed

·         Like the previous version of 11gR2 Forms, it is supported with Oracle WebLogic Server (WLS) 10.3.5 AND 10.3.6

·         The operating system support is (except for the addition of RHEL 6 and Solaris 11) the same as 11.1.2.0

·         JDK support

o   Using WLS 10.3.5 – JDK 1.6.0_35+

o   Using WLS 10.3.6 – JDK 1.7.0_7+

·         Internet Browser support – same as in 11.1.2.0

·         Database support:

o   10.2.0.4+

o   11.1.0.7+

o   11.2.0.1+

o   12.1.0.1+ (New to Forms 11.1.2.1)

·         OAM support:

o   Oracle SSO 10gR3 (10.1.4.3+) (same as before)

o   Oracle Access Management 11gR1 (11.1.1.5+)

o   Oracle Access Management 11gR2 (11.1.2.0.0) (New to Forms 11.1.2.1)

o   Oracle Internet Directory (OID) 11gR1 (11.1.1.5+)

o   Oracle Virtual Directory (OVD) 11gR1 (11.1.1.5+)

·         This version is released as both a base installation and a patchset (Oracle patch 15948641) installation meaning that we can install Oracle Forms 11.1.2.1 as a separate installation or as a patch to an existing 11.1.2.0 installation.

·         On the Oracle Forms download page, there are no more downloads for Forms 11.1.2.0. Only Forms 11.1.2.1 can be downloaded from OTN.

 

Reference: Oracle Support note 1503701.1

SIMILARITIES/DIFFERENCES TO FORMS 11.1.2.0

After successfully installed and configured Oracle Forms & Reports 11.1.2.1 in our Windows 7 64-bit test environment, we found that there are no major functionality changes that we could detect. In our test installation, we worked with Oracle WebLogic Server 10.3.6 using JDK 1.7.0_10 (this is the latest JDK available for download) as we were curious to see how JDK 7 would work with Forms. Based off the installation and configuration, we have noticed the following:

1.       The installation of Oracle Forms and Reports 11.1.2.1 (as well as running config.bat) is identical to installing 11.1.2.0. The same steps are involved.

2.       Environment files and formsweb.cfg work the same. In order to use the latest JRE (since we was using JDK 7 in our test), we had to configure the jpi parameters in formsweb.cfg.

3.       In Forms Builder, we had to specify a web browser location in Edit –> Preferences before we could run a form using Forms Builder.

4.       For some reason, nothing involving rwservlet would work (including viewing generated PDF reports) as we always received “REP-52262: Diagnostic output is disabled.” In previous releases of Oracle Forms & Reports 11gR1 and 11gR2, using the default setting in rwservlet.properties would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in 11.1.2.1, the default settings act the same as using <webcommandaccess>L0</webcommandaccess> in the file. To fix this, we had to manually add the parameter <webcommandaccess>L2</webcommandaccess> into rwservlet.properties and restart WLS_REPORTS before we could view generated reports. URL: https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings/

5.       If you are using Oracle Forms 11.1.2.1 using WebLogic Server 10.3.6 (not 10.3.5), JDK 7 (including the latest JDK update available) works well. The tabbing issue seems to have been fixed.

6.       The OHS bug which occurred in many Oracle Forms 11.1.2.0 installations no longer occurs. The bug was the case where you had to rollback and re-apply an Oracle patch to fix an issue where OHS would lose connectivity with the WLS_FORMS server after a report was run. We had this occur with some of our customers on Windows 7 64-bit.

7.       The Reports Builder bug where it crashes when viewing the Data Model in 64-bit machines has NOT been fixed. Fortunately, applying the fix as mentioned in https://pitss.com/us/2012/10/10/reports-builder-11gr2-crashes-when-viewing-data-model/ will still fix the problem.

8.       Oracle Forms & Reports 11.1.2.1 is backwards-compatible with Oracle Forms & Reports 11.1.2.0. We tested this by successfully opening up or loading a form in either an 11.1.2.0 Forms Builder or PITSS.CON saved in either Forms Builder or PITSS.CON using Forms 11.1.2.1. This means that if you are working with a customer who is using Oracle Forms 11.1.2.1, you are able to use your PITSS.CON or Forms Builder using Forms 11.1.2.0 without any problems. NOTE: Forms 11.1.2.1 is not backwards-compatible with Forms 11gR1.

 

Other than what we mentioned above, we did not notice any other major differences. We also setup a test PITSS.CON 8.0.4.2 environment to run in Oracle Forms & Reports 11.1.2.1. The newest PITSS.CON version, 12.2.2 (as of December 20, 2013), works well with Forms 11.1.2.1. Everything works the same as it did in Oracle Forms 11.1.2.0.

Rules for Icon files:

  • Icons should be of the following dimensions: 17×17 or 16×16 pixels.
  • Gif’s should be used for icon files.
  • Any gifs manually uploaded to “$ORACLE_HOME/forms/java” will be used over any jar files containing the same gifs.
  • When an application uses gifs for icons, any gifs loaded in jar files – whom are referenced in the “archive” setting formsweb.cfg – will be used (but any gifs loaded into $ORACLE_HOME/forms/java will be used over the same gifs present in a jar file).
  • Whichever jar is listed first in the “archive” setting will be used – unless that same gif is manually loaded into $ORACLE_HOME/forms/java, then that gif will be loaded into the forms application.
  • Say for example, you have the following archive setting in your formsweb.cfg: archive=icons1.jar,icons2.jar,share.jar, frmall.jar. Say icons1.jar and icons2.jar has a gif named “myicon.gif”. myicon.gif from icons1.jar will be used in the forms application, instead of icons2.jar.
  • Continuing the current example, if icons2.jar is listed before icons1.jar in the archive setting (archive=icons2.jar, icons1.jar, share.jar, frmall.jar) and myicon.gif is not present in ‘forms/java’. myicon.gif from icons2.jar will be used.
  • Continuing to the final example, say myicon.gif is loaded into ‘$ORACLE_HOME/forms/java’ and in both icons1.jar and icons2.jar, with archive=icons1.jar,icons2.jar,share.jar,frmall.jar. myicon.gif that is loaded in $ORACLE_HOME/forms/java will be used instead of the version in the jar file.

NOTE: To deploy jar files, you will need to restart the WLS_FORMS server before changes can be seen.

For a free/open-source image editor, Gimp: http://www.gimp.org/

Although Reports Builder 11gR2 is supported on 64-bit Windows machines, there is a bug within Reports Builder 11gR2 64-bit where if you try to access “Data Models” for any report in Reports Builder, Reports Builder will crash (Windows error that generates is: “Report Builder has stopped working. Windows can check online for a solution to the problem.”). To work around this, you will need to do the following:

  1. Go to %ORACLE_INSTANCE%\config\FRComponent\frcommon\TOOLS\admin (%DOMAIN_HOME%\config\fmwconfig\components\ReportsToolsComponent\reptools1\tools\admin in 12c)
  2. Make a backup of cauprefs.ora
  3. Edit cauprefs.ora in a text editor
    • Find the following lines:
      • Reports.PluggableDataSourceFactories =
        (“oracle.reports.plugin.datasource.xmlpds.XMLDataSourceFactory”,
        “oracle.reports.plugin.datasource.jdbcpds.JDBCDataSourceFactory”,
        “oracle.reports.plugin.datasource.textpds.TextDataSourceFactory”)
    • Replace the value to: Reports.PluggableDataSourceFactories = ()
  4. Save the file and try running Reports Builder again.

NOTE: If you happen to use Pluggable Data Sources (PDS) in your reports, the workaround will not work.

UPDATE: This error also occurs in the latest release of Oracle Forms & Reports 11gR2 (11.1.2.2) and 12c.
Reference: See Oracle Support note 1395965.1 for more information.