When a BI-published concurrent program uses an XML Data Template  to generate large quantities of data (for example the standard Account Analysis Report [XLAAARPT], in the Subledger Accounting application), the report may fail with the following error (in the log file):

Calling XDO Data Engine...
****Warning!!! Due to high volume of data, got out of memory exception...***
****Please retry with scalable option or modify the Data template to run in scalable mode...***
********************************************************************************

The problem is caused by the standard Java Concurrent Program, XML Publisher Data Template Executable [XDODTEXE], and the memory allocated to the program’s Java Virtual Machine (JVM) which is created at runtime by Oracle Applications.

There appear to be a number of ways to tackle this problem.

The quickest way seems to be entering the text string
-Xss2048k -Xmx2048m
…to the Executable Options field in the Concurrent Program definition screen:

-Xss: sets the JVM stack size (to 2MB in the above example).

-Xmx: sets the maximum memory (“heap size”) allocated to the JVM. In above example it is set to 2GB, which is the maximum usable memory for the 32-bit JVM used by the eBusiness Suite.

The JVM’s heap size can also be set (by a DBA) at site level, although I haven’t found it necessary to do this. To see what the value is set to, run the following query:

SELECT developer_parameters
FROM   fnd_cp_services
WHERE  service_id =
(
SELECT manager_type
FROM   fnd_concurrent_queues
WHERE  concurrent_queue_name = 'FNDCPOPP'
)

It is updated using SQL, and then the Concurrent Managers must be bounced:

UPDATE fnd_cp_services
SET    developer_parameters = 'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx2048m'
WHERE  service_id =
(
SELECT manager_type
FROM   fnd_concurrent_queues
WHERE  concurrent_queue_name = 'FNDCPOPP'
)

Oracle also recommend creating a Scalable Flag for the concurrent program (see Metalink Note 737311.1), but, again, I haven’t found it necessary to do this.

The scalability option is set by performing these steps:

Resp: System Administrator
Nav: Concurrent > Program > Define

Query back the concurrent program, and add a parameter called P_SCALABLE_FLAG:

Enabled: Yes
Value Set: yes_no
Default Type: Constant
Default Value: Y
Display: No
Token: ScalableFlag (this value is case sensitive)

You can also create a parameter called P_DEBUG_FLAG so that the log file includes the following:

• Report SQL
• Calling XDO Data Engine and the Scalable mode on

The parameter should have the following values:

Enabled: Yes
Value Set: yes_no
Default Type: Constant
Default Value: Y
Display: No
Token: DebugFlag (this value is case sensitive)

Other memory related issues…

If the concurrent program finishes with a Warning status, and the following message appears in the log file:

+------------- 1) PUBLISH -------------+
Beginning post-processing of request 4099006 on node C-ERP-DEVORA01 at 30-MAY-2012 10:31:15.
Post-processing of request 4099006 failed at 30-MAY-2012 10:31:16 with the error message:
One or more post-processing actions failed. Consult the OPP service log for details.
+--------------------------------------+

…consult the OPP service log file which is found in $APPLCSF/$APPLLOG, and which is called something like FNDOPP107254.txt.

(The contents of the OPP service log file can also be viewed from the Applications, Resp: Systems Administrator, Nav: Concurrent > Manager > Administer, select the “Output Post Processor” and click on the Processes button, choose the Active process and click on the Manager Log button.)

If a java.lang.OutOfMemoryError appears for your concurrent request ID, configure the XML Publisher Administrator Configuration settings as follows:

Resp: XML Publisher Administrator
Nav: Home > Administration > Configuration > Properties > General > Temporary Directory

Check that the temporary directory location (/tmp, in the above example) is at least 5GB or 20 times larger than largest XML data file that you generate. You can check the available space using the UNIX command df -h, as follows:

server1$ df -h /tmp
Filesystem             size   used  avail capacity  Mounted on
swap                    34G    17M    34G     1%    /tmp

It may also be necessary to set some FO Procesing properties on this page (although I haven’t had to do this, and the settings may require the application of one or two BI-Publisher-related patches – see Metalink Note 737311.1):

Use XML Publisher’s XSLT processor = True
Enable scalable feature of XSLT processor = False
Enable XSLT runtime optimization = True

For further information, see Metalink Notes:

737311.1: “How to Configure the Account Analysis Report in Release 12 for Large Reports”.

1410160.1: “Troubleshooting Known XML Publisher and E-Business Suite (EBS)”. “Integration Issues