All About Output Post Processor (OPP) in Oracle Applications
The integration of XML Publisher within Concurrent Processing is done by means of a specialized concurrent manager called the Output Post Processor (OPP). If a request is submitted which has an XML Publisher template specified as a layout for the 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.
An overview of the actions involved:
1. An application user submits an XML Publisher based report.
2. The standard concurrent manager processes the request.
3. The XML data file is generated by the standard concurrent manager. This can be done by various methods:
o Oracle Reports - Report Definition File (RDF)
o XML Publisher Data Template - XML data template linked to the Data Definition
o Any other process that produces XML output
4. A post processing action defines that the output needs to be generated by the Output Post Processor hence it is triggered by the standard manager.
5. The Output Post Processor generates the final report and informs the standard concurrent manager whether that was successful.
6. The standard concurrent manager finalizes the concurrent request.
Processes in OPP:
There should always be at least one OPP process active in the system. If no OPP service is available to process concurrent requests, completed requests that require OPP post-processing will complete with a status of Warning.
One service instance of the OPP service is seeded by default. This seeded OPP service instance has one workshift with one process.
A concurrent manager contacts an available OPP process when a running concurrent request needs an OPP post-processing action. Concurrent managers use a local OPP process (on the same node) by default, but will choose a remote OPP if no local OPP process is available.
Threads in OPP:
The OPP Service is multi-threaded and will start a new thread for each concurrent request it processes. You can control the number of simultaneous threads for an OPP Service Instance by adjusting the Threads per Process parameter for the instance.
If all the OPP process has reached their respective maximum number of threads, the requests waiting to be processed remain in a queue to be processed as soon as threads become available. If request throughput has become slow, you may want to increase the number of Threads per Process for the OPP.
The number of concurrent requests that the Output Post Processor can handle in parallel depends upon:
· the number of Processes
· the number of Threads Per Process
The default values are 2 Processes and 5 Threads per Process so a total of 10 reports can be processed in parallel.
Issues with OPP:
1. Timeout issue with OPP:
Example:
There is 1 OPP process with 2 threads. Hence 4 reports can be processed at any time.
- In case there are other concurrent requests running which have already invoked the OPP then it might happen that no additional requests can be picked up for a period of time. The pending request will be picked up as soon as one of the running jobs completes.
By default a timeout will occur if it takes longer than 120 seconds (2 min.) for the Output Post Processor to pick up the request from the concurrent manager process. In that case, the concurrent request will complete with status Warning.
-Once the Output Post Processor picks up the request, the BI Publisher engine is invoked to generate the final output file. The time that this takes will depends on various elements such as:
· size of the XML Data File
· complexity of the template
· performance of the server
By default a timeout will occur if it takes longer than 300 seconds (5 min.) for the BI Publisher engine to generate the output file. The concurrent request will complete with status Warning
Solution:
There are 2 new profiles options that can be used to control the timeouts.
Profile Option : Concurrent:OPP Response Timeout
Internal Name : CONC_PP_RESPONSE_TIMEOUT
Description : Specifies the amount of time a manager waits for OPP to respond to its request for post processing.
Profile Option : Concurrent:OPP Process Timeout
Internal Name : CONC_PP_PROCESS_TIMEOUT
Description : Specifies the amount of time the manager waits for the OPP to actually process the request.
The value for the above profile options can be increased to avoid timeouts.
The number of processes/threads for OPP can also be increased; however the concurrent manager has to be restarted for the changes to take effect.
2. Output Post Processing Fails Due To java.lang.ThreadDeath
-Increase the value of the Concurrent:OPP Timeout profile option to 10800 seconds.
-Enable the scalability feature of XML Publisher:
a. Login as SYSADMIN
b. Responsibility: XML Publisher Administrator
c. Function: Administration
d. Set the following properties:
e. Temporary Directory
f. Use XML Publisher's XSLT processor: True
g. Enable scalable feature of XSLT processor: True
h. Enable XSLT runtime optimization: True
- Restart the Concurrent Managers so that changes take effect
3. Output Post Processor is Down with Actual Process is 0 And Target Process is 1
This can happen on a cloned instance.
- FNDSVC should exist under FND_TOP/bin
- Bring down all application services and relink the FNDSVC through adadmin or using the below command:
adrelink.sh force=y ranlib=y "FND FNDSVC"
- Restart all applications services and restest the issue.
4. Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError: Java heap space
- Determine what the heap size per OPP process is currently:
select DEVELOPER_PARAMETERS from FND_CP_SERVICES
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');
- The default should be:
J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m
- Increase the Heap Space per Process to 1024:
update FND_CP_SERVICES
set DEVELOPER_PARAMETERS =
'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx1024m'
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');
- Bring the Concurrent managers down.
-Run cmclean.sql script from Note 134007.1 - CMCLEAN.SQL Non-Destructive Script to Clean Concurrent Manager Tables.
-Bring the managers up again.
OR
-Log into applications with the System Administrator responsibility.
- Navigate to Concurrent -> Program -> Define
-Query the XML Publisher Template Re-Generator program
-Set the following value for the Executable Options: -Xmx1024m
- Save changes.
- Retest the program.
The integration of XML Publisher within Concurrent Processing is done by means of a specialized concurrent manager called the Output Post Processor (OPP). If a request is submitted which has an XML Publisher template specified as a layout for the 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.
An overview of the actions involved:
1. An application user submits an XML Publisher based report.
2. The standard concurrent manager processes the request.
3. The XML data file is generated by the standard concurrent manager. This can be done by various methods:
o Oracle Reports - Report Definition File (RDF)
o XML Publisher Data Template - XML data template linked to the Data Definition
o Any other process that produces XML output
4. A post processing action defines that the output needs to be generated by the Output Post Processor hence it is triggered by the standard manager.
5. The Output Post Processor generates the final report and informs the standard concurrent manager whether that was successful.
6. The standard concurrent manager finalizes the concurrent request.
Processes in OPP:
There should always be at least one OPP process active in the system. If no OPP service is available to process concurrent requests, completed requests that require OPP post-processing will complete with a status of Warning.
One service instance of the OPP service is seeded by default. This seeded OPP service instance has one workshift with one process.
A concurrent manager contacts an available OPP process when a running concurrent request needs an OPP post-processing action. Concurrent managers use a local OPP process (on the same node) by default, but will choose a remote OPP if no local OPP process is available.
Threads in OPP:
The OPP Service is multi-threaded and will start a new thread for each concurrent request it processes. You can control the number of simultaneous threads for an OPP Service Instance by adjusting the Threads per Process parameter for the instance.
If all the OPP process has reached their respective maximum number of threads, the requests waiting to be processed remain in a queue to be processed as soon as threads become available. If request throughput has become slow, you may want to increase the number of Threads per Process for the OPP.
The number of concurrent requests that the Output Post Processor can handle in parallel depends upon:
· the number of Processes
· the number of Threads Per Process
The default values are 2 Processes and 5 Threads per Process so a total of 10 reports can be processed in parallel.
Issues with OPP:
1. Timeout issue with OPP:
Example:
There is 1 OPP process with 2 threads. Hence 4 reports can be processed at any time.
- In case there are other concurrent requests running which have already invoked the OPP then it might happen that no additional requests can be picked up for a period of time. The pending request will be picked up as soon as one of the running jobs completes.
By default a timeout will occur if it takes longer than 120 seconds (2 min.) for the Output Post Processor to pick up the request from the concurrent manager process. In that case, the concurrent request will complete with status Warning.
-Once the Output Post Processor picks up the request, the BI Publisher engine is invoked to generate the final output file. The time that this takes will depends on various elements such as:
· size of the XML Data File
· complexity of the template
· performance of the server
By default a timeout will occur if it takes longer than 300 seconds (5 min.) for the BI Publisher engine to generate the output file. The concurrent request will complete with status Warning
Solution:
There are 2 new profiles options that can be used to control the timeouts.
Profile Option : Concurrent:OPP Response Timeout
Internal Name : CONC_PP_RESPONSE_TIMEOUT
Description : Specifies the amount of time a manager waits for OPP to respond to its request for post processing.
Profile Option : Concurrent:OPP Process Timeout
Internal Name : CONC_PP_PROCESS_TIMEOUT
Description : Specifies the amount of time the manager waits for the OPP to actually process the request.
The value for the above profile options can be increased to avoid timeouts.
The number of processes/threads for OPP can also be increased; however the concurrent manager has to be restarted for the changes to take effect.
2. Output Post Processing Fails Due To java.lang.ThreadDeath
-Increase the value of the Concurrent:OPP Timeout profile option to 10800 seconds.
-Enable the scalability feature of XML Publisher:
a. Login as SYSADMIN
b. Responsibility: XML Publisher Administrator
c. Function: Administration
d. Set the following properties:
e. Temporary Directory
f. Use XML Publisher's XSLT processor: True
g. Enable scalable feature of XSLT processor: True
h. Enable XSLT runtime optimization: True
- Restart the Concurrent Managers so that changes take effect
3. Output Post Processor is Down with Actual Process is 0 And Target Process is 1
This can happen on a cloned instance.
- FNDSVC should exist under FND_TOP/bin
- Bring down all application services and relink the FNDSVC through adadmin or using the below command:
adrelink.sh force=y ranlib=y "FND FNDSVC"
- Restart all applications services and restest the issue.
4. Output Post Processor (OPP) Log Contains Error "java.lang.OutOfMemoryError: Java heap space
- Determine what the heap size per OPP process is currently:
select DEVELOPER_PARAMETERS from FND_CP_SERVICES
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');
- The default should be:
J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m
- Increase the Heap Space per Process to 1024:
update FND_CP_SERVICES
set DEVELOPER_PARAMETERS =
'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx1024m'
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');
- Bring the Concurrent managers down.
-Run cmclean.sql script from Note 134007.1 - CMCLEAN.SQL Non-Destructive Script to Clean Concurrent Manager Tables.
-Bring the managers up again.
OR
-Log into applications with the System Administrator responsibility.
- Navigate to Concurrent -> Program -> Define
-Query the XML Publisher Template Re-Generator program
-Set the following value for the Executable Options: -Xmx1024m
- Save changes.
- Retest the program.
No comments:
Post a Comment