For moving from a Test Environment to Production Environment, follow the steps given in chapter Moving from a Test Environment to a Production Environment available at Oracle Fusion Middleware Administering Oracle Fusion Middleware guide.
There are two case:
Test to Production full
Test to Production incremental
Table 8-1 Test to Production Use Cases
Use Case ID | Synopsis | Pre-Condition/ Description | Detailed Procedure | Post Condition |
---|---|---|---|---|
Administrator creates a complete REPORTS domain in the test environment with the required REPORTS and back-end components. After testing the applications, would like to replicate the entire setup to a production environment |
In Test environment, the user has done the following: Installed WLS Installed Forms and Reports Installation Run the WLS config wizard and created reports domain Configured / tuned the reports component instances, wired to different DB etc. Reports doesnt have a schema but WLS 12c installation requires a RCU schema to be created. Production environment Use T2P scripts to duplicate the bits copyBinary / pasteBinary. Copy domain config using copyConfig / extractMovePlan / pasteConfig.
|
See below |
The production environment has all the changes in test environment and is working fine |
|
Administrator has a working production REPORTS setup and would like to test changes in their applications/configuration before rolling them into the production network |
Production environment exists Test environment has some patches / config changes that needs to be rolled into the production environment. |
See below |
The production environment has all the incremental changes and is working fine |
For the above cases please find in below tables what is automatically migrated and manual steps needed where required.
Some steps are marked [Optional] and they are applicable only when the relevant functionality is used, for example, Reports plug-ins. In the production environment do the following:
Note that artifacts in domain home are automatically migrated by pasteConfig script. But if user has artifacts outside domain home (for example, used fonts somewhere else in file system) they should be manually migrated
Table 8-2 Test to Production Full
S.No | Test- Production Migration Areas | Automatic/ Manual | Comments/ Steps |
---|---|---|---|
1 |
Reports Component instances created |
Automatic |
Automatically migrated. Reports Server/Tools/Bridge component instances |
2 |
Reports Configuration |
Automatic |
Automatically migrated. Reports Server/Tools/Bridge / J2EE App config. See Publishing Reports to Web chapter "Configuring Oracle Reports Services" |
3 |
Reports related resources setup |
Automatic |
Automatically migrated. Fonts / Printer Config /CUPS printer config Fonts: Copy any fonts used in test environment from directory specified by environment variable |
4 |
Reports definition files and data tables |
Manual |
- Copy the reports files (RDF, JSP, REP, XML etc) used in test environment to production environment. - For JSP Web Reports, deploy those JSP reports in production environment reports managed servers in location
- Migrate Reports specific data tables referred in RDF files to the DB of production environment using DB data migration tools |
5 |
Reports Job related configuration in files system |
Automatic |
Automatically migrated - Report server Cached Job files, Reports Scheduled job information in files system Note: If absolute path names are used for report names, output names etc while scheduling reports, then path names may not be valid in production environment. In such case user need to reschedule reports in production environment using Reports servlet or Reports command line (rwclient utility). |
6 |
Reports Job related configuration in Database [optional] |
Manual |
If Job Repository and / or Job Status Repository is configured in Database for Reports server Same schemas need to be created in DB using script ORACLE_HOME/reports/admin/sql/rw_job_repos.sql Migrate data if any in the original DB for schemas |
7 |
Reports OPSS Security related configurations |
Automatic |
Automatically migrated User and reports server security policy information roles / memberships / policies Credential Store Facility (CSF) entries |
8 |
OID re-association |
Manual |
If OID is used as for SSOCONN RAD entries they need to be migrated from test OID to production OID using OID data migration tool. Reports need to reassociated to new OID via WLST command |
9 |
DB Proxy users |
Manual |
Migrate and DB proxy users to production DB using DB cloning tools |
10 |
Reports Plug-in Destinations, Data Sources [optional] |
Manual |
If Any Reports Plug-in registered, the corresponding jar files needs to be also copied to production environment. The path to these files should also be added in the |
Note that for configuration change replication in files, it may not be possible to just copy the files from test to production as they have references to OracleHome, DomainHome, Port numbers and other variables. Hence user need to use EM/ EM Mbean browser /JConsole or Manual editing for replication of changes.
If new reports are created with new fonts in setup, you can follow steps for "Font and printer setup" and incrementally copy new fonts and reports to production environment
If new CSF keys are created for DB password, you can follow steps for "Reports Security related changes" and incrementally add new CSF keys
Table 8-3 Test to Production Incremental
S.No | Test- Production Migration Areas | Automatic/ Manual | Comments/ Steps |
---|---|---|---|
1 |
Reports Component instances created |
Manual |
Create Reports Server/Tools/Bridge component instances using WLST commands |
2 |
Reports Configuration |
Manual |
Merge Reports Server/Tools/Bridge / J2EE App config. See Publishing Reports to Web chapter for a list of config files at Configuring Oracle Reports Services |
3 |
Reports related resources setup |
Manual |
Merge Fonts / Printer Config / CUPS printer config Fonts: Copy any fonts used in test environment from directory specified by environment variable REPORTS_FONT_DIRECTORY (default ${DOMAIN_HOME}/reports/fonts) to production environment |
4 |
Reports definition files and data tables |
Manual |
Copy the reports files (RDF, JSP, REP, XML etc) used in test environment to production environment. For JSP Web Reports, deploy those JSP reports in production environment reports managed servers in location
Migrate Reports specific data tables referred in RDF files to the DB of production environment using DB data migration tools. |
5 |
Reports Job related configuration in files system |
Manual |
Copy Report server Cached Job files , Reports Scheduled job information in files system Note: If absolute path names are used for report names, output names etc while scheduling reports, then path names may not be valid in production environment. In such case user need to reschedule reports in production environment using Reports servlet or Reports command line (rwclient utility). |
6 |
Reports Job related configuration in Database [optional] |
Manual |
If Job Repository and/ or Job Status Repository is configured in Database for Reports server Same schemas need to be created in DB using script ORACLE_HOME/reports/admin/sql/rw_job_repos.sql Migrate data if any in the original DB for schemas |
7 |
Reports OPSS Security related configurations |
Manual |
Migrate using OPSS command User and reports server security policy information roles / memberships / policies Credential Store Facility (CSF) entries |
8 |
OID re-association |
Manual |
If OID is used as for SSOCONN RAD entries they need to be migrated from test OID to production OID using OID data migration tool. Reports need to reassociated to new OID via WLST command |
9 |
DB Proxy users |
Manual |
Migrate and DB proxy users to production DB using DB cloning tools |
10 |
Reports Plug-in Destinations, Data Sources [optional] |
Manual |
If Any Reports Plug-in registered, the corresponding jar files needs to be also copied to production environment. The path to these files should also be added in the |