Friday, August 8, 2025

OPP (Output Post Processor)

 The Output Post Processor (OPP) is an enhancement to Concurrent Processing and is designed to support XML Publisher as a post-processing action for concurrent requests. 

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.

How Output Post Processor(OPP) works:

  • An application user submits an XML Publisher based report.
  • The standard concurrent manager processes the request.
  • The XML data file is generated by the standard concurrent manager.
  • A post processing action defines that the output needs to be generated by the Output Post Processor ,So standard manager send the request in the queue of OPP
  • The Output Post Processor generates the final report and informs the standard concurrent manager whether that was successful.
  • The standard concurrent manager finalizes the concurrent request

The Output Post Processor makes use of the Oracle Streams Advanced Queuing (AQ) database feature. Every OPP service instance monitors the FND_CP_GSM_OPP_AQ queue for new messages and this queue has been created with no value specified for primary instance. This implies that the queue monitor scheduling and propagation are done in any available instance. In other words, ANY OPP service instance may pick up an incoming message independent of the node on which the concurrent request ran.

Threads and Processes for Output Post Processor(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.

For example, say you have set your Output Post Process service to one process and have set the number of threads to 1, then one request will run at a time per process, allowing it to use all the heap memory for that process that was set for the java heap memory FND_CP_SERVICES.DEVELOPER_PARAMETERS. 

If you set the number of threads to two, then the two reports will share processing space in the java heap. Three threads, then three reports will be processed in the java heap space of the single OPP process.  If you have the number of threads set to, for example 5 threads and you have set the java heap to Xmx2048m, then the 5 processes will have 2048 Mb of heap and 5 reports will be processed in the 2048 Mb of heap space. So for reports that are very large, it may necessary that the number of threads be reduced in order for there to be enough heap to process the report.

OPP processes and threads can be seen from Concurrent Manager define form

1) Logon to Applications with “System Administrator” responsibility
2) Navigate to Concurrent -> Manager -> Define
3) Query for “Output Post Processor”
4) Click on “Work Shifts” and This will show the number of processes

One service instance of the OPP service is seeded by default. This seeded OPP service instance has one work shift with one process. 

If you are on parameters, you will see the threads

oracle.apps.fnd.cp.opp.OPPServiceThread:2:0:max_threads=5

The max_threads parameter controls the maximum number of request threads. This number may be increased depending on the workload. 

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

It is suggested to increase the number of “threads” as much as possible, then start adding “Processes”, if needed. 

The limiting factor with increasing “threads” is memory, if one sets the max heap size of a JVM to 2GB, then all “threads” will share this memory.

To get optimum performance, it is suggested to keep “Processes” to a minimum. It is recommended to have 2 OPP “Processes” with more “threads”.


Profile options related to OPP: 
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.

There is no perfect number for each of the values. It entirely depends on how much load you have on the system and how many requests are being processed.
You would need to try and validate how the program and also the system performs when you make these changes. You would not want to create a new issue by resolving one.

Oracle Database & Applications R12.2 Log file locations

Many times, we forget the path for the log files since there are too many.  Below is the list of frequently used log files which can help us...