As of March 7, 2017, Mozilla has released the newest release of Firefox, version 52. Similar to what Google Chrome did about a year or so ago, Mozilla has now disabled the NPAPI plug-in which is required to run anything with Java such as Oracle Forms without using Java Web Start. What will happen is if Firefox is updated to version 52 and you try to access Forms, you will see a blank screen which will result in the Forms application to not start at all.

Fortunately, Mozilla has realized that businesses still need to use services such as Java during this transition, so Mozilla has released the Firefox “Extended Support Release” for version 52. This is a version of Firefox which is used by companies and organizations which need support for running Java with the NPAPI plug-in especially for mass deployments. The current ESR version of 52 will continue to allow the use of the NPAPI plug-in for Java through May 2018. The download link (to download the 32-bit Firefox 52 ESR for Windows 32 and 64-bit machines) may be found here:

https://www.mozilla.org/en-US/firefox/organizations/all/

After this is installed on your PC, you will be able to run Forms using Firefox again without the need of Java Web Start. This is important for anyone who is still running Forms 11gR2 (or older) which has no support for Java Web Start. However, if you are running Forms 12c, you may use Java Web Start which allows you to run Java (required for running Oracle Forms) without the NPAPI plug-in. Java Web Start allows you to run Oracle Forms 12c from any web browser (Internet Explorer, Firefox, Chrome, Edge, etc.). If you decide to use Java Web Start, the Firefox ESR is not necessary.

Sources: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Why-do-Java-Silverlight-Adobe-Acrobat-and-other-plugins-no/ta-p/31069 and https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/

 

There is a known issue in PITSS.CON where reinstalling Source Control (also referred to as Version Control) causes Source Control to no longer appear as an option within PITSS.CON. This has been seen after you have upgraded from an older release to either 16.1 or 16.2.1. Users who upgrade from 15.4.2 or older to 16.2.2 (or users who are using 15.4.2 or older) will not experience the problem. This is only encountered after an upgrade and Source Control is reinstalled (not upgraded). Fixing the problem will require several steps to restore Source Control functionality in PITSS.CON.

  1. Upgrade your PITSS.CON (all users) to version 16.2.2. Do not worry about the Version Control user as we will reinstall it again.
  2. Once all users are upgraded to PITSS.CON 16.2.2, install Version Control again.
  3. In the PITSS.CON 16.2.2 installer, go into the “script_install” folder and locate the script, user_grants.sql. Create a copy of the script and open it in Notepad.
    1. VC_3
  4. In the copied file, replace “&NEW_USER” with your Version Control user (e.g. “VC”). Save and close the file.
    1. VC_4
  5. Open up Command Prompt, and navigate to the folder with the updated script.
    1. VC_5
  6. Launch SQLPLUS with the MIG user and run the script.
    1. VC_6
  7. Log out of SQLPLUS and navigate to the “script_vc” folder located inside the “version_control” folder in the PITSS.CON setup folder.
    1. VC_7
  8. Log into SQLPLUS with the Version Control user and run the script “pitsscon.sql”.
    1. VC_8
  9. When asked to type in the setup folder path, type in the directory where Version Control was installed and press “Enter” (e.g. C:\pitsscon\vc).
    1. VC_9
  10. If you see the error, “ORA-02291: integrity constraint (MIG.SELF_REF) violated – parent key not found”, run the following SQL commands with the Version Control use
    1. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, COLOR) VALUES (’80’, ‘Source Control’, ‘Application and Development Process Management’, ‘FOLDER’, ‘r56g120b184’);
    2. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, PARENT_ID, FORM_ASOC, ICON) VALUES (‘8010’, ‘Source Control’, ‘Secure, version and track changes to application files and Oracle DB objects.’, ‘TOOL’, ’80’, ‘vers_control’, ‘vc_add_files_wb’);
    3. commit;
    4. VC_10
  11. In the PITSS.CON database, query the MIG_PITSSCON_USERS table, and look up (and write down) the USER_ID attributes of all installed PITSS.CON users except for MIG.
    1. VC_11
  12. Return to your SQLPLUS session (as the Version Control user) and run the following command for each PITSS.CON user other than MIG. The <USER_ID> attribute should be the value of the attribute for the PITSS.CON user you are updating.
    1. INSERT INTO “MIG”.”PITSSCON_USERS_RIGHTS” (USER_ID, TOOL_ID, IS_SELECTED) VALUES (‘<USER_ID>’, ‘8010’, ‘Y’);
    2. VC_12
  13. Commit all changes: commit;
    1. VC_13

After making the above changes, the Source Control button should be available again in PITSS.CON.

VC_14

NOTE: For Forms 12c, when you enter Source Control, and you notice that you are unable to log into your Source Control user other than Administrator, there might have been a corruption when upgrading previously to 16.1 or 16.2.1. A full reinstall of PITSS.CON including the MIG user may be required. Please contact PITSS Support at pitssam-support@pitss.com for instructions on how to reinstall MIG and preserve your PITSS.CON license. This particular issue has currently not been seen when upgrading from PITSS.CON 15.4.2 or older to 16.2.2.

For Oracle Forms 11gR2 and 12c protected by OAM using WebGate, there are known reports where users may encounter errors after being logged into the application for 60 minutes:

FRM-92091: Unexpected fatal error in client-side Java code

or

FRM-92102: A network error or server failure has occurred

The reason for these errors is because the “Token Validity Period” is being reached. This is a setting configured in the webgate agent. By default, this parameter is set to 60 minutes or 1 hour. This means that regardless if the end user has been using Forms for a full hour or if the user has left his or her Forms session idle for an hour, a timeout will occur. To solve this problem, the Token Validity Period setting in the webgate agent will need to be increased to a value (in minutes) where end users will not encounter these errors (i.e. 480 minutes (8 hours) or 540 minutes (9 hours)). You will need to determine the amount of time before this timeout occurs.

NOTE: When you update the Token Validity Period for the webgate, you will need to redeploy the WebGate files generated in the $OAM_DOMAIN_HOME/output/<WebGateAgentName> directory into the OHS home’s webgate/conf folder as well as restart OHS.

After making the change above, the errors should no longer occur once 60 minutes has passed.

Source: Oracle Support Document ID 2178936.1

Oracle HTTP Server (OHS) can be used to redirect users to a new site when a particular URL is specified. This is useful if you would like to have users go to a new domain or website if they still would like to access an old URL. A RewriteRule can be written in httpd.conf (for HTTP) and/or ssl.conf (for HTTPS) to perform this. This can be implemented in both 11g and 12c. The following steps are written for 12c, but they can also be used for 11g to redirect traffic from the starting OHS page (http://server.domain:<ohs_port>) to another page:

  1. Log into EM Fusion Middleware Control.
  2. Go to the Target Navigation (you may have to click the button in 12c to access the menu), expand HTTP Server, right-click on ohs1, go to Administration –> Advanced Configuration.
    1. Target Navigation
  3. If you are using 12c, click the lock button in the top-right corner, and select “Lock & Edit”. If you are using 11g, you may skip to step 4.
    1. Lock and Edit
  4. Select “httpd.conf” in the drop-down menu and click “Go”.
  5. Scroll to the very bottom of the file. Add the following three lines:
    1. RewriteEngine On
      RewriteCond %{REQUEST_URI} ^/$
      RewriteRule ^(.*)$ http://<server>.<domain>:<OHS_PORT>/newhtml.html [R,L]
    2. NOTE: You may also redirect to a new domain such as <newserver>.<newdomain> using the same rewrite rule parameter.
    3. RewriteEngine
  6. Click “Apply” to save all changes.
  7. If you would like to also perform a redirect when using HTTPS, you may apply the same changes for ssl.conf. If you do not need to do this, please skip to step 9. However, when adding these three lines in ssl.conf, it should be before the closing </ifModule> tag and the rewrite rule should use HTTPS. You may use the screenshot below as an example.
    1. RewriteEngine SSL
  8. Click “Apply” to save all changes.
  9. (Skip to Step 10 if you are using 11g). In the top-right corner, click the lock button and select “Activate Changes”.
  10. Restart OHS.

After applying the steps above, when the index.html page is accessed of your OHS server using http(s)://<server>.<domain>:<OHS_PORT>, the URL will be immediately redirected to the page you specified in the RewriteRule.

By default, if you were to access the showjobs page of your Oracle Reports 11g or 12c environment, any user is able to view the page and open up the reports even if they contain confidential information. There is a way you can configure the showjobs to where only specific users can access this page or any of the Reports admin pages (steps written for 12c but they will also work for 11g):

  1. Open up rwservlet.properties (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_12.2.1/configuration.
  2. Locate the line <webcommandaccess>L2</webcommandaccess>. Change L2 to L1.
    1. L1 will only permit end users to use the non-admin rwservlet commands GETJOBID, KILLJOBID, SHOWAUTH, and SHOWJOBID.
    2. rwservlet.properties
  3. Save and close the file.
  4. Open up rwserver.conf (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/components/ReportsServerComponent/$rptsvr.
  5. Near the bottom of the file, look for the line <queue maxQueueSize=”1000”/>. Immediately after this line, add the following line:
    1. <identifier encrypted=”no”>username/password</identifier>
    2. NOTE: After you restart WLS_REPORTS and rep_server1, the credentials will be encrypted. Also, you may create any username/password combination you like. It does not need to be what is configured in weblogic or in the database.
    3. rwserver.conf update
  1. Save and close the file.
  2. Restart both WLS_REPORTS and the standalone reports server.
  3. Try to access showjobs normally. You should be presented with the following error:
    1. REP-52262: Diagnostic output is disabled
    2. REP-52262
  1. Now, add “?authId=username/password” to the end of the URL. Notice how the showjobs page appears.
    1. showjobs working
  1. If you were to reopen rwserver.conf, notice how the credentials are encrypted:
    1. rwserver.conf encrypted

Source: Oracle Support document 1242614.1 (Steps in the Oracle Support document are written for 11g)

As of October 28, 2015, Oracle Forms and Reports version 11.1.2.2.0 is now supported with Windows Server 2012 R2 (64-bit) and Windows 8.1 (NOTE: Forms 12c has been supported with these OS versions since its first release). However, because the certification with Windows Server 2012 R2 and Windows 8.1 was added well after the terminal release of Oracle Forms and Reports 11gR2 (11.1.2.2.0), an Oracle Patch, 20836354, is required during the installation of Oracle Forms and Reports.

You may download the patch from My Oracle Support: https://support.oracle.com/epmos/faces/PatchDetail?patchId=20836354&requestId=18892137 (NOTE: The patch is incorrectly labeled for Oracle Linux 7. This patch should only be used for Windows Server 2012 R2 and Windows 8.1 as Oracle Linux 7 is not supported with Oracle Forms 11gR2. However, Oracle Linux 7 is supported with Forms 12c.)

Once the patch is downloaded, extract it in the Windows file system. You will need to reference this patch when starting the installation of Oracle Forms and Reports. This may be done using these steps:

  1. Open up Command Prompt as an administrator (right-click on cmd.exe or Command Prompt and select “Run as administrator”)
  2. Navigate to the location (using the cd command) of setup.exe for Oracle Forms 11.1.2.2.0.
  3. Launch the Forms installer using this command: setup.exe PREREQ_CONFIG_LOCATION=<PATH_TO_EXTRACTED_PATCH>\prereq

That should allow you to complete the Forms 11gR2 installation without any errors during the Prerequisite Check screen. You should be able to use the installer normally.

NOTE: Windows 10 is currently not supported for both Forms 11gR2 and Forms 12c at this time.

After extending a domain with Oracle Forms and Reports with an additional Forms and Reports managed server, WLS_FORMS1 and WLS_REPORTS1, in a cluster, there is a known issue (this may or may not occur) where the standalone reports server of the original installation is unable to communicate with the EM Agent associated with the AdminServer for the Forms domain. For example, if you log into the Enterprise Manager (EM) Fusion Middleware (FMW) Control associated with your Forms domain, if this problem occurs, you will see the warning “Targets not being monitored due to invalid configuration”. If you click on this warning message, it will take you to the Agent-Monitored Targets page (you may also access this page by right-clicking the domain farm name in the left panel and selecting “Agent-Monitored Targets”). On this page, you may notice that one of the “Oracle Reports Server” targets needs an agent configured:

Agent-Monitored Targets

However, if you click to configure the agent for the target and you click OK after all fields entered are correct, you will get an error saying that there is no agent available.

To fix this problem, when you are in the Configure Target page, click the button “Change Agent”. The agent URL next to the Change Agent button will become a drop-down, and you should be able to select the correct agent associated with your standalone reports server:

Agent-Monitored Targets

After the agent is selected, click “OK” to save your changes. After completing this step, the target will be able to contact the agent successfully.

Even when WebUtil and Jacob have been fully configured in the PITSS.CON server environment as documented in https://pitss.com/us/2014/03/20/forms-and-reports-11g-environment-requirements-for-webutil/, there have been known issues where users (on the first use of PITSS.CON) are unable to log in due to the following error:

NoClassDefFoundError – com/jacob/com/ComFailException

No Jacob

The reason for this error is because the Java cache may be interfering with properly finding the Java classes associated with jacob.jar. Clearing the Java cache should fix the problem:

  1. Open up the Control Panel on the end user’s PC
  2. Go to All Control Panel Items and click “Java”
  3. With the General tab highlighted in the Java Control Panel, click “Settings…”Java Control Panel
  4. Click “Delete Files…”Delete Temporary Java Files
  5. In the new pop-up window, have only “Trace and Log Files” and “Cached Applications and Applets” selected and click “OK”.Clearing Java cache
  6. After the window closes, click “OK” twice to close all windows in the Java Control Panel.
  7. Close all web browser windows and try launching PITSS.CON.

After completing the steps above, PITSS.CON should launch without any problems.

When updating forms to a live production environment, if a form is updated when end users have the form open, users may encounter odd errors. Although a form can be copied over an open form in Unix, it is not possible to copy over an open form in Windows.

One recommendation is to implement two deployment locations: the actual location where all of the production forms are deployed and a temporary location for new deployments which is specified earlier in the FORMS_PATH. New or updated forms are deployed in the temporary location and then moved over to the main location during a time when no one will be using the application.

Example FORMS_PATH entry:

FORMS_PATH=C:\Oracle\Middleware\Oracle_FRHome1\forms;C:\app\forms_new;C:\app\forms

C:\app\forms_new would be an example of a temporary location where new and updated forms would go and C:\app\forms would be an example of the current live forms.

In this example, forms are deployed under C:\app\forms. When a new form needs to be deployed during working hours when the app is being heavily used, it is deployed under C:\app\forms_new. As new users connect or reconnect to a form, they connect to the new form under forms_new since it is earlier in the FORMS_PATH. Eventually no one is using the form under C:\app\forms, and during off hours, the form can be moved from C:\app\forms_new to C:\app\forms.

IMPORTANT: Downloading JDK and JRE 7 from My Oracle Support requires an account with My Oracle Support.

As of July 14, 2015, JDK 7 and JRE 7 are no longer available for public download. Although the latest version of Oracle Forms, version 11.1.2.2.0 (11gR2) is supported to use JRE 8, it is currently NOT supported to use JDK 8 for Oracle Forms and Reports 11gR2 as well as for other Fusion Middleware products such as ADF (11g and 12c) and OHS (11g and 12c). However, as public downloads for Java 7 are no longer available, there are only two options to download JDK 7.

One method (requires an Oracle account) is to use the Oracle Java Archive: http://www.oracle.com/technetwork/java/archive-139210.html

The second method involves downloading the JDK and JRE from My Oracle Support. The following steps will explain how you can download the latest JDK and JRE 7 from My Oracle Support:

  1. Log into https://support.oracle.com using your My Oracle Support account.
  2. Go to Patches & Updates
  3. Search for the following patches:
    1. JDK/JRE 7u79: 20418638
    2. JDK/JRE 7u80: 20418657
    3. Specify the OS platform of your server environment
    4. image
  4. Select the Patch number on the left side of the table
    1. image
  5. Click “Download”
    1. image
  6. Click the name of the zip file to download it.

Once the JDK and JRE are downloaded, you should be able to find both the JDK and the JRE for the particular OS you selected.

image