| Oracle® Clinical Installation Guide Release 5.0.1 E36499-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Installation Guide Release 5.0.1 E36499-02 |
|
|
PDF · Mobi · ePub |
This chapter describes the recommended approach to upgrading an existing Oracle Clinical installation to Release 5.0.1. Supported upgrade paths include:
Release 4.6.2
Patch Set 4.6.3, 4.6.4, 4.6.5, 4.6.6 or later
Be sure you are using the latest documentation:
Check My Oracle Support Article ID 1572864.1 for any known installation issues; see "Finding Information and Patches on My Oracle Support".
Check the Health Sciences Clinical documentation page at http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html to be sure you have the latest version of this guide.
Check My Oracle Support Article ID 1590927.1 for the latest release of the Oracle Clinical 5.0.1 Release Notes
Review Chapter 1, "Preparing to Install Oracle Clinical" for system requirements and planning information.
This chapter includes the following topics:
Section 11.5, "Upgrading the Oracle Database Server to 11.2.0.4"
Section 11.6, "Upgrading the Database to Oracle Database 11.2.0.4"
Section 11.7, "Upgrading the Oracle Clinical Database Server"
Section 11.10, "Installing the Application Tier Technology Stack"
Section 11.11, "Installing the Oracle Clinical Front End and Reports Server"
Section 11.14, "Upgrading Installations that Use Replication"
Release 5.0 included the following important changes:
Section 11.1.1, "Changes to Parameterized Submission (PSUB)"
Section 11.1.2, "Changes in SAS Data Extract Implementation"
PSUB has been re-architected in Release 5.0 to support an Oracle Real Application Cluster (RAC) installation across multiple nodes. Instead of using dbms_pipes, which can be used only within a single database instance, to communicate between the user session and the PSUB service, Release 5.0 uses Oracle Advanced Queuing.
Changes include:
the RXCPROD account formerly responsible for starting and stopping PSUB (RXCPSDPS) has been eliminated. The PSUB start and stop privilege is now held by the opapps account, which continues to be responsible for the installation. If your company has previously allocated these responsibilities to separate individuals, be aware that your PSUB administrator now requires access to the opapps account.
The opapps account will not only execute the RXCPSDPS (PSUB) process, but all of the batch jobs launched by that process, such as batch validation and batch data load, using the ocpsub proxy database account. These jobs will no longer be executed by individual users' operating system accounts.
The connection information for the proxy account is securely stored in Oracle Wallet, with information you provide when you run the Oracle Clinical Installer. Oracle Wallet replaces the Secure Shell which replaced Remote Shell (rsh, remsh, and rlogin) used in earlier Oracle Clinical releases.
Users who need to submit PSUB jobs no longer need:
a user account beginning with OPS$
an individual operating system account
Instead, a new property identifies users as PSUB users and grants them access to the new ocpsub proxy database account account. To grant this access to existing user accounts, run the migration script oclupg50migrateusers.sql provided with Oracle Clinical 5.0 and described in the Oracle Clinical Administrator's Guide.
PSUB log files are no longer stored on the server but on the database. You need to create a directory to temporarily hold PSUB output files on the PSUB server, but you no longer need to set up a directory for each user. The system does this automatically the first time a user runs a PSUB job on the database.
Some PSUB jobs require input files and/or produce special output files that are still stored on the file server, not in the database.. You can choose to have user-specific directories to store these or to store them all together. If you choose to have user-specific directories, you must create them yourself.
The local reference codelist OCL_STATE has new settings to configure the changed PSUB implementation.
See Chapter 8, "Setting Up the Parameterized Submission Process" for more information.
SAS Data Extract jobs are run by PSUB, so its changes in 5.0 affect SAS as well. Users no longer have individual operating system accounts and are no longer members of the oclsascr user's group.
Like other PSUB users, SAS Data Extract users no longer need individual operating system accounts, and therefore these accounts do not need to belong to the oclsascr user group. Only opapps needs to belong to oclsascr.
Since Oracle Clinical no longer uses individual operating system accounts to run SAS jobs, the authentication method must change. You can set up SAS authentication two different ways:
Using Oracle Wallet
Using SAS proxy encryption file
New OCL_STATE settings also support these options; see Section 9.1.4, "Set Up SAS User Authentication and Set OCL_STATE Reference Codelist Values" for more information.
Four Data Extract processes require input and output files in addition to the usual output files (.log and .out) that in Oracle Clinical 5.0 are stored in the database. Three of the four processes are very similar in structure in that they each require the execution of two jobs. The first job creates files that are executed by SAS in the second job. New settings in the OCL_STATE local reference codelist allow you to execute these two jobs separately. This can be useful when SAS resides on a separate server from the PSUB server; see Chapter 9, "Setting Up SAS."
Note:
SAS files generated in earlier releases of Oracle Clinical cannot be re-used in Release 5.0 because they contain a database connection string that is no longer usable. You can regenerate all your SAS view files to include the correct database connection string using the existing gen_views utility; see the Oracle Clinical Administrator's Guide.There are a few changes related to file viewing in Release 5.0:
You no longer need to specify or set up SFTP or FTP as the method of transferring PSUB log and output files because they are read directly from the database. You no longer need to edit formsweb.cfg for this purpose.
HTTP(S) set up is done during installation of Oracle HTTP Server; see Section 5.6, "Enabling SSL Between a Browser and Oracle HTTP Server".
The location for the crfimages folder used to display images during RDC Onsite data entry has changed. Additional information is available in the Oracle Clinical Administrator's Guide.
Old Location: ORACLE_AS10gR3_HOME\j2ee\rdc\applications\olsardc\rdconsite\de
New Location: OPA_HOME\html\rdc\dcif_images
For example: opapps50\html\rdc\dcif_images
The setup required for viewing PSUB log and output files has changed; see Section 11.1.1, "Changes to Parameterized Submission (PSUB)." In addition, see the Oracle Clinical Administrator's Guide.
Note:
The location and handling of Reports Server log and output files has not changed. They are still located on the on Report Server Windows machine and are accessed using UNC; see Section 7.5, "Setting Up the Reports Server for Access and File Viewing". In addition, see the Oracle Clinical Administrator's Guide.In Oracle Database 11gR2 the DEFAULT profile, which applies to all users by default, including internal users/schemas, enforces password requirements including an expiration period, which is 180 days by default. You must proactively change the passwords before they expire or parts of the system may stop working.
For further information see the Oracle Clinical Administrator's Guide, Chapter 1, and http://docs.oracle.com/cd/E11882_01/network.112/e16543/authentication.htm#CHDCGJED in the Oracle® Database Security Guide 11g Release 2 (11.2).
Before you start to upgrade your system to Oracle Clinical 5.0.1, complete the preliminary tasks described in this section:
Stop PSUB on the database.
The preferred way to stop the PSUB service is with the following utility, from the opapps account, after setting the correct environment. You need to be sure the TNS_ADMIN environment variable is set to the location of the sqlnet.ora file. The Installer puts sqlnet.ora in the opapps Home directory; see "Setting TNS_ADMIN on UNIX" in the Oracle Clinical Administrator's Guide.
Use the echo command to check the setting, then stop PSUB.
Log in to the operating system of the local computer in the opappsaccount.
Set the environment variables for the database and code environment.
Enter the following command:
echo $TNS_ADMIN setenv TNS_ADMIN $HOME stop_psub database_name][environment Wallet_alias
Navigate to the Services control panel.
Highlight the PSUB service.
Click Stop.
You must ensure that no data entry is performed, and no jobs that update data (such as batch validation) run during the upgrade process.
To prevent users from accessing the data, place the database in restricted mode. Provide restricted session access to the following accounts:
OPA
RXC
RXA_DES
RXC_SERVLETST
SYSTEM
After you complete the upgrade, remove the restricted access from the databases and user accounts.
If you have a distributed environment in which you replicate data and metadata among multiple databases using one of Oracle Clinical's replication features, stop all replication before continuing the upgrade.
This section includes the following topics:
Tip:
You must upgrade all databases in your Oracle Clinical installation to Oracle Clinical 5.0.1 before setting up, or resuming, replication in any of them.When upgrading a database, you must either ensure that all incremental replications are up-to-date or perform full definition replications for each study and Global Library after you complete the upgrade. New Mandatory columns do not have values in the journal tables the system uses for both incremental replication and auditing. It would violate the audit trail to back-populate the journal tables with values for the new Mandatory fields, which are left null. An incremental replication that draws upon journal records created prior to the upgrade fails with the following error:
Mandatory column is null. Use caution when applying the percent symbol (%) wildcard to specify which studies to bring across when doing a full study replication. The % wildcard pulls over all studies that are available for replication from all owning locations. (A study is available for replication if its Ready to Repl check box is selected.) If your company has many studies at multiple locations, consider specifying studies uniquely.
To stop standard replication activities in your installation:
Cease the initiation of any new standard replication activities.
Ensure that no replication commands are issued, and no replication batch jobs are executed, until all database upgrades are complete.
In a distributed environment:
Perform either an incremental or a full replication so that all sites are consistent.
Suspend replication.
Upgrade all databases in a replicated set. Do not restart replication until you finish upgrading all databases in a replicated set.
If you follow these instructions, you need only perform incremental replication after the upgrade. If you do not make all sites consistent before the upgrade, you must perform full replication after the upgrade.
Because symmetric replication operates independently of Oracle Clinical, you must stop the database activities that control the symmetric replication activities. In addition, you must stop the symmetric replication activities for each database in your installation.
To stop symmetric replication for one database in your installation:
Log in as the REPSYS user.
Check the replication queue for all pending jobs.
List the pending jobs in the queue:
select * from DEFTRAN;
Push these pending transactions:
dbms_defer_sys.execute(destination=>'other sites.WORLD', execute-as-user=>TRUE);
Disable the replication queues until the upgrade is complete.
List the jobs in the queue:
select * from USER_JOBS;
Locate all the job ID numbers for all push transactions (dbms_defer_sys.execute transactions)
Stop each of these jobs by running:
dbms_jobs.broken(job_id,TRUE);
Note:
This command halts all symmetric replication operations in and out of the affected database, including non-Oracle Clinical replication.Stop all modifications to the database.
As much as possible, avoid making changes to programs, projects, organization units, regions, planned studies, factors, strata, active substances, drugs, or treatment regimens.
Quiesce the databases by executing this command against the master database:
execute dbms_repcat.suspend_master_activity ('RXA_DES');
Drop the replication group from both databases:
execute dbms_repcat.drop_master_repgroup ('RXA_DES');
Oracle recommends backing up your database(s) at this point.
If you are currently using a release of Oracle Clinical prior to Release 4.6.2, you must first upgrade Oracle Database, the Oracle Clinical Database Server and Oracle Clinical databases to Release 4.6.2.
Note:
You do NOT need to install the 4.6.2 application tier because the technology stack is new in Release 5.0.x and you must do a fresh install of the whole application tier.If you are already using Release 4.6.2 or higher, you can skip this section.
Open a Service Request (SR) on My Oracle Support at https://support.oracle.com to download the Release 4.6.2 media, which are no longer publicly available.
Download the most recent version of the 4.6.2 Installation Guide from http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html.
Read Chapter 1 of the Release 4.6.2 Installation Guide to plan your installation.
In the Release 4.6.2 Oracle Clinical Installation Guide Chapter 12, Upgrading an Oracle Clinical Installation to Release 4.6.2 perform the tasks in Section 12.2, "Completing Other Pre-Upgrade Tasks."
Do Section 12.4, "Installing Oracle Clinical 4.6.2 on the Database Server." This step is needed to upgrade databases to 4.6.2.
Do Section 12.5, "Upgrading Oracle Clinical 4.6.2 to the New Oracle 11gR2 Oracle Home" to upgrade your databases to the new Oracle Home.
Do Section 12.6, "Upgrading Database Objects to Oracle Clinical 4.6.2"
Note:
Do NOT follow the other instructions in Section 12.7 "Installing and Configuring Other Components for Oracle Clinical".Check section 12.9, "Repairing Oracle Clinical Data." If you have not already run the Find and Fix scripts that are available, run them now.
Now follow instructions below.
You must upgrade Oracle Database to 11.2.0.4.
To upgrade on Windows, follow these instructions:
Section 3.3.1, "Install Oracle Database 11.2.0.4 Enterprise Edition"
Section 3.3.2, "Install Oracle Database 11g Release 2 Examples"
Note:
If you are upgrading a Windows database, be sure there is only one Oracle Home, and that the path points to the 11.2.0.4 home. Otherwise, you will not be able to start PSUB.Upgrade each database to 11.2.0.4 following instructions in the patch readme file and Oracle Database 11g Release 2 (11.2) Installation Guide for your operating system at http://www.oracle.com/pls/db112/portal.portal_db?selected=11&frame=
To upgrade the Oracle Clinical Database Server component, you log in to the server, run Installer from the appropriate download location, and select the OC Server product. Follow instructions for your operating system:
Section 11.7.1, "Install the Oracle Clinical 5.0.1 Database Server on UNIX"
Section 11.7.2, "Install the Oracle Clinical 5.0.1 Database Server on Windows"
Then follow instructions in Section 11.7.3, "Set Initialization Parameters".
This section describes the tasks that you complete to install Oracle Clinical 5.0 on UNIX Database Servers.
Note:
When you run the Installer, choose the Upgrade option.See "Using the Silent Installer" for instructions for running the Installer as a file with pre-entered parameter values.
Perform the UNIX-specific installation instructions in Chapter 2, Section 2.5, "Installing the Oracle Clinical Database Server."
Installing Oracle Clinical creates the OPA_HOME/bin/opa_settings file. This file contains global environment setting defaults that you can now modify for this computer, if necessary; see Section 2.6.2, "Review the opa_settings File" for more information.
To install Oracle Clinical 5.0.1 on a Windows Database Server:
Perform the installation instructions in Section 3.4, "Installing the Oracle Clinical Database Server."
Note:
When you run the Installer, choose the Upgrade option.After the upgrade completes, set the init.ora parameters according to the instructions in Section 4.1.7, "Set Initialization Parameters."
You must stop and then start the database to activate the changed init.ora parameters.
Notes:
If you set up the EVENT parameter in the init.ora file to trace unique key constraints before upgrading, you should set the event parameter back to its required value. See Section 4.1.7, "Set Initialization Parameters" for details.If your init.ora file includes the REMOTE_OS_AUTHENT parameter, make sure that it is not set to TRUE. It can be set to FALSE or be absent.
This section describes how to run Installer to upgrade each database.
Note:
If you are upgrading to a RAC environment, you must import your database(s) to a single RAC node before running the Installer to upgrade it.See Section 4.2.2, "Gather Required Information" before you start the Installer. The information in Section 4.2.2 is not in quite the same order as displayed in the Installer for upgrading databases but it is the same information.
To start the upgrade of an Oracle Clinical database on a UNIX Database Server:
Log in to the server computer as the opapps user.
Change the primary group of the opapps account to the group that owns the Oracle Inventory:
newgrp inst_group
where inst_group is the name of the group that owns the Oracle Inventory. You specified the name during the Oracle Database 11g Release 2 (11.2.0.4) installation. Typically, this user group is oinstall.
This temporary change is necessary so that the Installer can update the Oracle Inventory.
Set the X Window display output to the IP address of your local computer. Use the standard format for IP addresses, and add ":0" to the end of the address. For example:
setenv DISPLAY 123.45.67.89:0
Navigate to this location in the folder where you extracted the server code; see Section 1.5, "Downloading and Extracting the Software":
server_code_platform\Disk1\install
Change protections on files to 755.
chmod 755 *
Start the Installer:
./runInstaller
The Installer opens to the Welcome screen. Click Next.
In the Select a Product to Install screen, select OC Database Upgrade. Follow instructions on screen, entering the information indicated in Section 4.2.2, "Gather Required Information".
Reset the privileges for the opapps account:
newgrp group
where group is the name of your original primary group for the opapps account.
To begin the installation:
Log in using an account with Windows system administrator privileges.
Navigate to this location in the folder where you extracted the server code; see Section 1.5, "Downloading and Extracting the Software".
Locate and execute file:
oc\server_code\win\install\setup.exe
The Installer opens to the Welcome screen. Click Next.
In the Select a Product to Install screen, select OC Database Upgrade. Follow instructions on screen, entering the information indicated in Section 4.2.2, "Gather Required Information".
The Installer generates numerous log files and saves the files to the following location:
Windows OPA_HOME\oc\50\install
After running the Installer, check the log files to confirm that the upgrade succeeded. Upgrading the Oracle Clinical database produces the following log files:
compile_all_invalid_database.log
html_blob_seeddata_database_timestamp.log
html_dialg_templ_database_timestamp.log
load_olsardcstatemachine_jar_database.log
oclconfig_database.log
oclupg_database.log
opaconnectcheck_system_database.log
upgrade_database_timestamp.log
xmlp_clob_seeddata_database_timestamp.log
xml_clob_seeddata_database_timestamp.log
The rest of this section describes finding errors in the log files (as logfile), and descriptions of known errors.
To simplify reviewing upgrade results, run these commands for each of the database upgrade log files:
Oracle Linux From the command line, enter:
opa_setup database 50cd $RXC_INSTALL/bin/grep -n -E '^ORA-|^PLS-|^SP2-' logfile | more
Oracle Solaris SPARC From the command line, enter:
opa_setup database 50cd $RXC_INSTALL/usr/xpg4/bin/grep -E '^ORA-|^PLS-|^SP2-' logfile | more
Windows From the command line, enter:
set p1=databaseset p2=50opa_setupcd %RXC_INSTALL%find /i "error" logfile | find /v "No error"This section describes known error messages and possible actions you can take to resolve them.
See My Oracle Support Article ID 386941.1, OLSA 4.6.x and 4.7.x Known Install and Configuration Issues, for a description of any error messages.
If the installation fails to reencrypt any password, it does not list them as errors. Instead, it lists them in the log files in a section titled, "Passwords for the following schema accounts were not converted." Check if this section exists and if it lists any accounts. If there are any accounts, you must reencrypt them using the set_pwd command; instructions are in the Oracle Clinical Administrator's Guide.
When you upgrade a database from Oracle Clinical 4.6.2 to Patch Set 4.6.3 or later, the Installer runs a validation script to ensure that all studies have been migrated to the enhanced approval and verification data model that was introduced in Oracle Clinical 4.5.3.11 and 4.5.3.12. If the database is in a replicated environment, within each study the Installer validates only patients that are owned by the current location.
Check the Installer log file:
If the validation succeeds, the log file includes the message "Validation succeeded, database has been migrated to the new approval/verification data model. No further action is required." and the database upgrade process continues. However, if in the future you need to unfreeze a currently frozen study, you may need to migrate its data first.
If the validation fails, the database upgrade process is terminated. The log file includes the error message that the migration has not been run on the database. Contact Oracle Support for further instructions.
When upgrading the Oracle Clinical database, the Installer automatically calls and runs the following script to compile invalid objects:
compile_all_invalid.sql
However, to reduce the time required to run the script and to ensure that the installation completes in a timely manner, the compile_all_invalid.sql script does not compile these invalid objects:
Packages owned by RXC_PD (that is, the validation and derivation procedures that you have created). The package name starts with RXC_PD.
Data Extract views that belong to a study. In the database, these views are owned by an internal user whose name starts with study_name$.
Objects owned by any ops$ account. The compile_all_invalid.sql script ignores objects if the owner has a dollar symbol ($) in the name.
The log file generated by the compile_all_invalid.sql script lists the objects that could not be compiled.
To view the list of invalid objects, open the following log file:
$RXC_INSTALL\compile_all_invalid_database.log
To compile the remaining invalid objects (see Table 11-1), run the script compile_schema_invalid.sql.
You can run the compile_schema_invalid.sql script at a suitable time after the Installer finishes upgrading the Oracle Clinical database. You can recompile the invalid objects for a given schema by connecting to the schema and then running the compile_schema_invalid.sql script.
If you have any PL/SQL code referenced from your generated procedures, ensure that these objects are valid before running the compile_schema_invalid.sql script.
For example, if you created a schema named X that contains all the PL/SQL code referenced from your generated procedures, you would first run:
compile_schema_invalid.sql X
Then, you would run:
compile_schema_invalid.sql RXC_PD
Follow the instructions appopriate for your operating system.
To run the compile_schema_invalid.sql script on UNIX:
Log in to the UNIX database server computer as the opapps user.
Set the UNIX environment:
opa_setup database_name code_environment
where:
database is the name of this database instance.
code_environment is the value in the opa_settings file for this code environment. For Oracle Clinical 5.0, the default value is 500.
Change to the RXC_INSTALL directory:
cd $RXC_INSTALL
Start an SQL*Plus session, and connect to the database as sys:
sqlplus sys/sys_password as sysdba
Run the script. Table 11-1 lists the options you can use to run the script depending on which invalid objects you want to compile.
Table 11-1 SQL Commands for Compiling Specific Types of Invalid Objects
| To… | Enter this SQL Command… |
|---|---|
|
Compile any invalid objects in RXC_PD |
|
|
Compile any invalid objects for the Data Extract views that belong to a study |
|
|
Compile any invalid objects in OPS$ accounts |
|
|
Compile any invalid objects in any account that has the dollar symbol ($) in the account name |
|
|
Compile all invalid objects in all schemas |
Note that this command compiles all invalid objects, including those in other schemas such as RXC and RXA_DES. However, the compile_all_invalid.sql script that the Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas. |
Check the log file to verify that the script compiled the invalid objects successfully:
$RXC_INSTALL\compile_schema_invalid_database.log
To run the compile_schema_invalid.sql script on Windows:
From the command line, enter:
set p1=database
set p2=50
opa_setup
cd %RXC_INSTALL%
Start an SQL*Plus session, and connect to the database as sys:
sqlplus sys/sys_password as sysdba
Run the script. Table 11-2 lists the options you can use to run the script depending on which invalid objects you want to compile.
Table 11-2 SQL Commands for Compiling Specific Types of Invalid Objects
| To… | Enter this SQL Command… |
|---|---|
|
Compile any invalid objects in RXC_PD |
|
|
Compile any invalid objects for the Data Extract views that belong to a study |
|
|
Compile any invalid objects in OPS$ accounts |
|
|
Compile any invalid objects in any account that has the dollar symbol ($) in the account name |
|
|
Compile all invalid objects in all schemas |
Note that this command compiles all invalid objects, including those in other schemas such as RXC and RXA_DES. However, the compile_all_invalid.sql script that the Installer automatically runs after upgrading the Oracle Clinical database already compiles the invalid objects for those schemas. |
Check the log file to verify that the script compiled the invalid objects successfully:
%RXC_INSTALL%/compile_schema_invalid_database.log
Do each of the following tasks.
The Oracle Clinical Remote Data Capture Onsite (RDC Onsite) application uses the dbtimezone value for internal calculations when the Display timestamps in local timezone preference is set. See Section 4.4.1, "Set the Database Time Zone" for instructions.
To improve performance, some of Oracle Clinical's packages are pin-able packages; Pinning allocates a stable memory location so that a package cannot be subjected to being swapped out of memory. Oracle Clinical provides the rxcdbinit.sql script in the rxc_install directory to pin the database packages.
Run the script rxcdbinit.sql as RXC. For details, see Section 4.4.2.1, "Pin UNIX Database Packages" or Section 4.4.2.2, "Pin Windows Database Packages".
After upgrading to OC 5.0 and setting initialization parameter optimizer_features_enable to 11.2.0.4 (see Section 4.1.7, "Set Initialization Parameters"), you must manually run several scripts. These scripts gather statistics required for the Oracle 11g Optimizer to be effective for accounts used internally by Oracle Clinical, RDC Onsite, and TMS. Each script prompts for the password of the account(s) it processes.
If your database contains large amounts of data, the scripts may take a long time to run. You may want to edit the scripts; for information on the scripts' parameters see the following documentation of the DBMS_STATS package that is called by these scripts: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036456.
oclstats.sql captures new statistics in the RXC, RXA_LR, RXA_DES, RXA_DISC_REP application accounts required for the Oracle 11g optimizer to be effective and result in better performance of Oracle Clinical and RDC Onsite.
opastats.sql captures new statistics in the OPA application account used by Oracle Clinical, RDC Onsite, and TMS.
Failure to execute these scripts can negatively impact performance.
You may have customized Oracle Clinical and RDC Onsite files for various purposes. Due to changes in the underlying application tier technology stack, many of these files have been changed in Release 5.0. The application tier cannot be upgraded; it must be completely reinstalled.
To preserve your customizations:
Back up each file that you have customized before you install the new application tier. The following sections provide a list of customizable files and the actions required to preserve your changes.
From the Administration Console for the OPA domain (by default, port 7101), stop and delete the RDC Onsite application.
Install the new application tier technology stack, following instructions in Chapter 5, "Installing and Configuring the Application Tier."
Using information in the following sections, manually reenter your changes to the new versions of files that have changed in Release 5.0.
Redeploy these files and any files you have customized that have not changed in Release 5.0.
Restart the application for your changes to take effect.
The following sections contain information on customizable files:
Affected Files: rxcuser.pll, rxcuser.fmb, rxcuser.mmb, rxclbcli.pll
Note:
If you have customized rxclbcli.pll to integrate OC with an external workflow or imaging system, you must change user_password arguments in getimage and getimagedcf from encrypted_passwords.password%type to varchar2.Required Action to Preserve Customization:
Recompile rxcuser.fmb with Forms Builder 11g.
Recompile rxcuser.mmb with Forms Builder 11g.
Replace your recompiled rxcuser.fmb and rxcuser.mmb files on each Forms Server in your network.
Table 11-3 Oracle Clinical Customizable Forms Files with 4.6.2 Locations
| File Name | Location in 4.6.2 | Purpose of Customization | Changed in 5.0? |
|---|---|---|---|
|
rxcuser.fmb |
opapps46\oc\admin |
Customizing the Users and Roles menu |
Changed |
|
rxcuser.mmb |
opapps46\oc\admin |
Customizing the Users and Roles menu |
Changed |
|
rxcuser.pll |
opapps46\oc\admin |
Customizing the Users and Roles menu |
Changed |
|
rxclbcli.pll |
opapps46\oc |
Integration with other systems; see the Oracle Clinical Application Programming Interface Guide for information. |
Changed |
Affected Files: rxcdrptl.rdf, rxcdrptp.rdf
Required Action to Preserve Customization: Recompile with Oracle Reports 11g and replace in opa_home\oc folder on the Oracle Reports server.
Table 11-4 Oracle Clinical Customizable Forms Files with 4.6.2 Locations
| File Name | Location in 4.6.2 | Purpose of Customization | Changed in 5.0? |
|---|---|---|---|
|
rxcdcf.bmp |
opapps46\oc\ |
Customizing the image on DCF reports. |
Not changed |
|
rxcdrptl.rdf |
opapps46\oc\admin |
Customizing DCF reports landscape template. |
Changed |
|
rxcdrptp.rdf |
opapps46\oc\admin |
Customizing DCF reports portrait template. |
Changed |
|
All files with extension .conf |
ORACLE_AS10gR2_HOME\reports\conf |
Report Server parameter configuration. |
Obsolete in 5.0 |
If you modified the DE_GRIDWIDTH and DE_GRIDHEIGHT parameters in formsweb.cfg, recreate your changes so your Data Entry screens have the correct appearance.
You may also have modified the file for file viewing purposes. These customizations are obsolete in Release 5.0; see Section 11.1.3, "Changes to File and Image Viewing".
In Release 4.6.2 this file was located at:
ORACLE_AS10gR2_HOME\forms\server.
The new version of the file is located at:
Middleware\user_projects\domains\FRDomain\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_11.1.2\config.
Table 11-5, "RDC Onsite Customizable Files" lists the RDC Onsite files that were customizable in Release 4.6.2 with their 4.6.2 location, the purpose of customization, and information about whether they have been changed or even made obsolete in Release 5.0, and their Release 5.0 location, if any.
Most of these files are now inside the olsardc.ear file, which contains the entire RDC Onsite application. You must reenter any customizations you have made and repackage the. ear file, then redeploy the application. Contact Oracle Support for help if necessary.
For more information on customizing these files, see the Oracle Clinical Remote Data Capture Onsite Administrator's Guide.
Table 11-5 RDC Onsite Customizable Files
| File Name | Location in Release 4.6.2 | Purpose of Customization | Changed in 5.0? | Location in Release 5.0 |
|---|---|---|---|---|
|
bc4j.xcfg |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF\classes\oracle\pharma\ rdc\model\services\common |
Performance configuration |
Changed; no longer used by launch page |
olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\lib\rdcmodel.jar\oracle\pharma\rdc\model\services\common |
|
dataentry-config.xml |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\ |
Performance configuration |
Obsolete in 5.0; configurations moved to rdcConfig.properties |
NA |
|
dataentrylogger.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF |
Specify the detail level of DE log file debug info |
Changed |
olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\ |
|
dcapi.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\ |
DCAPI log file generation, performance configuration |
Changed |
\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\ |
|
de_external.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\classes\oracle\ pharma\rdc\de\resource\properties |
Approval warning message, labels in data entry |
Changed |
olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\lib\rdcdataentry.jar\oracle\pharma\rdc\de\resource\properties |
|
opalogger.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\ |
~ |
Obsolete in 5.0 |
NA |
|
RdcLogos.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF\classes\oracle\ pharma\rdc\view |
Contact Us link |
Changed |
Determined by the location mentioned in registry variable HKLM > Software > Oracle > opa50 > opa_config_folder. |
|
RdcTexts.properties |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\rdconsite\WEB-INF\classes\oracle\pharma\rdc\view\nls |
Change Password link, text and messages in the RDC Surround |
Changed |
Determined by the location mentioned in registry variable HKLM > Software > Oracle > opa50 > opa_config_folder. |
|
web.xml |
ORACLE_AS10gR3_HOME\j2ee\rdc\applications\ olsardc\ rdconsite\WEB-INF |
Timeout interval, performance configuration |
Changed |
Most functionality moved to rdcConfig.properties. Exists and located at: olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\ |
|
orion-web.xml |
ORACLE_AS10gR3_HOME\j2ee\rdc\application- deployments\ olsardc\rdconsite\ |
Used in image viewing |
Obsolete in 5.0 |
NA |
|
orion-web.xml |
ORACLE_AS10gR3_HOME\j2ee\opa\application- deployments\ olsardc\rdcclassic\ |
Used in image viewing |
Obsolete in 5.0 |
NA |
If you customized any of the following files, to retain your changes you must reapply your customizations after upgrading.
In Release 5.0 these files reside in the opapps50 directory, not the opapps46 directory.
Table 11-6 HTML Customizable Files with 4.6.2 Locations
| File Name | Location in 4.6.2 | Purpose of Customization | Changed in 5.0? |
|---|---|---|---|
|
launch.htm |
opapps46\html |
Customize the launch page |
Changed |
|
ocdcitemplate.htm |
opapps46\html |
Customize the launch page for the batch generator for HTML Data Entry Forms and Patient Data Report Templates |
Changed |
|
rdcadmin.htm |
opapps46\html |
Customize the RDC Admin launch page |
Changed |
|
rdcadmint.htm |
opapps46\html |
Customize the RDC Admin test mode launch page |
Changed |
|
rdclaunch.htm |
opapps46\html |
Customize the RDC launch page |
Obsolete in 5.0 |
|
rdclauncht.htm |
opapps46\html |
Customize the RDC test mode launch page |
Obsolete in 5.0 |
|
All files |
opapps46\html\xhelp |
Customize online help content |
Changed |
One customizable database script, ocl_add_user.sql, has changed in Oracle Clinical 5.0.
These scripts are located in the same directories in Release 5.0 as in Release 4.6.2. For information about customizing them, see the Oracle Clinical Administrator's Guide.
Table 11-7 Customizable Database Scripts with 4.6.2 Locations
| File Name | Location in 4.6.2 | Purpose of Customization | Changed in 5.0? |
|---|---|---|---|
|
ocl_add_user.sql |
RXC_TOOLS |
Create new user accounts. |
Changed |
|
rxcptdxvb.sql |
install directory |
Customize data extract views. |
Not changed |
|
pop_vb_static_views.sql |
install directory |
Customize data extract views. |
Not changed |
|
ocl_client_pb.sql |
install directory |
Customize to add PLSQL code to be invoked from various parts of the application. |
Not changed |
|
rxasravw.sql/rxasravw_custom.sql |
rxc_install directory |
Customize Study Design replication. |
Not changed |
|
rdcpb_client.sql |
Customize flex fields for DCI Forms. |
Not changed |
Because Oracle Clinical 5.0 uses a different technology stack than earlier releases of Oracle Clinical, you cannot upgrade the application tier; you must install it fresh.
For Oracle Clinical 5.0, the Application Tier technology includes:
Oracle Application Server 11gR2 , which includes the Oracle Forms Server and the Oracle Reports Server. Both are required for Oracle Clinical.
WebLogic Server 11gR1 (10.3.6) and Oracle Application Developer Framework 11g R1. These are required for RDC Onsite.
You can install all components on the same machine, or install on multiple machines, but you must install all components on all machines and then disable services on the machine(s) where they are not needed.
To ensure high availability of the Reports Server, you can set up and use more than one Reports Server on a subnet and they can access each other. For more information see the Oracle Clinical Administrator's Guide.
Follow instructions in Chapter 5, "Installing and Configuring the Application Tier."
Install the following:
Oracle Clinical Forms Server — See Chapter 6, "Installing the Oracle Clinical Front End."
Oracle Clinical Reports Server — See Chapter 7, "Installing the Oracle Clinical Reports Server."
Set up the following:
PSUB — See Chapter 8, "Setting Up the Parameterized Submission Process."
SAS — See Chapter 9, "Setting Up SAS."
Clients — See Chapter 10, "Setting Up Clients."
Upgrading from 4.5.x If you are upgrading from Oracle Clinical 4.0.3 or 4.5.x, follow instructions in the Oracle Clinical Administrator's Guide "Troubleshooting" chapter, "Managing High Sequence Numbers" section, to assess the current value of internally generated IDs, reseed the sequence(s) if necessary, and ensure that the maximum value is properly set to avoid severe referential integrity bug 3718908. The affected sequences are the internal identifiers for:
Received DCMs (RDCMs)
Received DCIs (RDCIs)
Discrepancies
Responses
Upgrading from 4.6.x If you are upgrading from Oracle Clinical 4.6.x you may want to proactively determine whether you need to reseed any of these sequences. If the value of any of these internal IDs gets too close to the maximum, the system gives a warning message to a user attempting to use the relevant subsystem and exits the current screen. To avoid this, you can assess how close the highest current value is to the maximum and reseed the sequence in advance if necessary. For further information see the Oracle Clinical Administrator's Guide "Troubleshooting" chapter, "Managing High Sequence Numbers" section.
If you use replication and have upgraded all databases in this distributed environment, follow instructions in the Oracle Clinical Administrator's Guide to enable the type(s) of replication you use.
|
 Copyright © 1996, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|