Output Post Processor (OPP)
Concurrent Processing now uses the Output Post Processor (OPP) to enforce post-processing actions for concurrent requests. Post-processing actions are actions taken on concurrent request output.
An example of a post-processing action is that used in Concurrent Processing support of XML Publisher. If a request is submitted with an XML Publisher template specified as a layout for the concurrent request output, then after the concurrent manager finishes running the concurrent program, it will contact the OPP to apply the XML Publisher template and create the final output.
Monitor the workload of OPP
The OPP uses 'Advanced Queue' to find the pending requests that it needs to process, hence it becomes difficult to configure (or) do sizing of OPP without knowing the workload. When OPP begins to process a concurrent request, it will update the processor_id column of fnd_conc_pp_actions with its concurrent_process_id.
We can use the following query to find pending requests against OPP:
select REQUEST_ID,PHASE_CODE,STATUS_CODE from fnd_concurrent_requests
where request_id in (
select concurrent_request_id
from fnd_conc_pp_actions
where action_type >= 6
and processor_id is null)
and PHASE_CODE!='C';
where request_id in (
select concurrent_request_id
from fnd_conc_pp_actions
where action_type >= 6
and processor_id is null)
and PHASE_CODE!='C';
Once we estimate the number incoming requests of the OPP, we can do the sizing appropriately
Tuning OPP to Improve Performance
The parameter max_threads controls the maximum number of request threads. This number may be increased depending on the workload. Oracle recommendation is to keep the number of Threads per Process between 1 and 20.
The more threads that are set the more reports are processed simultaneously, but if all the reports being processed have large data files and complex templates, then this could impact performance, or cause the report creation to fail. If the reports are all very small reports then higher thread counts can be used safely.
There are many site specific factors that needs to be considered for optimum CP throughput: from machine hardware, to user request volume, to required Work Shifts, to programs run time characteristics (long / short running).
Tuning Heap Size to avoid OutOfMemoryError
The most common error in OPP is OutOfMemoryError. One can increase the heap size to prevent this error. Ensure that one has sufficient free RAM before increasing heap size.
For example: One is setting heapsize to 2 GB and assume you have 2 processes. Then one should have 4 GB free RAM. Otherwise increasing the heapsize of OPP, can prevent OPP from coming up.
Monitor AQ$ tables
The AQ$_FND_CP_GSM_OPP_AQTBL_H is a history table. We need to purge the AQ$ tables using the oracle provided method to ensure OPP running without any issues. Below are high level steps for the same.
- select count(*) from applsys.FND_CP_GSM_OPP_AQTBL ;
- Run the below script as apps user
DECLARE
po dbms_aqadm.aq$_purge_options_t;
BEGIN
po.block := FALSE;
DBMS_AQADM.PURGE_QUEUE_TABLE(
queue_table => 'APPLSYS.FND_CP_GSM_OPP_AQTBL',
purge_condition => NULL,
purge_options => po);
END;
po dbms_aqadm.aq$_purge_options_t;
BEGIN
po.block := FALSE;
DBMS_AQADM.PURGE_QUEUE_TABLE(
queue_table => 'APPLSYS.FND_CP_GSM_OPP_AQTBL',
purge_condition => NULL,
purge_options => po);
END;
/
3. select count(*) from applsys.FND_CP_GSM_OPP_AQTBL ;