Starting with Oracle Forms 12c, it is required to install RCU schemas into an Oracle Database. Without the RCU schemas, it will not be possible to start up the WebLogic servers. It is advised to have the RCU schemas configured to have the passwords to not expire, but if this is not possible due to security restrictions, you will need to remember to reset the password to what was configured when the schemas were installed. The RCU schemas are (the <PREFIX> is the prefix specified during the installation which goes in front of the schemas):

  • <PREFIX>_OPSS
  • <PREFIX>_STB
  • <PREFIX>_IAU
  • <PREFIX>_IAU_APPEND
  • <PREFIX>_IAU_VIEWER

In the event that the above five schemas especially <PREFIX>_OPSS expires, if the Admin Server is started up, it will fail to start due to the error, “ORA-28001: password has expired”. If you reset the password for the five schemas to what was configured previously, the WebLogic server will start up normally.

However, if you either are required to change the password to something different or if you cannot remember the password which was used, you will need to follow these steps to change the RCU password and have the WebLogic domain recognize the new password:

  1. Set the new password for the RCU schemas mentioned above. Make sure the accounts are also unlocked. If the accounts are locked for any reason, you may need to contact a DBA to unlock the users.
    1. Example: alter user FORMS_OPSS identified by <new_password>;
  2. When the five schemas’ passwords are updated, you must run a commit to apply the changes: commit;
  3. The Admin Server will need to be started up. However, we will need to start it up in a different way to avoid it from crashing upon startup. Go to $ORACLE_HOME/oracle_common/common/bin and run wlst.sh (or wlst.cmd in Windows)
  4. In WLST, run the following (you must use forward slashes ‘/’ even for Windows): modifyBootStrapCredential(jpsConfigFile=’/u01/oracle/middleware/user_projects/domains/FormsDomain/config/fmwconfig/jps-config.xml’,username='<PREFIX>_OPSS’,password='<NEW_PASSWORD>’)
    1. NOTE: Your path to jps-config.xml within $DOMAIN_HOME/config/fmwconfig may be different than the example above. Please specify the full path without using environment variables.
  5. Exit WLST: exit()
  6. Start the Admin Server. Although you will still encounter errors regarding the data source, the Admin Server will start up.
  7. Log into the Admin Console.
  8. In the top-left corner of the Admin Console, click “Lock & Edit“.
  9. In the Domain Structure in the left frame of the Admin Console, go to Services –> Data Sources.
  10. Click on the first of four (assuming you have not configured additional data sources beyond the four which come with Forms 12c) data sources.
  11. Go to the Configuration tab and then the Connection Pool subtab.
  12. Type in the new schema password in the Password and Confirm Password fields.
  13. Click Save.
  14. Repeat steps 9-13 for the remaining three data sources.
  15. In the top-left corner of the Admin Console, click “Activate Changes“.
  16. In the top-left corner of the Admin Console, click “View changes and restarts“.
  17. Click the Restart Checklist tab.
  18. Place check marks next to all four data sources, and click “Restart“.
  19. On the confirmation page, click “Yes“.
  20. The data sources will restart. They should be functional again in a few seconds.

After completing the steps above, you should be able to start up the remaining WebLogic servers as well as restart the Admin Server without encountering the errors again.

Source: Oracle Support Document ID 1682942.1

There is a known bug in Oracle Forms 12c that the DATETIME item in Forms is set to a different time than what is configured in the Windows or UNIX server. Oracle Support has reported this issue in AIX, but it has been seen in both Windows and Linux as well. The easiest way to work around this bug is to configure the following environment variable to GMT in your env file (e.g. default.env):

FORMS_DATETIME_LOCAL_TZ=GMT

NOTE: Normally when you do not set this variable, the system defaults to GMT, but this is necessary in 12c.

This should correct the time issues, but if for any reason any datetime fields are out of sync still, you may also need to set the following variable to GMT:

FORMS_DATETIME_SERVER_TZ=GMT

Source: Oracle Support document ID 2139346.1

There is a bug in Forms 12c where the Forms application crashes with FRM-93652 errors when calling any forms where data from a record group is populated. Oracle has created a patch to fix this problem. These steps should be followed to fix this problem:

NOTE: This problem is currently only seen in Unix environments (Linux, Solaris, AIX, etc.). It has not been reported in Windows.

  1. Download Oracle Patch 21534616 from My Oracle Support. Make sure to download the version for your server’s OS. NOTE: The patch is technically an Oracle Database patch, version 11.2.0.3.0, but this will be used to patch the DB client which comes with the Forms 12c installation.
  2. Extract the patch in your server. Once it is extracted, navigate into the 21534616 folder.
  3. Make sure the following environment variables are set (this assumes the Oracle home is installed in /oracle/middleware/as_1 but it may be different for your environment)
    1. export ORACLE_HOME=/oracle/middleware/as_1
    2. export PATH=/oracle/middleware/as_1/bin:$PATH:/oracle/middleware/as_1/OPatch
  4. Run opatch prereq CheckConflictAgainstOHWithDetail -ph ./ to make sure there are no conflicts or errors. FRM-93652 1                      FRM-93652 2
  5. Shut down all instances inside the Forms 12c domain (all WebLogic servers, OHS, the standalone reports server, and Node Manager).
  6. Run opatch apply to install the patch.                                                                                                                                                                                   FRM-93652 3
  7. Make sure the Middleware Home is the Oracle Home for Forms 12c. If it is, type y to proceed.                 FRM-93652 4
  8. When it asks if the local system is ready for patching, type y and press Enter.                                            FRM-93652 5
  9. You should receive a message that the patch was successfully applied. There will be some warnings, but you may ignore these warnings.
    1. FRM-93652 6
  10. Go to $ORACLE_HOME/forms/lib and run: make -f ins_forms.mk frmweb_install                                                     FRM-93652 7
  11. If you see the output shown in the following screenshot, the step was run successfully.                         FRM-93652 8
  12. Start up your Forms 12c environment.
  13. Recompile all forms, menus, and libraries.

After applying the steps above, you should no longer encounter FRM-93652 errors when opening up any 12c forms where data from a record group is populated.

NOTE: There is a possibility that you may encounter the error FRM-41337 in the same forms. If you do, you will need to apply another Oracle patch as indicated in https://pitss.com/us/2016/05/06/frm-41337-appears/.

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.

GraphViz is a great third-party tool which can be used to generate graphs. By default, if you generate a graph from PITSS.CON (such as from the “Generate Forms Flow as DOT file” button in ADF Assistant) as a DOT file, it will create the DOT file code in the PITSS.CON Editor:

image

The code can be then copied into GraphViz and a graph can be generated.

However, you can configure PITSS.CON to automatically create a graph for you upon request. You can configure this with the steps below:

Prerequisites:

1. PITSS.CON must be installed and configured

2. GraphViz must be downloaded from http://graphviz.org (be sure to accept the license agreement before downloading and installing the product) and installed in the machine where PITSS.CON is installed.

Setup:

1. If PITSS.CON is currently open, please log out of PITSS.CON.

2. Open up pitsscon.env (or the env file associated with your PITSS.CON user)

3. In the PATH environment variable, add the following entry to the end of the PATH:

;C:\PROGRA~2\Graphviz2.38\bin (NOTE: The path may be different if you installed GraphViz in a different location)

SNAGHTMLe4ef71

4. Save and close the file.

5. Repeat steps 2-4 for any other PITSS.CON-related env files.

After applying the steps above, if you attempt to generate a graph from modules such as ADF Assistant or Systems Analysis (inside Application Engineering), a graph will automatically be created in a separate tab or window (depending on your Web browser configuration).

image

This will also prevent end users from having to install GraphViz on their local machines as it will be used from the installation on the server.

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.

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)

There are times where if PITSS.CON crashes when modules are being loaded, the following error will appear when you try to start loading modules again:

image

You can do the following to fix the problem:

  1. Go to Administration –> Batch Jobs
    • image
  2. In the Batch Jobs menu, you will see “Load Forms” on the left side of the window. As you can see, it is not a “green light”. Right-click on “Load Forms”.
    • image
  3. Click on “Reset Batch Procedure”
  4. The traffic light symbol next to “Load Forms” should be green again.
    • image
  5. Try loading a module again.

Modules should load successfully now.

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

To protect end-users from the latest security threats, Oracle has improved security in Java. Starting with Java Runtime 7 Update 25, you may have noticed the following warnings in the Java Console for jar files such as frmall.jar or any custom-made jar files:

  • Missing Permissions manifest attribute for: http://server.domain:port/forms/java/name_of_jar.jar
  • Missing Codebase manifest attribute for: http://server.domain:port/forms/java/name_of_jar.jar

image

At this time (with using the latest JRE available), these warnings will not cause any problems running any Oracle Forms application. These warnings appear due to how the Forms application jar files are set up. By default, the jar files deployed by every Oracle Forms application such as frmall.jar will present these warnings.

How to Remove the warnings for the Oracle Forms jar files such as frmall.jar, etc.

Oracle Patch 16837591 is able to correct this problem as it will apply the necessary updates to the Oracle Forms jar files supplied by Oracle to prevent this warning from appearing. This patch can be downloaded from My Oracle Support. The patch is available for any Oracle-supported operating system.

Once the patch is downloaded and extracted, you may install it by completing these steps:

  1. Shut down all WebLogic servers and instances running in the Forms domain.
  2. Open up Command Prompt (if using Windows) or an SSH client (if using Unix) and change the directory to the directory where you extracted the patch.
  3. cd 16837591
  4. Set the ORACLE_HOME and PATH environment variables similar to how it is done below (NOTE: The actual values of ORACLE_HOME and PATH may differ depending on how your environment is set up):
    1. Windows
      1. set ORACLE_HOME=C:\Oracle\Middleware\Oracle_FRHome1
      2. set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch
    2. Unix
      1. export ORACLE_HOME=/oracle/middleware/Oracle_FRHome1
      2. export PATH=$PATH:/oracle/middleware/oracle_common/OPatch
      3. image
  5. Run: opatch version (to make sure you are using an OPatch version level that is supported by the README file which comes with the patch).
    1. image
  6. Run: opatch apply
    1. image
  7. When it asks if the system is ready for patching, type: y
    1. image
  8. Once complete, you may start up the WebLogic servers and OPMN instances in the Oracle home.

              image

After completing the steps above, the warnings should no longer appear for any of the Oracle-supplied jar files:

image

NOTE: All end-users will be re-presented with this warning. As the frmall.jar file is from Oracle, you may run this and click the option to trust the publisher.

image

NOTE (Modified October 24, 2013): We have also created a knowledge base article specifying how you may update custom jar files with these parameters: https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/

NOTE: Be sure to review the README file included with an Oracle patch before applying it. PITSS will not be held responsible for anything that happens when running any Oracle patch. Also, never make any changes or updates to any Oracle-supplied jar files (jar files which start with “frm”) without consent by Oracle (outside of this patch). Failure to do so may require a reinstallation of Oracle Forms and Reports.

NOTE: This Oracle patch is only supported with Forms 11.1.1.6.0, 11.1.1.7.0, 11.1.2.0.0, and 11.1.2.1.0. If you are using an older Forms version, it is recommended to upgrade to one of these four versions before applying this patch.

Source: Oracle Support note 1563023.1.