xml-publisher Output Post Processor (OPP)

Oracle XML Publisher is a template-based publishing solution delivered with the Oracle E-Business Suite. It provides a new approach to report design and publishing by integrating familiar desktop word processing tools with existing E-Business Suite data reporting. At runtime, XML Publisher merges the custom templates with the concurrent request data extracts to generate output in PDF, HTML, RTF, EXCEL (HTML).

RDF report with tabular layout which prints in English can be converted to various user requirements like report that needs to be printed in Japanese, report output can be published on intranet, report can be printed in chart format, report output can be in Excel.

For this purpose we have only 2 options, either new RDF needs to be created or existing RDF needs to be modified.  It involves so much of processing.  We can avoid this using XML Publisher.

XML Publisher separates a reports data, layout and translation components into three manageable pieces at design time.  At runtime all the three pieces are brought back together by XML Publisher to generate the final formatted, translated outputs like PDF, HTML, XLS and RTF.

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.

If we found any issues in publishing XML publisher reports, we need to bounce OPP (output postprocessing) Manager from Concurrent–> Manager –> Administer.

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.

 

 

Nagulu Polagani

"We are all apprentices in a craft where no one ever becomes a master."