This section offers solutions to known Oracle Clinical issues in the following categories:
See also "Troubleshooting Symmetric Replication."
If you redeploy the RDC Onsite .ear file—for example, to apply a patch—restart the application server, including the WebLogic Admin Server. This helps clear connection pools and any DLLs that may be loaded. If you do not restart the server, the following message is displayed the next time a user opens an RDC Onsite data entry window:
java.lang.UnsatisfiedLinkError: Native Library drive:\opapps52\bin\olsadcapiprocmgr.dll already loaded in another classloader
If you receive the following warning: ConnectOCL - 970100: The following sequence(s) is approaching its maximum value : DISCREPANCY_ENTRY_SEQ
(or another of the sequences mentioned below), you need to reseed the sequence; see "Reseeding Sequences".
In all versions of Oracle Clinical since 4.5.1 the system enforces that the internal identifier for each of the following cannot exceed 9,999,999,999 (that is, 10^10 -1):
Received DCMs (RDCMs)
Received DCIs (RDCIs)
Discrepancies
In addition, Response IDs cannot exceed 1,000,000,000,000,000 (10^15).
This is because in earlier versions, when the internal identifier for these records exceeded 2,147,483,647 the system incorrectly processed the identifiers and batch validation, data extract, replication, and procedure execution operations failed or ran incorrectly.
The OCL_DE_CONFIG Local Codelist includes a value, SEQUENCEBUFFER, which is assigned an initial long value of 1,000,000. At this setting, when a sequence number is within 1,000,000 of 9,999,999,999, the system displays the warning message above when a user attempts to use a relevant subsystem and the system exits the current screen. If you prefer a larger or smaller buffer, you can change the value in the reference codelist.
Perform this test to proactively determine if your database is nearing the point where this situation may occur. If the result of this test for the number of Received DCMs, Received DCIs, or discrepancies is well below 9,999,999,999—or 1,000,000,000,000,000 for responses—you do not need to reseed the corresponding sequence.
To determine the next sequence number to be generated for an RDCM, RDCI, or discrepancy in your system:
Connect to your database through SQL*Plus as RXC.
Issue a command to determine the next sequence value to be assigned:
For RDCMs:
SELECT received_dcm_seq.nextval FROM dual;
For RDCIs:
SELECT received_dci_seq.nextval FROM dual;
For discrepancies:
SELECT discrepancy_entry_seq.nextval FROM dual;
The system returns a number after each command. If any internal identifier number is approaching 9,999,999,999, you should reseed the sequence; see "Reseeding Sequences".
Use this query to check if the maximum sequence value is correctly set to 9999999999. (Releases prior to 4.5.1 had no maximum limit.)
col max_value format 9999999999 select sequence_name,max_value from dba_sequences where sequence_name in ('RECEIVED_DCM_SEQ','RECEIVED_DCI_SEQ','DISCREPANCY_ENTRY_SEQ');
Note:
If the nextval value retrieved in Step 2 is greater than 2,147,483,647 and the maximum has not been set to 9999999999, see My Oracle Support note ID 277278.1.If the query finds that any of the maximum values is set to anything other than 9999999999, run a command to reset it:
For RDCMs:
alter sequence received_dcm_seq maxvalue 9999999999;
For RDCIs:
alter sequence received_dci_seq maxvalue 9999999999;
For discrepancies:
alter sequence discrepancy_entry_seq maxvalue 9999999999;
To determine the next sequence number to be generated for a response in your system:
Connect to your database through SQL*Plus as RXC.
Issue this command to determine the next sequence value to be assigned:
SELECT response_seq.nextval FROM dual;
The system returns a number. If it is approaching 1000000000000000 (10^15), you should reseed the sequence; see "Reseeding Sequences".
Use this query to check if the maximum sequence value is correctly set to 1000000000000000 (10^15). (Releases prior to 4.5.1 had no maximum limit.)
col max_value format 9999999999999999 select sequence_name,max_value from dba_sequences where sequence_name in ('RESPONSE_SEQ';
If the query finds that any of the maximum values is set to anything other than 1000000000000000, run a command to reset it:
alter sequence response_seq maxvalue 1000000000000000 ;
If any of your sequence numbers are approaching or exceed the maximum value, you should reseed them. The system generates sequence numbers in increments of 100, so unused numbers are available.
When you reseed a sequence, the system prompts you to provide a previously unused start value. After reseeding, the system uses the same increment value to generate new values, ensuring that the new generated values are unique.
To reseed any of these sequences:
Stop all Oracle Clinical activity on the database until this procedure completes.
Connect to the database through SQL*Plus as RXC.
To determine which seed numbers are already in use for the sequence(s) you are reseeding, issue a command:
For RDCMs:
SELECT distinct mod(received_dcm_id,100) FROM received_dcms;
For RDCIs:
SELECT distinct mod(received_dci_id,100) FROM received_dcis;
For discrepancies:
SELECT distinct mod(discrepancy_entry_id,100) FROM discrepancy_entries;
For responses:
SELECT distinct mod(response_id,100) FROM responses;
Note:
If this is a replicated environment, run this command in all replicated instances.Choose a new starting seed number value between 0 and 99 (inclusive) that is not in the list returned by the above step.
Issue a command to drop the sequence(s) you are reseeding:
For RDCMs:
DROP sequence received_dcm_seq ;
For RDCIs:
DROP sequence received_dci_seq ;
For discrepancies:
DROP sequence discrepancy_entry_seq ;
For responses:
DROP sequence response_seq ;
Issue a command to recreate the sequence(s) with a new starting value. The system prompts you to enter the new starting value (START WITH &SEQ_START_NO
).
For RDCMs:
CREATE SEQUENCE received_dcm_seq INCREMENT BY 100 START WITH &SEQ_START_NO MAXVALUE 9999999999 MINVALUE 1 NOCYCLE CACHE 20 NOORDER;
For RDCIs:
CREATE SEQUENCE received_dci_seq INCREMENT BY 100 START WITH &SEQ_START_NO MAXVALUE 9999999999 MINVALUE 1 NOCYCLE CACHE 20 NOORDER;
For discrepancies:
CREATE SEQUENCE discrepancy_entry_seq INCREMENT BY 100 START WITH &SEQ_START_NO MAXVALUE 9999999999 MINVALUE 1 NOCYCLE CACHE 20 NOORDER;
For responses:
CREATE SEQUENCE response_seq INCREMENT BY 2000 START WITH &SEQ_START_NO MAXVALUE 1000000000000000 MINVALUE 1 NOCYCLE CACHE 20 NOORDER;
Note:
In the case of responses, the sequence uses 2000 as the increment and Oracle Clinical manipulates this value by adding 100 to it 20 times before going back to sequence.Issue this command to grant access:
For RDCMs:
GRANT SELECT on received_dcm_seq to RXCLIN_MOD;
For RDCIs:
GRANT SELECT on received_dci_seq to RXCLIN_MOD;
For discrepancies:
GRANT SELECT on discrepancy_entry_seq to RXCLIN_MOD;
For responses:
GRANT SELECT on response_seq to RXCLIN_MOD;
This section offers fixes or workarounds for the following error messages:
The Oracle Clinical Conducting a Study guide has a list of batch data load error messages with descriptions of the problem.
This message may appear in the .log
file and is a data replication issue. Oracle Clinical expects to conduct data replication between two locations using named packages rather than synonyms.
Solution: The named packages should have been created during setup for replication by executing the dyna_rxapkirp.sql script. See "Creating the Package for Replicating Investigators and Sites".
Full message text:
Full message text:
323600 Unable to change to test mode, another session may be connected.
323700 Unable to change to production mode, another session may be connected.
325700 Unable to change to test mode (\0), synonyms not created.
325800 Unable to change to production mode (\0), synonyms could not be dropped.
For each of the above error messages, Oracle Clinical users should check with the administrator. This problem could be due to an RXCSYN package error, missing grants to RXC, or synonym conflicts with your schema objects.
These messages may appear if you switch between production and test modes while having another session open under the same userid. It may also appear if a user submitted a reports job before switching modes, and the reports engine is still associated with that user. The system considers this to be another session by the same user.
To check if you are logged on to more than one session, from SQL, you can enter the command:
select username from v$session;
If you do not have access to v$session, consult with a DBA.
In the case of reports jobs, you can prevent future problems by changing the MAXIDLE time of the Reports Server, which controls the length of time a user/engine session is kept open.
To change the MAXIDLE time of the Reports Server:
Open up the report queue manager and select the report queue of concern.
Select Options, then Privileges, and Administrator and log on as administrator.
Choose Queue, then Properties and change the maximum idle time to one minute or some reasonable smaller number (depending on the number of reports, users, and so forth on that queue).
In the case of a user switching modes, you can create a separate test account as described under ORA-04020, above.
If procedure generation fails and the parse error displays: "PL/SQL Package Body: Looping Synonyms" the problem is actually that the account RXC_PD does not have a password set. It may have expired due to Oracle Database security settings. To reset these passwords, log into SQL*Plus and enter:
set_pwd rxc rxc_pd
The system prompts for the RXC password and the new RXC_PD password.
When a general protection fault (GPF) occurs during data entry, the system creates file rxcdecde.dbg, which contains a description of the cause of the GPF. The file resides in the RXC_ROOT directory.
This section describes steps you should take, in order, when you troubleshoot PSUB problems.
To troubleshoot a PSUB job:
Troubleshooting PSUB Based on the Batch Job's Execution Status
Handling PSUB Failures that Return "Fatal two-task communication protocol" Error
Handling PSUB Failure that Returns "Illegal use of PSLAUNCH…" Error
Also included:
If a problem arises while you are running PSUB, you should first review the Failure Text field of the Submitted Batch Jobs window.
To check this field for your batch job:
Open the Submitted Batch Jobs window: select Admin, then PSUB/Reports Jobs, and then Batch Jobs.
Locate the relevant Batch Job ID number.
Check the Execution Status of the job. If there is an entry in the Failure Text field, make a note of its contents
If the failure text does not help you to resolve the problem, see "Check the PSUB Log Files". If your batch job is hanging because the batch queue is full, see "If Batch Jobs Hang and the Batch Queue Is Full".
The PSUB process log files are cumulative, text-based descriptions of PSUB activity. These files are very helpful when you are troubleshooting problems with PSUB Process log files can include time stamped entries for:
Error messages returned by the PSUB process
All jobs submitted by the user; the entry may include each job's:
Message ID
Batch_job_ID
User name
On both UNIX and Windows systems, PSUB process log file names are in the form:
rxcpsd_
product_instance code_environment
_1.log
On UNIX systems, there is a second process log file. Whenever you examine the "*_1.log" process log file on UNIX systems, you should also check this second file to see if it contains relevant entries. Its name is identical to the first log file, except that it has an "_2" suffix, rather than "_1". So the second UNIX process log file name is in the form:
rxcpsd_
product_instance code_environment
_2.log
The "*_2.log" process log files contain error and warning messages that are generated by certain UNIX commands that the PSUB process executes (e.g., non-background commands). These commands are not present in the PSUB service on Windows. Therefore, Windows systems only generate "*_1.log" process files.
The [verbose|nonverbose] argument must be included when the PSUB startup command, rxcpsdps
, is executed. Oracle recommends that you start PSUB in verbose mode because the process logs that are generated:
Contribute to efficient troubleshooting
Do not pose significant disk space concerns
On UNIX systems, rxcpsdps is 'wrapped' in the OPA script start_psub. By default, the start_psub script executes rxcpsdps in verbose mode.
On Windows systems, the PSUB service requires that you explicitly provide the [verbose|nonverbose] argument. See "Managing the PSUB Process".
If you cannot check the Failure text or the .out and .log files because the batch queue is hung, see "If Batch Jobs Hang and the Batch Queue Is Full".
Verify that the process log files for the relevant Batch Job ID exist.
Review the .out and .log files. The following table summarizes these files. Make a note of any error messages.
Name | Description | Directory |
---|---|---|
lbatch_job_id.log | Log file of a specific job | RXC_LOG |
obatch_job_id.out | Output file of a specific job | RXC_LOG |
*.log | Log file of the PSUB process (see "Viewing Log and Output Files on the Screen" for naming convention) | RXC_CENTRAL_LOG |
Check the job-specific log and output files first, then the central log file. In the central log file, search for the batch job ID number to find the relevant entry. See if the database and code environment settings are correct.
If all PSUB jobs hang (that is, they do not reach a completed execution status), and the batch queue is full, attempt to clear the queue and submit a single job to PSUB. If a problem then occurs with a single job, it may be clearer which area is causing the problem. The method for clearing the queue is either: stop all of the hung batch jobs (on UNIX systems) or stop the PSUB service (on Windows systems).
The queue may become full and PSUB jobs may hang under the following circumstances:
PSUB is waiting, either for an operating system resource, or a database resource
the operating system is overloaded, for example, a built-in limitation, such as maximum number of processes, is exceeded.
This section describes how to stop batch jobs on UNIX systems. See also "Starting and Stopping PSUB Manually in UNIX".
To stop an individual batch job:
Navigate to Admin, PSUB/Reports Jobs, and Batch Jobs).
Locate and select the row associated with the relevant Batch Job ID.
Click the Stop button.
On UNIX servers, a series of hanging jobs can cause the batch queue to become full. When the queue fills and is backlogged with hanging jobs, all jobs are eventually given an execution status of SUBMIT_FAILED or SUBMITTED. If this type of problem occurs frequently, it may be advantageous to fine-tune the existing queues or add more queues.
If, after trying all relevant solutions, you are unable to stop the jobs on a UNIX server, contact your Administrator so that she may use the solutions described here.
Only Administrator-level personnel should attempt to stop PSUB jobs using these solutions. Use these strategies, in the order they are listed, to stop PSUB jobs.
Use the stop_psub utility.
Identify and then stop the processes that are hanging:
To identify the process that is hanging, use either:
ps -ef|grep opapps
or
ps -ef|grep userid
To stop all of the hanging processes that you identified in Step 2a, use this command:
kill -9 pid
Log in as opapps and, at a command prompt, enter:
at -l [-q]
This command lists all of the jobs that are currently in all of the queues. Each job has a unique ID number.
If there are jobs pending in the queue, the following command, which uses the unique ID number to remove specific jobs from the queue, may be of use:
at -r
id
If you are able to stop all PSUB jobs, stop and then restart the PSUB process and submit one job. If it hangs, try to isolate whether one particular module is the cause or if any PSUB job hangs, regardless of module.
If you are unable to determine a module that is causing the problem and jobs are still hanging, the only recourse is to reboot the computer.
To find out if a PSUB process is listening to a particular database, and if it is, what code environment it is running in, enter this query:
SQL> select host, code_environment, stop_ts 2 from psub_process_log 3 where start_ts = ( 4 select max (start_ts) from psub_process_log;
This query returns the:
computer on which PSUB was last started against the database
code environment
state of the process:
if stop_ts is null, the PSUB process is currently active
if stop_ts is not null, the PSUB process is stopped.
new code list
Note:
As an alternative, to find out on which computer PSUB is set up, query one of the following:OCL_STATE local reference codelist, SERVER_NAME setting
RXC.PSUB_PROCESS_LOG table
Use this information, in conjunction with the operating system-specific instructions, below, to determine if PSUB is running on a given computer.
Use this command to find out if PSUB is running on particular UNIX server:
% ps -ef | grep -i rxcpsdps
The process search command, ps, returns descriptions of the PSUB processs that are currently running. Each row that is returned represents one PSUB process running on the server. Each process has a unique product_instance and code_environment pair. The format of the response to the process search command listed above is:
rxcpsdps [verbose|nonverbose]product_instance code_environment
Use this procedure to find out if the PSUB service is running on a given Windows server.
Open the Control Panel.
Double-click the Services icon.
In the Services window, note the status of the PSUB service with the relevant database name. The status will be "Started" if the service is running.
Execution status as reported in the Submitted Batch Jobs form is shown below. You can take various actions depending on execution status.
Value | Meaning |
---|---|
ENTERED | The user has requested a job submission. |
SUBMITTED | The process submitted the job to the batch queue; it may be pending. |
SUBMIT_FAILED | The process attempted to submit the job to the batch queue but failed. |
STARTED | The job is executing on the batch queue. |
SUCCESS | The job completed with SUCCESS status. |
FAILURE | The job completed with FAILURE status. Look at the Failure Text in the Submitted Batch Jobs window for possible reasons. |
Examine the Submitted Batch Jobs window, look for the Execution Status and Failure Text for your Batch Job ID, and take one of the following actions, depending on the circumstances.
If the Execution Status of your batch job remains at ENTERED, perhaps:
The PSUB process is not running on the server, or it is not receiving the request from the client.
The corresponding Oracle user's operating system account does not exist.
The Advanced Queue is not started; see "PSUB Remains at Entered Status."
If the Execution Status of your batch job remains at SUBMITTED, perhaps:
The job is pending in the batch queue, or the batch queue is stopped.
The opapps account does not have Write permission for the user's RXC_LOG directory on the PSUB server.
A log file exists with the same number as the one for the submitted job. This is a rare situation. Delete the old log file and resubmit the job.
In the case of a PSUB job that stays in SUBMITTED status even though the PSUB process is up and running, if your .log file says:
ERROR:Error while connecting: ORA-01017: invalid username/password; logon denied Exiting...
Edit sqlnet.ora (in drive:\app\oracle\product\11.2.0.2.0\NETWORK\ADMIN):
UNIX: Comment out the following line (add # at the beginning of the line) and save.
# SQLNET.AUTHENTICATION_SERVICES = (NTS)
Windows: Make sure the same line in sqlnet.ora is not commented out (if there is a pound sign (#) at the beginning of the line, remove it and save):
SQLNET.AUTHENTICATION_SERVICES = (NTS)
If the PSUB process is still running you can now resubmit the PSUB jobs. Otherwise, stop and then start the PSUB process.
If the Execution Status of your batch job is SUBMIT_FAILED, examine the Failure Text. If this action gives no possible cause, perhaps:
The ssh command cannot be executed by the OPAPPS user. Check that the host name in the /etc/hosts.equiv file is the official name of the host as specified in /etc/hosts.
The user's password is not correct.
The batch queue does not exist. Check the Long Value of the BATCH QUEUE NAME local reference codelist.
The batch queue is in a stopped state.
If the Execution Status of your batch job remains at STARTED, perhaps:
The job is executing and waiting for some resource.
The job is hung.
If the Execution Status is FAILED, examine the Failure Text. If this action gives no possible cause, perhaps:
The report or command exited with error status.
The report or executable file does not exist.
The print command exited with failure status, because, for example, the specified print queue does not exist.
Make sure the Long Value of the SERVER_OS entry in the OCL_STATE local reference codelist is correct for your operating system. You can enter one of the following values:
NT — Indicates the server is running one of the Windows operating systems currently supported by Oracle Clinical.
UNIX — Indicates the server is running the UNIX operating system.
Check that the SERVER_NAME in OCL_STATE is set to the database/PSUB server.
Note:
On UNIX systems, the Long Value of the SERVER_NAME entry (also in OCL_STATE) must be in lowercase letters.Check that your RXC_LOG is correctly defined or modify the user's log directory via the menu path Admin, then Users, and Oracle Accounts.
Note:
You may get an error message on the Windows server about the Kernel32.DLL initialization because of too many jobs running at the same time. Stop the unwanted processes, including cmd.exe and pslaunch.exe, using the Task Manager. If the error happens frequently, stop the PSUB service, reboot the Windows server, and restart the PSUB service. This should fix the problem.If you submit a PSUB job that fails and returns a "Fatal two-task communication protocol" error (this failure is sometimes followed by the "End-of-communication-channel" in the core dump information on your console), you might have the environment variable NLS_LANG set inconsistently with the settings in the database.
To verify that the environment variable NLS_LANG matches the actual database settings:
Execute the following query:
SQL> select parameter, value from V$NLS_PARAMETERS where parameter in ('NLS_LANGUAGE','NLS_TERRITORY','NLS_CHARACTERSET');
Open opa_settings and search for the following string:
db_env_setting:database_name:NLS_LANG
If you do not find this string, add a line with the following syntax:
db_env_setting:database_name:NLS_LANG:NLS_LANGUAGE_NLS_TERRITORY.NLS_CHARACTERSET
where NLS_LANGUAGE_NLS_TERRITORY.NLS_CHARACTERSET are the values returned in Step 1.
If you find the string, correct the values to match the values in Step 1 in the following syntax:
db_env_setting:database_name:NLS_LANG:NLS_LANGUAGE_NLS_TERRITORY.NLS_CHARACTERSET
where NLS_LANGUAGE_NLS_TERRITORY.NLS_CHARACTERSET are the values returned in Step 1.
In a UNIX environment, you may see the following error when you submit a PSUB job (3GL or PLSQL):
Illegal use of PSLAUNCH by user. Job ID=batch_job_ID. Exiting...
This error can occur if the PSUB user is not using the C Shell (csh). The default shell gets set up when you create the user account. For example, on Linux, the bash shell is set by default.
Verify that all user accounts that run PSUB jobs are configured to use the C Shell (csh).
If the error continues to occur after you verify that PSUB account uses C Shell, modify $RXC_PSUB/launchps.sh
as follows:
Log on to the UNIX computer on which the PSUB process is running, as owner of the file launchps.sh
. (The owner is usually OPAPPS.)
Set environment variables for the database name and code environment; see "Setting Environment Variables on the Command Line."
Change to the $RXC_PSUB directory.
Edit launchps.sh
by adding the following line immediately before the pslaunch command:
sleep 2 pslaunch $4 $5 $6 $7 $3 $8
This command introduces a 2-second delay before the system calls pslaunch
. You may increase the delay if the error continues to occur.
To find out specific information about PSUB connections to a given database, query the table RXC.PSUB_PROCESS_LOG. This will return the:
instance
environment
time a PSUB process started
time a PSUB process stopped.
If PSUB does not start; for example, after installing or upgrading:
Check one line in sqlnet.ora (in drive:\app\oracle\product\11.2.0.2.0\NETWORK\ADMIN):
UNIX: Edit sqlnet.ora by commenting out the following line (add # at the beginning of the line) and save it.
# SQLNET.AUTHENTICATION_SERVICES = (NTS)
Windows: Make sure the same line in sqlnet.ora is not commented out (if there is a pound sign (#) at the beginning of the line, remove it and save):
SQLNET.AUTHENTICATION_SERVICES = (NTS)
Locate and ensure that these lines in init.ora are not commented out and the values are as specified:
remote_os_authent=null
os_authent_prefix=""
(a null string)
Shutdown the database.
Start the database.
Start PSUB.
If PSUB remains at Entered status, you may need to manually restart the AQ process:
Stop PSUB, see "Starting and Stopping PSUB.".
Log in as sysdba.
Enter:
EXEC DBMS_AQADM.START_QUEUE('RXC.PSUB_REPLY_QUEUE',TRUE,TRUE); EXEC DBMS_AQADM.START_QUEUE('RXC.PSUB_SEND_QUEUE',TRUE,TRUE);
Restart PSUB.
Rerun the job.
If you have difficulty starting PSUB on a Windows database after upgrading to or installing Oracle Clinical:
Open the sqlnet.ora file and confirm that following line is not commented (that is, there is no '#' at the beginning of the line). If there is, uncomment the line (remove the #):
sqlnet.authentication_service=(NTS)
Attempt to start PSUB.
If PSUB fails to start:
Open the init.ora file. Ensure that the following lines are not commented out and have the values specified. If not, uncomment and/or change the values.
remote_os_authen=NULL os_authent_prefix="OPS$"
Shut down any databases on the Windows server, then start the databases.
You can trace a session connected to the Oracle Clinical Database and generate a log file. The following example explains how to run a trace while in the Maintain DCM form.
Start a SQL*Plus session as SYS, or another user with the DBMS_SYSTEM role.
Find the session ID and serial number of the Oracle Clinical user working in the Maintain DCM form:
select sid, serial# FROM v$session where username = '
userid
';
Assume that 8 and 12 are returned for sid and serial#, enable SQL trace for the user as follows:
exec dbms_system.set_sql_trace_in_session(8,12,TRUE)
Have user perform the operation that causes the error. After the error is returned disable SQL trace:
exec dbms_system.set_sql_trace_in_session(8,12,FALSE)
Find the trace file out in your USER_DUMP_DEST directory. For example,
select value from v$parameter where name = 'user_dump_dest';
where value is the path, something like, /ind/oraclelogs/maria/db/udump. The trace file is placed in this directory.
The following problems are related to the Oracle Clinical Report Server.
Oracle Clinical reports may:
display field values that appear truncated
display dates as ******
To fix this issue, change the display setting on Windows to 150%.
From the Windows Control Panel, navigate to Ease of Access, then Optimize, then Visual Display.
If the Windows 2008 R2 application server is accessed using remote desktop, you may need to apply a Microsoft Windows patch - 2726399 to be able to modify the setting.
This problem can arise if you add separate Reports Servers to an installation with no Forms Servers configured to support them. For separate Reports Servers to work, you must set up registry settings on each separate Reports Server and a Forms Server, and share directories on the Forms Server. See "Setting Up Image Viewing" and OPA_XMLTEMP_UNC and OPA_XMLTEMP_HTTP for more information.
Check if this is a scheduled job. If it is, use the Oracle AS10gR2 Enterprise Manager to stop it. Navigate to Action, Report Queue Manager from any screen, or Admin, PSUB/Report Jobs, Enterprise Manager. The Report Queue Manager window opens. The instructions vary by manager version, so follow the instructions in the window to stop the job.
When invoking webservices from client, you may get the following error:
Error invoking 'getServiceProperty':'oracle.fabric.common.xml.xpath.XPathFunctionException: oracle.apps.aia.core.config.PropertyNotFoundException: Property Not Found (SystemConfiguration/Default.SystemID)'
To resolve the issue:
In the PATH environment variable, add the JDK path as C:\Oracle\Java\jdk\bin;
Add the Managed Server (the server where wsdl .ear is deployed) in the config.xml file:
Take a backup of the config.xml file under $DOMAIN_HOME/config as config.xml_bkp and open config.xml.
Search for the string oracle.wsm.seedpolicies
.
The current entry has only the AdminServer deployment location. Add the Managed Server separated by a comma as shown below:
<library>
<name>oracle.wsm.seedpolicies#11.1.1@11.1.1</name>
<target>AdminServer,AIAServer1</target>
<source-path>C:/Oracle/Middleware/oracle_common/modules/ oracle.wsm.policies_11.1.1/wsm-seed-policies.jar</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</library>
Restart the Managed Server.