Updated on 8th November 2019
Well, after dealing with 3 different versions of Forms & Reports 12c with Weblogic 12c, I found that 99.9% of the configurations for deploying Oracle Forms and Reports remain the same across versions. Hence instead of posting new threads towards the configurations, I will try to amend this thread with new instructions if any. Thank you (reader)
A week back I posted the procedures tested at my end (I’m excusing myself with this statement because 12c total setup could be a painful experience and may NOT be successful for many, even after following line by line instructions) here
This time I am going to list few instructions those will help you to deploy your existing forms & reports based applications to newly built 12c environment. The ONE pleasant surprise I came across during the deployment was, if your forms and reports were built and compiled used 11g R2 (not sure about 11g R1), no need to recompile them once again for the 12c deployment.
So last time we finished the topic discussing how to install and configure the 12c database, Weblogic Server, forms & reports and stopped at accessing the Oracle Enterprise Manager for Weblogic server.
If you are familiar with Weblogic Server 10 & Forms and reports 11gR2, creating a classic domain was much simpler compared to 12c. OPMN configurations were automated & once the relevant paths were setup, you are almost ready to start using the infrastructure for applications. However 12c requires more efforts from one to establish the same.
I’ll start with Oracle HTTP Server (OHS instance) that we created during the base_domain configurations. OPMN is not anymore used by Oracle 12c, hence the OHS.
As I always said, I’m not a weblogic guru, just another enthusiast who wants to try out newer products as a part of learning. Most of the stuffs I suggest here are “as how I managed to get it working”. Hence, if you find anything ridiculous or non-standard, please let me know through the comment section.
As you may already aware, forms and reports applications are deployed using own PORTs, for example WLS_FORMS server uses the port 9001 & WLS_REPORTS uses 9002 (default installation). However while you want to deploy an application, the users should be accessing both through a common interface, especially when the reports are called from forms using Web.Show_Document method. An example how the reports are called from a form using the above said method is like following:
“/reports/rwservlet?” assumes the servlet is called from the current root, for example, if you started the forms applications using the default deployment URL, it would look like the below
and an attempt to call a report from one of the forms will generate an url like following
causing URL not found error because there are NO reports application deployments at http://rajesh-pc:9001/
The one possibility to address this would be by hardcoding the root part of the url, which I never tried. However, exposing the ports of your forms and reports application servers may not be a good idea. Here, OHS instance comes in picture.
All you need to do is to register the forms and reports applications with the OHS and once the OHS instance restarted, you can start calling both forms are reports through the common URL, for example like following
7777 is the default OHS instance port, which you can change to a free port according to your requirements. You may even use port 80 using OHS (I will not discuss about changing OHS port to 80, there are many decent posts already available all over internet)
Update: 5th June 2016
You may enable the IPV6 after the installation and configuration by removing the registry dword & restarting the box. Using Weblogic console, point “Admin Server”, “WLS_FORMS” & “WLS_REPORTS” servers listen address to the host name of the box you are running them from.
In addition to changing the listening address, edit the host file of your box (X:\Windows\System32\drivers\etc” and add an entry like below
192.168.1.10 mybox.mydomain.xyz mybox
IPV6 is becoming the standard now, however many of the Oracle products have serious issues handling the IPV6 stack & you may find reference towards inet4 references raised by java while checking the log files. So we will completely disable the IPV6 stack on our Windows 10 machine. Please read Microsoft documentations to understand what kind of troubles you may get subjected by disabling IPV6
regedit -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Create a new reg_dword (32Bit) “DisabledComponents”
and just enter “FF” in the hexadecimal value column. Restart the computer
Note#2: If you created a Windows service for node manager using the Weblogic provided install service script, stop all WLS servers and stop the node manager service and delete the service from an elevate command prompt. I came across multiple issues related to java while using the Windows service created using the scripts.
We will use NSSM once again to create the node manager service, using the start node manager script you will find under $DOMAIN_HOME\bin folder
I’ve observed that most of null java exceptions were eliminated by creating the node manager service this way.
Note#3: Now we will setup a proper username and password for nodemanager because if you want to start the OHS instance manually later, you need to supply password (for the 1st time)
Logon to Weblogic console @ http://localhost:7001/console
Lock & Edit the domain security values, please refer the image below for details
Provide a meaningful name for the node manager account and supply a password. I used the same password for the total 12c deployment, unless you are setting up a PRODUCTION instance, you may use the common password across the 12c instances for easy administration of objects when required. Shutdown the services (better)
Note#4: Once the node manager properties are changed, start the WLS admin server. Once a WLS classic domain is created, you MUST have a live database connectivity in order to start the WLS admin server. Hence make sure that before you will start the weblogic server, you can connect to the database that holds the repository information for the user domains. Start WLS_FORMS and WLS_REPORTS servers using the weblogic console to insure that the admin server can contact the node manager. The first instance of weblogic server start may take upto 8-10 minutes, so wait patiently
Note#5: Logon to Oracle Enterprise Manager console. If the servers are started properly, you will see “everything” green, else…
Note#6: Let us try to start the OHS instance for the 1st time, you can navigate to the OHS instance using the target navigation button, check the below image for more details
As I have already started my OHS instance I will see all details for the instance, please check the image below
If your OHS instance is not started yet, use the “Start up” button to start the instance. I had few failures, pointing towards JAVA while tried, most of them were related to the node manager, as described earlier by the beginning of this article.
Note#7: If you managed to start the OHS instance successfully, you have completed the 1st level of configurations for the application deployment. You can modify the listen address, port information etc using the OEM itself. Please check the below image for details. I will NOT try to get into the details of how to this time, though it is highly appealing, due to the fact that I need to stick to the topic (minimum once in a while)
Stop the OHS instance now. We need to tell the OHS instance, what exactly it is going to serve by modifying the configuration files. A bit of manual efforts are required as there are NO GUI provided by Oracle for such setups.
Move to your Oracle Home folder. I have installed Weblogic server in D:\Weblogic\Middleware folder, hence my Oracle home folder is
(Adjust your paths accordingly)
Edit forms.conf file in the folder D:\Weblogic\Middleware\Oracle_Home\forms\templates\config\
By default this template file comes with commented examples, like following
# SetHandler weblogic-handler
# WebLogicHost host
# WeblogicPort port
You need to uncomment one of the blocks starting from <Location /forms> until </Location> & add properties specific to your deployment, for example, my computer’s name is “RAJESH-PC” and I am using default ports for both forms and reports applications, hence I have the properties set like following
Once altered, copy forms.conf to OHS instance “moduleconf” folder. I have copied the file to following location: (Alter according to your setup)
Now we will edit the configuration file for reports
Switch to “D:\Weblogic\Middleware\Oracle_Home\reports\conf” folder & edit “reports_ohs.conf” and add a block like following (alter according to your setup)
Copy the edited file to
Now the OHS instance know about the deployments and once after restarted, you can try to start the forms based application through the OHS instance, rather than calling it against the default port (9001)
Once the OHS instance is updated with the new information, try to start the OHS instance from a command prompt using storeUserConfig parameter
D:\Weblogic\Middleware\Oracle_Home\user_projects\domains\base_domain\bin>startComponent.cmd ohs1 storeUserConfig
1st run, you will be prompted for node manager password, supply the password you have setup earlier and OHS instance should start without creating a fuzz in usual scenarios
In future if you want to start the OHS instance, unless made changes to the configurations, just run
Above concludes the 1st of level of configurations for Oracle forms based application. You can use Weblogic 12c Enterprise Manager to configure most of the forms environment related parameters like forms path and other, while I am yet to find out relevant configuration areas for reports. I’ve opened a thread with Oracle community inquiring the same and yet to receive any leads.
You can manually modify the formsweb.cfg & default.env files to start with as well
While forms based application hasn’t changed much (other than the OHS part), making the reports working for you could be really a painful experience.
Regardless whether you are going to use the in-process report server or a stand alone instance of the reports, many changes should be made to the configuration files, so that you can call the reports server from a Forms module
Generally we will be modifying n configuration files, I will try my level best to provide the exact locations for the files which you should change according to your installation preferences
Configuration files path
- rwservlet.properties – Servlet specific properties
- rwserver.conf – Server properties
- cgicmd.dat – key mapping file
1. As far you are using in-process reports server, nothing much to alter with “rwservlet.properties” file. Basically you should see entries like following in the opened file:
2. rwserver.conf (Please check the below image)
3. cgicmd.dat: Many values we supply to call a report using Web.Show_Document method could potentially expose vital information like the database details & many other. “cgicmd.dat” file helps us to map such values to keys and later use them wherever applicable. With this example, I will demonstrate, how the database username, password and service name are mapped using a key. Please check the image attached below
Once these configurations files are altered, please restart the WLS_REPORTS server using Weblogic admin console. You may optionally restart the WLS_FORMS server as well
Basically these many configuration should let you go online with your application. One of the pleasant stuffs about 12c forms and reports is, you don’t have to recompile the existing forms modules, just copy them to a new folder, update your formsweb.cfg and default.env files, restart the WLS_FORMS server and you are all set to go.
I’ve successfully configured a stand alone report server instance as well. I think I should separate it from this thread and post it as a fresh one to avoid confusions.
I been working from last few weeks to get these whole stuffs in a single place and cannot remember whether I’ve missed anything vital. If you get stuck anywhere, please let me know through the comment section and I will be more than glad to look into such.