APEX

Hello everyone,

I'm reporting a significant regression bug in APEX 24.2 concerning report printing with BI Publisher server.

A process that worked in APEX 22.1 is now fundamentally broken.

The Scenario

We are using apex_util.download_print_document to generate a PDF report from an RTF template and a multi-query report definition from Shared Components. The problematic call signature is the one that uses a PL/SQL CLOB variable for the layout:

This code worked in 22.1 but fails in 24.2

apex_util.download_print_document (
    p_file_name           => 'my_report.pdf',
    p_content_disposition => 'attachment',
    p_application_id      => :APP_ID,
    p_report_query_name   => 'MY_MULTI_QUERY_REPORT', -- Report with 2+ SQL queries
    p_report_layout       => l_rtf_layout_clob,     -- Layout loaded into a CLOB
    p_report_layout_type  => 'rtf',
    p_document_format     => 'pdf'
);

The symptom is that this call now returns a 0-byte PDF file. After debugging the HTTP request sent from the APEX server to the BI Publisher server, I have identified two distinct bugs in this code path.

Bug 1: Incorrect templateType in Request Metadata

When using the signature above, APEX 24.2 incorrectly informs BI Publisher that the template type is xslfo instead of rtf.

• Request Sent in APEX 22.1 (Correct):

   {"templateType":"rtf", "outputFormat":"pdf", ...}
  

• Request Sent in APEX 24.2 (Incorrect):

   {"templateType":"xslfo", "outputFormat":"pdf", ...}
  

BI Publisher receives an RTF file but is told to process it as an XSL-FO file, causing the processing to fail and return an empty result.

Bug 2: Malformed XML Structure for Multi-Query Reports

For a report based on two or more SQL queries, this code path now generates a malformed XML data structure. Instead of creating uniquely named rowsets (e.g., , ), it generates multiple rowsets with the same name ().

• Correct XML Structure (as generated by the working workaround below):

      <?xml version="1.0" encoding="UTF-8"?>
      <DOCUMENT>
          ...
          <REGION>
              <ROWSET1>
                  <ROWSET1_ROW>...</ROWSET1_ROW>
              </ROWSET1>
              <ROWSET2>
                  <ROWSET2_ROW>...</ROWSET2_ROW>
              </ROWSET2>
          </REGION>
      </DOCUMENT>
  

• Incorrect XML Structure (generated by the failing code path):

      <?xml version="1.0" encoding="UTF-8"?>
      <DOCUMENT>
          ...
          <REGION>
              <ROWSET>
                  <ROW>...</ROW>
              </ROWSET>
              <ROWSET>
                  <ROW>...</ROW>
              </ROWSET>
          </REGION>
      </DOCUMENT>
  

This ambiguous XML structure is unusable by BI Publisher, as it cannot map the data to the corresponding for-each loops in the RTF template.

Working Workaround

The only way to make this work in APEX 24.2 is to adopt a two-step process. This approach calls a different internal code path which correctly generates both the metadata and the XML structure.

-- 1. Fetch the data-only XML
l_report_data_blob := apex_util.get_print_document (
    p_application_id      => :APP_ID,
    p_report_query_name   => 'MY_MULTI_QUERY_REPORT',
    p_report_layout_type  => 'rtf', 
    p_document_format     => 'xml' -- Fetch raw data
);

-- 2. Send the data and layout to the print server
apex_util.download_print_document (
    p_file_name           => 'my_report.pdf',
    p_report_data         => l_report_data_blob,
    p_report_layout       => l_rtf_layout_clob,
    p_report_layout_type  => 'rtf',
    p_document_format     => 'pdf'
);

Conclusion

The direct call to download_print_document with a CLOB layout appears to be fundamentally broken in APEX 24.2 for external BI Publisher integration. It seems to be a significant regression from previous versions.

Can the Oracle APEX team confirm this is a known issue and if a patch is planned?

Thank you.