In Reports Builder 11g, there is a known issue where copying and pasting items within any of the layout editors in Reports Builder causes Reports Builder to freeze or hang. This has been reported with Reports 11.1.1.6.0, 11.1.1.7.0, 11.1.2.1.0 and 11.1.2.2.0 with Windows 7 64-bit.

To resolve the issue, Oracle has provided a patch for download (NOTE: Access to My Oracle Support (Metalink) is required):

1. Download Patch 17301874 from Oracle Support (https://support.oracle.com). Make sure you specify the version of Forms and Reports you have installed.

2. Extract the patch in your PC or server.

3. Shut down all WebLogic servers and OPMN processes pertaining to your Forms environment.

image

4. Open up Command Prompt as an administrator.

5. Set the following environment variables:

set ORACLE_HOME=C:\Oracle\Middleware\as_1 (or C:\Oracle\Middleware\Oracle_FRHome1)

set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch

image

6. To ensure your OPatch version meets the prerequisites, run: opatch veresion

image

7. Navigate to where you extracted the Oracle patch and go into the 17301874 folder. Once there, install the patch by running: opatch apply

image

8. Ensuring that the Oracle Home mentioned matches the one for your Oracle Forms environment and everything in the Oracle Home is shutdown, type ‘y’ when asked if the system is ready for patching.

image

9. You will receive a success message when the patch is installed successfully.

10. Start up everything from the WebLogic servers to OPMN.

After applying the steps above, the problem should be fixed with Reports Builder.

Source: Oracle Support note 1395965.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 are many remote desktop applications available in the Internet. NoMachine is a great example of a remote desktop client which can be used to connect from a Windows, Mac, or Linux box to another Windows, Mac, or Linux machine which has NoMachine also installed. By default, the NX Agent will use port 7001 (the value of the DisplayBase set for NoMachine + 6000) running on localhost. As the agent is using port 7001, it can potentially cause a conflict with the AdminServer for any WebLogic environments using port 7001 primarily if using localhost to access the WebLogic Admin Console or anything WebLogic-related running on port 7001.

Error in starting the AdminServer using port 7001:

image

Port conflict exists due to NoMachine agent using port 7001 on localhost:

SNAGHTML6ceca1SNAGHTML6d7762

NOTE: Although the AdminServer starts up successfully, it is not possible to run anything with port 7001 for anything WebLogic-related using the localhost address (using your actual hostname instead of localhost works fine however):

image

To fix this problem, you can change the port which NoMachine uses for the NX Agent using these steps below:

NOTE: Admin privileges are required.

1. Go to the file directory where NoMachine is installed (in Windows, it should be C:\Program Files (x86)\NoMachine by default) and go into the etc folder.

2. Open the file server.cfg using a text editor (NOTE: Make a backup first!).

3. Locate the parameter DisplayBase (may be commented out initially). Set the number to a value which does not conflict with other running ports. In this example, I changed the DisplayBase to 2001 (DisplayBase + 6000 = the port number used for the NX Agent) so that the NX Agent uses port 8001, a port which nothing with WebLogic will use. NOTE: Make sure the value is NOT commented!

image

4. Save and close the file.

5. Open up the Windows Services and locate the service “NoMachine Display Monitor”. Restart the service so the port number changes from 7001 to the port number you set.

SNAGHTML7631db

6. Now that the service has been restarted, the agent will no longer be using port 7001. In order to associate localhost with your WebLogic AdminServer using port 7001 again, you will need to restart the AdminServer.

After applying the steps above, you should be able to use the localhost address with your WebLogic server environment running port 7001.

image

Source: https://www.nomachine.com/forums/topic/nxagent-is-listening-on-port-70017002

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

10g PITSS.CON Setup Prerequisites

1.     Minimum System Requirements

1.1.    Oracle Supported Forms Builder Platforms (Development Client):

1.1.1. Windows XP 32-bit SP3+

1.1.2. Windows Server 2003 32-bit R2+

1.1.3. Windows Server 2008 32-bit

1.1.4. Windows 7 32-bit

1.2.    Oracle Support Forms & Reports Services Platforms (Server):

1.2.1. Windows Server 2003 32-bit R2+

1.2.2. Windows Server 2008 32-bit R2+

1.2.3. Windows Server 2008 64-bt R2+

1.3.    RAM: 2 – 3 GB+(Depending on operating system support)

1.4.    Virtual Memory: 2-3GB+

1.5.    HDD Space: At least 30GB of free space for the installation directory/drive where you want 10g WebLogic and Forms Installed

1.6.    OS User Access Requirements:

1.6.1. The operating system user that is used for the installation must have Administrative privileges on the machine and “Full Access” to the file system directory where 11g WebLogic and Forms was installed.

1.6.2. The OS user admin account should be locally created on the PC/server.

1.6.3. IMPORTANT: This OS account used to install the Oracle software MUST be used to run the Oracle Services per the Oracle Forms Certification Matrix (it is best to use an account to which multiple system admins will have access) and PITSS.CON must also be installed as the same user who installed WebLogic and Forms.

2.     Software Requirements

2.1.    Java JDK 1.6.0_24

2.1.1. Go to http://java.sun.com/products/archive/j2se/6u24/index.html

2.1.2. Click “Java SE 6”

2.1.3. Click “Java SE Development Kit 6u24”

2.1.4. Click on “jdk-6u24-windows-i586.exe” for 32-bit and “jdk-6u24-windows-x64.exe” for 64-bit.

clip_image001[4]

2.2.    Database Requirements

A Database will be needed to store the PITSS.CON Repository. The database MUST be a locally installed database (in the same local-area network (LAN) as the application server).

2.2.1. Database 11g is recommended for 10g Forms, 10gR2 is the minimum acceptable version.

2.2.2. The database should NOT be the XE edition of Oracle Database.

2.2.3. We’ll need a database user with DBA privileges accessible (such as SYS).

2.2.4. The database will need CTXSYS user installed on the database (done through installing Oracle Text on the database) where the PITSS.CON Repository will run. To check if Oracle Text was installed, check to see if a CTXSYS user exists (without manually installing it).

2.2.5. A tablespace will need to be created for the PITSS Repository. It should be expandable  (auto-extend) with at least 3 GB of space. Please let PITSS know the name of the tablespace to use.

2.2.6. The database where the PITSS.CON Repository will be installed should be a development or test database. We do not recommend using a production database.

2.2.7. NOTE: After PITSS.CON is installed, the PITSS.CON repository should NOT be moved to a separate database or server using export/import or Data Pump. Please contact PITSS before moving PITSS.CON to a separate database or server.

 

 

2.3.    Application Modules

2.3.1. Please have all modules (forms, menus, libraries, and reports) ready for loading into PITSS.CON.

 

2.4.    PITSS.CON 12.3.1

2.4.1. Please contact PITSS at 248-740-0935 or support@pitssamerica.com for download instructions.

 

2.5.    Webutil, JACOB, and PITSS.CON Install Scripts

2.5.1. Please contact PITSS at 248-740-0935 or support@pitssamerica.com for download instructions.

 

If you have any questions on the above, please contact PITSS.

When performing a Forms upgrade, an analysis of your application, or modernizing your Forms to ADF using PITSS.CON, the application database objects are necessary when performing such tasks. In order to load them into the PITSS.CON repository, you will need to make sure your PITSS.CON user is assigned the application database schema containing the database objects you need.

Use these steps to set up your PITSS.CON environment for loading database objects:

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

image

2. Go to “User Access”.

image

3. Expand your group name to find your PITSS.CON user by clicking the “+” button next to the group name. In this example, the PITSS.CON user we want to load database objects into is in the group “USERS”.

image

4. Select the PITSS.CON user inside the group. In this example, we are selecting the PITSS1 user. Once this is done, you will notice that the Users table may fill in with different schemas. Once your PITSS.CON user is selected, click “Change Connect String” to update the connect string to your application database.

NOTE: If the PITSS.CON group the PITSS.CON user belongs to has any database objects already loaded, they will need to be removed from the PITSS.CON repository before continuing. Otherwise, you may encounter an error when selecting “Change Connect String”.

image

5. Enter the username, password, and connect string of your application database userid. In this example, we are using a user called “admin”. Click “Test Connect String” to save the connect string. NOTE: Make sure the application database userid you are entering has the “select on v_$database” grant given to it.

image

6. Click “OK” when asked if you want to save as the new working database.

image

7. The Application Connection field will be updated with the specified userid. In the Users table, you should see a list of all available schemas on the application database. For the schema you wish to assign the PITSS.CON user to, select the row with that schema and select the “Assign a PITSS.CON User” button. In this example, we are assigning the PITSS1 user to the WEBUTIL schema.

image

8. Select the PITSS.CON user you wish to assign to the schema and click OK.

image

9. You will see that the PITSS.CON user is assigned to the application schema. Repeat steps 7-8 for as many schemas as needed.

image

10. Log out of the MIG user and log into your PITSS.CON user.

image

11. Go to Administration –> Settings.

image

12. Scroll down to “Connection String to Application Database” and select it. You will need to provide the same application database connect string in these fields as you did in the MIG user. Click “Test Connect String” to save the changes.

image

13. If successful, you should see a message at the bottom saying, “The connection string is correct.”

image

14. Click the “Exit” button to return to the main menu. Go to Maintenance –> DB Handling.

image

15. Click “Load” to start the loading procedure for loading the database objects.

image

16. The “Select Database Objects” table will appear. All schemas assigned to your PITSS.CON user will appear here. For the schema objects you wish to load, please place a check mark next to each schema and specify a password for each schema. When ready, click “Load” again to load the database objects into PITSS.CON.

image

This will allow you to load database objects into PITSS.CON.

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)