After a server with WebLogic installed is restarted either normally or abnormally, there is a known issue where the managed WebLogic servers are unable to be started up using the Node Manager inside the WebLogic Administration Console. Errors produced are:

“For server MANAGED_SERVER_NAME, the Node Manager associated with machine MACHINE_NAME is not reachable.”

image

To solve this problem, please follow these steps below:

1. Make sure all managed WebLogic servers are shut down.

2. Shut down the AdminServer.

3. Stop the Node Manager. In Windows, this can be done by stopping the Windows service (if installed) or closing out of the Command Prompt window running startNodeManager.cmd.

4. In the file system, delete the following files for each managed server:

a. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.state

b. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.lck

c. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.pid

NOTE: If any of the above three files do not appear, that will be perfectly fine as that can happen sometimes.

5. Start up the Node Manager.

6. Start the Admin Server using either a startup script or WLST.

 

After applying the steps above, you should be able to start the managed servers from the Admin Console.

Source: Oracle Support note 1293552.1

By default, when Oracle WebLogic Server uses HTTPS for secure connections such as for Forms and Reports, SSL (Secure Socket Layer) v3.0 and TLS (Transport Layer Security) v1.0 are configured. SSL is the original protocol used for secure connections via HTTPS where TLS is the newer, more secure protocol. In recent months, a security vulnerability known as Poodle, “Paddling Oracle On Downgraded Legacy Encryption”, was discovered to be. In summary, Poodle is a “man-in-the-middle” exploit which can allow hackers to view encrypted information. More information on Poodle can be found on Oracle’s website: http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

The vulnerability exists with SSL v3.0, which is commonly used as the secure protocol used for HTTPS connections with using Oracle WebLogic Server. However, the TLS protocol does not contain this vulnerability. If WebLogic is configured for both (it is by default) and the end-user’s Web browser has SSL v3.0 and TLS v1.0 both enabled, there is a possibility that the WebLogic connection via HTTPS may be done using SSL v3.0 instead of TLS v1.0. A WebLogic connection is defined by any connection going to an application (JSP, Forms & Reports, ADF, Discoverer, etc.) which is deployed in Oracle WebLogic Server.

The best approach is to configure WebLogic to only use TLS v1.0. With this, all end-users will be forced to use TLS 1.0 on all HTTPS connections to the WebLogic server whether it is used for running deployed JSP applications, Oracle Forms and Reports applications, Oracle ADF applications, or other Oracle Fusion Middleware applications. The changes are quick and easy to deploy. Also, no new SSL/TLS certificates will need to be created. Implementing TLS v1.0 only for WebLogic can be done with these steps:

1. Log into the WebLogic Administration Console (Example: http://server.domain:7001/console)

2. Log in with the weblogic username and password

3. Go to Environment –> Servers

image

4. Select a WebLogic server where SSL has been set up. We’ll use WLS_FORMS as an example.

image

5. In the top-left corner, click “Lock & Edit”.

image

6. Make sure the Configuration tab is enabled. Select the “Server Start” sub-tab.

image

7. In the Arguments section, type in the following parameter:

-Dweblogic.security.SSL.protocolVersion=TLS1

NOTE: This will force the WebLogic server to use TLS instead of SSL.

When finished, click the “Save” button.

image

8. For any other WebLogic servers using SSL/TLS, repeat steps 4-7 (except for step 5 as you will be in “Lock & Edit” mode already).

9. In the top-left corner, click “Activate Changes” to apply all changes.

image

10. If any WebLogic servers which had the changes applied are currently running, they will need to be restarted using the Admin Console. If this includes the AdminServer, you will need to use WLST to start up the AdminServer as you will not be able to use the Admin Console if the AdminServer is down.

Now that WebLogic is configured for TLS v1.0, all end users will need to make sure that TLS 1.0 is enabled in their Web browsers:Internet Explorer:NOTE: It is likely that TLS 1.0 is enabled in Internet Explorer, but it is recommended to check anyway.Go to Tools –> Internet Options (or simply Internet Options from the menu in the top-right corner)In the Advanced tab, scroll down to the Security section. Make sure “Use TLS 1.0” is enabled.

SNAGHTMLaf2c8f

Mozilla Firefox and Google Chrome:All current releases of Firefox and Chrome have at least TLS 1.0 already enabled.After applying the steps above, you should be using TLS when running anything on the WebLogic server (JSP applications, ADF applications, Forms, etc.) using the HTTPS protocol.

Source: Oracle Support note 1936300.1

By default, when Oracle HTTP Server (OHS) 11g uses HTTPS for secure connections such as for Forms and Reports, SSL (Secure Socket Layer) v3.0 and TLS (Transport Layer Security) v1.0 are configured. SSL is the original protocol used for secure connections via HTTPS where TLS is the newer, more secure protocol. In recent months, a security vulnerability known as Poodle, “Paddling Oracle On Downgraded Legacy Encryption”, was discovered to be. In summary, Poodle is a “man-in-the-middle” exploit which can allow hackers to view encrypted information. More information on Poodle can be found on Oracle’s website: http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

The vulnerability exists with SSL v3.0, which is commonly used as the secure protocol used for HTTPS connections with using OHS. However, the TLS protocol does not contain this vulnerability. If OHS is configured for both (it is by default) and the end-user’s Web browser has SSL v3.0 and TLS v1.0 both enabled, there is a possibility that the OHS connection via HTTPS may be done using SSL v3.0 instead of TLS v1.0.

The best approach is to configure OHS to only use TLS v1.0. With this, all end-users will be forced to use TLS 1.0 on all HTTPS connections to that OHS environment whether it is used for running deployed Web applications, Oracle Forms and Reports applications (whether using the embedded OHS server which comes with Oracle Forms and Reports or using a WebGate for organizations using OAM for SSO), Oracle Discoverer, or other Oracle Fusion Middleware applications. The changes are quick and easy to deploy requiring minimal downtime (only minutes). Also, no new SSL/TLS certificates will need to be created. Implementing TLS v1.0 only for OHS 11g can be done with these steps:

1. Go to %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix environments)

2. Make a backup of ssl.conf

SNAGHTMLa8ef22

3. Open up ssl.conf in a text editor

4. Locate the SSLProtocol parameter. Notice that it reads: SSLProtocol nzos_Version_1_0 nzos_Version_3_0

image

5. Comment out this line and add the following entry in the next line below:

SSLProtocol nzos_Version_1_0

NOTE: This is the parameter to specify only TLS v1.0

image

6. Save and close the file

7. Restart OHS using either OPMN or Enterprise Manager

Examples:

Windows: %ORACLE_INSTANCE%\bin\opmnctl restartproc ias-component=ohs1

Unix: $ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs1

Now that the OHS server is configured for TLS v1.0, all end users will need to make sure that TLS 1.0 is enabled in their Web browsers:

Internet Explorer:

NOTE: It is likely that TLS 1.0 is enabled in Internet Explorer, but it is recommended to check anyway.

Go to Tools –> Internet Options (or simply Internet Options from the menu in the top-right corner)

In the Advanced tab, scroll down to the Security section. Make sure “Use TLS 1.0” is enabled.

SNAGHTMLaf2c8f

Mozilla Firefox and Google Chrome:

All current releases of Firefox and Chrome have at least TLS 1.0 already enabled.

 

After applying the steps above, you should be using TLS when running anything on the OHS server (Web pages, Forms, etc.) using the HTTPS protocol.

NOTE: OHS 11g (e.g. 11.1.1.7.0) is currently only supported to use TLS 1.0. Only OHS 12c (12.1.x) can use TLS 1.1 or higher which is currently not usable for Oracle Forms and Reports 11gR2.

Source: Oracle Support note 1936300.1

There have been known issues where if you plan to run Oracle Forms using OHS with SSL/TLS (using the HTTPS protocol) and the OHS HTTP port (8888 by default) is disabled in httpd.conf, connections to the Forms application drop after a small period of time. The error which end users receive is:

FRM-92103: A network error or server failure has occurred. You will need to restart your application.

image

Look in the ohs1.log located in %ORACLE_INSTANCE%\diagnostics\logs\OHS\ohs1. If you see the following errors inside the log file:

[timestamp] [OHS] [ERROR:32] [OHS-2079] [core.c] [host_id: hostname] [host_addr: ip_address] [pid: ###] [tid: ###] [user: USER] [VirtualHost: hostname.domain:8890]  nzos handshake error, nzos_Handshake returned 29039(server hostname.domain:8890, client ::1)

[timestamp] [OHS] [ERROR:32] [OHS-2171] [core.c] [host_id: hostname] [host_addr: ip_address] [pid: ###] [tid: ###] [user: USER] [VirtualHost: hostname.domain:8890]  NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]

OHS may need to be enabled at least at the loopback address level. If your organization has requirements where the OHS HTTP port has to be disabled for incoming and outgoing connections, configuring it to run only at the loopback level will still satisfy this requirement. To configure this, you will need to follow these steps:

1. Go to %ORACLE_INSTANCE%\config\OHS\ohs1 ($ORACLE_INSTANCE/config/OHS/ohs1 in Unix) and open up httpd.conf in a text editor (make a backup first).

2. Look for the commented “#Listen 8888” parameter. Uncomment the parameter and specify the loopback address:

Listen 127.0.0.1:8888

image

3. Save and close the file.

4. Restart OHS either from OPMN or Enterprise Manager.

After applying the steps above, the FRM-92103 errors should disappear when running Forms with the OHS HTTPS port.

Source: Oracle Support note 1471204.1

Starting with Oracle Forms and Reports 11.1.2.2.0, the latest version of Oracle Forms available, support with Java Runtime 8 update 5 or higher has been added per the Oracle Forms 11.1.2.2.0 certification matrix (More information can be found in the Client tab in the certification matrix) http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen.

However, if your Forms application is using SSL (https), you may encounter the following error in your Java Console:

network: Connecting https://server.domain/forms/java/icons.jar with proxy=DIRECT

javax.net.ssl.SSLException: Received fatal alert: close_notify

network: Connecting http://server.domain:443/ with proxy=DIRECT

                at sun.security.ssl.Alerts.getSSLException(Unknown Source)

                at sun.security.ssl.Alerts.getSSLException(Unknown Source)

The Forms application will no longer work. According to the “Security Enhancements” page in the JRE 8 documentation http://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html, the TLS 1.1 and TLS 1.2 options were enabled in the Java Control Panel found on every client PC which connects to the Oracle Forms application. Previously in JRE 6 and 7, these options were either disabled or not present; however, it was enabled in JRE 8.

To fix the problem, in the client PC, you will need to perform these steps:

1. Open up the Java Control Panel (can be found in the Windows Control Panel under “All Control Panel Items”.

2. Click the “Advanced” tab and expand the “General” section.

3. You will see that “Use TLS 1.1” and “Use TLS 1.2” are selected. Unselect both checkboxes and click “OK”.

4. Close out of all browser windows and relaunch the application.

 

After completing the steps above, you should be able to run your Forms application using JRE 8.

Source: Oracle Support note 1675195.1

If you are attempting to load forms or reports into PITSS.CON, and you are unable to load any form or report into PITSS.CON (including ones already been loaded into the PITSS.CON repository) due to the following errors:

Forms:

“Insert code for [TRIGGER or PROGRAM UNIT] – ORA-29875: failed in the execution of the ODCIINDEXINSERT routineORA-”

image

Reports:

No errors in the “Error List” window, but the error “ORA-06502: PL/SQL: numeric or value error” appears in the bottom status bar.

image

 

The indexes for the PITSS.CON user you are using will need to be re-indexed. The MIG user can do this within PITSS.CON:

NOTE: Please disconnect (log out of) all logins of the PITSS.CON user you are using whether it be in PITSS.CON or in any database program such as SQL*Plus, SQL Developer, or Toad before completing the steps below.

1. Log into PITSS.CON with the MIG user.

2. Go to “User Administration”.

image

3. Expand the group the PITSS.CON user belongs to and select your PITSS.CON user. After that, click the “Add User to Task” button.

image

4. Select the check boxes “Compile Invalid Objects” and “Rebuild Indexes”. After both of them are selected, click “Run Task”.

image

5. Please wait until the task is completed. When finished, you will see a status in the status bar at the bottom saying, “Done.”

image

6. Log out of the MIG user and back into your PITSS.CON user.

 

After completing the steps above, you should be able to resume loading your Forms and Reports modules into PITSS.CON.

Self-signing jar files to use for Oracle Forms have been a way to sign jar files without using a trusted vendor. Oracle has provided the sign_webutil.bat (or sign_webutil.sh) script to use for self-signing a jar file. As the self-signed certificates do not contain a trusted publisher name, any time a Forms application starts up, you may notice a Java security warning with a publisher “UNKNOWN”. This is because the self-signed certificate is not generated from a trusted vendor (VeriSign, Comodo, GoDaddy, etc.) and is not in the “Signer CA” list in the Java Control Panel on a user’s PC. This has been noticed more in recent months as users are unable to “always remember this option” when choosing to run an application with an UNKNOWN publisher starting with Java 7 Update 40 (or even getting an Application Blocked error when using JRE 7u51 or higher).

The best solution would be to sign your jar files with trusted code-signing certificates from a trusted vendor. However, you also have the option to add the self-signed certificate to your Java Control Panel to the list of Signer CA certificates which will add the self-signed certificate to the trusted list allowing you to run the application without the warning appearing (however, a Java notification will still appear with a publisher name that would be considered more trustworthy than “UNKNOWN”).

To configure this, you will need to update the sign_webutil script (used for self-signing jar files) in the platform running the Forms and Reports environment. After this, you will need to export a CSR certificate from the keystore which the script uses. The following steps will accomplish this:

1. Locate your sign_webutil.bat or sign_webutil.sh script. If you are using one provide by PITSS, it should be located in either %ORACLE_HOME%\forms\webutil\win32 or %ORACLE_HOME%\forms\webutil\win64. If you are, you may skip step 3 as the password will be “webutilpasswd” . If it does not exist here, you can find it in %ORACLE_INSTANCE%\bin. Please make a backup of this file.

2. Open the file in a text editor.

3. Modify the following variables:

a. SET KEYSTORE_PASSWORD= Create a keystore password of your choice (CAUTION: The password will NOT be encrypted)

b. SET JAR_KEY_PASSWORD= Create a private key password of your choice (CAUTION: The password will NOT be encrypted)

4. Locate the line “SET DN_CN=Product Management”. This is the self-signed certificate information. If you want to use your own information, you may update the following four lines (below is an example). If you are fine with using the values Oracle has provided, you may skip to step 5.

a. SET DN_CN=Forms Self-Signed Certificate (Common Name or name of the certificate)

b. SET DN_OU=Oracle Forms (Organization Unit)

c. SET DN_O=PITSS America LLC (Organization)

d. SET DN_C=US (Country code such as US for United States, CA for Canada, etc.)

5. Save and close the file

6. Re-sign your jar file(s) with the sign_webutil script:

Windows: %PATH_TO_SCRIPT%\sign_webutil.bat %PATH_TO_JAR_FILE%\jarfile.jar

Unix: $PATH_TO_SCRIPT/sign_webutil.sh $PATH_TO_JAR_FILE/jarfile.jar

7. Deploy the signed jar file in %ORACLE_HOME%\formsjava

8. Restart WLS_FORMS if it is running

9. Go to the location of your keystore file that is specified in the sign_webutil script inside Command Prompt or your SSH terminal.

10. Ensuring that the JDK is in the PATH environment variable run the following command to extract a CSR from the keystore:

keytool -export -keystore .keystore -alias webutil2 -file name_of_cert.csr

11. Please keep the CSR file handy. This file will need to be sent to any end user who plans to use the application.

12. In the end-user’s PC, open up the Java Control Panel from Control Panel. This can be done by clicking on Control Panel from the Start button. Once there, expand the Control Panel and select “All Control Panel Items”. Double-click on Java.

13. Go to the Security tab and click “Manage Certificates…”.

SNAGHTMLf94c50

14. Specify “Signer CA” as the Certificate type. Click “Import” to import the CSR.

15. Once it is imported, it will be in your list of trusted certificates for that PC.

SNAGHTMLfa3518

After applying the steps above, you should see a more trustworthy Java notification similar to the one below instead of a security warning which will allow you to remember the option to run the application (even when using the latest JRE):

image

NOTE 1: Steps 1-10 only need to be done once in the PC/server where Forms is installed. Steps 11-15 will need to be done for every user who plans to access the application.

NOTE 2: Make sure your jar files also contain the permissions, codebase, and Application-Name manifest attributes or the jar files may be blocked starting with Java 7 Update 51. For more information, please review https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/.

NOTE 3: The Oracle jar files (they start with “frm”) are signed with Oracle’s trusted certificates. Do not attempt to modify or replace them as it will cause the Forms environment to not run correctly if at all.

Source: Oracle Support note 1596871.1

Normally in Enterprise Manager for Forms, you are able to associate and disassociate your Oracle Forms environment to/from OID. However, if OID is no longer there like in a situation where OID was deinstalled, you will be presented with the following error when you try to disassociate Forms from the old OID environment (such as if you are trying to associate Forms with the new environment):

“FRM-60205: error removing the Forms J2EE application formsappf9c-9652-30540462a11e footprint from OID host”

You can disassociate the old OID environment from Forms by performing these steps:

1. Shutdown all WebLogic servers in the Forms domain.

2. Navigate to the DOMAIN_HOME of your Forms domain.

3. You will need to edit the file FormsOIDConfig.xml in two locations. Make backups of these files:

a. $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config/FormsOIDConfig.xml

b. $DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2/<random_string>/config/FormsOIDConfig.xml

4. Open the file in each location using a text editor.

5. Remove all entries in the file until you have the following:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>
<!DOCTYPE properties SYSTEM “http://java.sun.com/dtd/properties.dtd”>
<properties>
</properties>

6. Save and close the file.

7. Repeat steps 4-6 for the other file. NOTE: For the second location, it may already appear as it should in step 5.

8. Start up the WebLogic environment for Forms.

9. In EM, the old OID environment should no longer appear. You may proceed with associating Forms with a new OID environment.

 

Source: Oracle Support note 1130053.1

When running the Oracle Forms 11gR2 (11.1.2.2.0) Patchset Upgrade to upgrade an older version of Oracle Forms 11gR2 (11.1.2.0.0 or 11.1.2.1.0) in Windows, there is a random possibility that the following error may be encountered about halfway through the upgrade:

“Error in writing to file ‘%ORACLE_HOME%\bin\oraldapclnt11.dll’. [%ORACLE_HOME%\bin\oraldapclnt11.dll (The process cannot access the file because it is being used by another process)]”

Forms upgrade error with DB

Per the error message, the oraldapclnt11.dll is being used by another process. Before clicking “Retry”, make sure that:

1. Your WebLogic servers for the Forms and Reports environment are shut down.

2. OPMN is shut down for the Forms and Reports environment.

3. The Node Manager is shut down for the Forms and Reports environment.

4. If an Oracle Database is locally installed (meaning on the same PC/server where Forms and Reports is being upgraded), it should be shut down as well (the DB instance, the TNS listener, the DB console, etc.).

5. If any Oracle Enterprise Manager Grid/Cloud Control Agents are deployed on the PC/server, they should be shut down as well.

 

If you click “Retry” and the error still appears, apply these steps to fix the problem:

1. Make a backup of the entire Middleware home. You can do this by zipping up the entire Middleware directory.

2. Go into %ORACLE_HOME%\bin.

3. Rename the file “oraldapclnt11.dll” as “oraldapclnt11.dll.bak”.

4. Click “Retry”. The error should not appear again. The upgrade will create a fresh copy of the DLL.

NOTE: You may experience the same error with the following DLLs where you may need to apply the same steps as above (except for the Middleware backup as that would have been done already):

  • orannzsbb11.dll
  • orazt11.dll
  • oraztkg11.dll

In order to run your Oracle Forms application utilizing the WebUtil functionality, the Forms and Reports environment must be properly set up:

1. You must use the webutil.olb and webutil.pll that came with the Forms install. You should NOT copy any versions from other platforms. For example, if you are deploying your application in Linux after developing some forms in Windows, you should not copy any WebUtil library from Windows to Linux (or vice-versa). Basically, make sure the webutil.pll you compiled is one that came with the Forms installation. Otherwise, you may encounter strange issues such as FRM-40735/ORA-06502 or ORA-06508.

2. Make sure that the WebUtil libraries (olb, pll, and plx) are not in more than one location in the FORMS_PATH.

3. Inside formsweb.cfg in each application section(s), it/they will need to at least have:

baseHTMLjpi=webutiljpi.htm
baseHTML=webutilbase.htm
WebUtilArchive=frmwebutil.jar, jacob.jar
WebUtilLogging=off
WebUtilLoggingDetail=normal
WebUtilErrorMode=Alert
WebUtilDispatchMonitorInterval=5
WebUtilTrustInternal=true
WebUtilMaxTransferSize=16384

4. In $ORACLE_HOME/forms/webutil/win32, the file jacob-1.14.3-x86.dll needs to be present

5. In $ORACLE_HOME/forms/webutil/win64, the file jacob-1.14.3-x64.dll needs to be present

6. In $ORACLE_HOME/forms/java, jacob.jar must be present there. If you are using Java Runtime Environment (JRE) 7u51 or higher, it will need to be signed with trusted code-signing certificates or your application may get blocked when running in the web browser.

7. Make sure that a public synonym WEBUTIL_DB has been created in your Oracle Database and is granted on execute to public (GRANT EXECUTE ON WEBUTIL_DB TO PUBLIC;)

8. Make sure in $ORACLE_INSTANCE/config/FormsComponent/forms/server/webutil.cfg that the following parameters are set to what they are below (these parameters are found close to the very bottom of the file):

transfer.database.enabled=TRUE
transfer.appsrv.enabled=TRUE
transfer.appsrv.workAreaRoot=
transfer.appsrv.accessControl=FALSE

That should be everything that is required in the environment for WebUtil to work in Forms.

Source: Oracle Support note 1093985.1 (How to Configure Webutil in Forms 11g)