Scheduling and Fetching output of a BIP Report using Webservice

We have likely encountered a scenario where a report call fails because it exceeds the online viewing timeout or the maximum allowed file size limit for online rendering. In these situations, the standard runReport method from the ExternalReportWSSService simply isn't enough, the call will time out, leaving us with an error instead of data.

To handle these high-volume requirements, we need to shift from synchronous execution to an asynchronous scheduling model.

In this post, we will do a deep dive into how to use the ScheduleReportWSSService to programmatically schedule a report, manage its execution, and successfully fetch the output once it's ready.

Comparison: Synchronous vs. Asynchronous Report calls

		Feature ExternalReportWSSService-runReport (Online) ScheduleReportWSSService (Scheduled) Best For Small, quick data pulls Large datasets & complex logic Timeout Risk High (usually 300 seconds) None (runs in background) File Size Limit Strict limits (around 500MB of XML) Much higher thresholds as it considers formatted output lik csv Execution Synchronous (wait for response) Asynchronous (polling) Sample WSDL:  https://abcd-saasfademo1.ds-fa.oraclepdemos.com:443/xmlpserver/services/ScheduleReportWSSService?WSDL Shedule a report: Request Payload: <soap:Envelope     xmlns:soap="http://www.w3.org/2003/05/soap-envelope"     xmlns:sch="http://xmlns.oracle.com/oxp/service/ScheduleReportService">     <soap:Header/>     <soap:Body>         <sch:scheduleReport>             <scheduleRequest>                 <reportRequest>                     <attributeFormat>csv</attributeFormat>                     <parameterNameValues>                         <item>                             <name>query1</name>                             <values>          <item>c2VsZWN0ICogZnJvbSBnbF9qZV9saW5lcyB3aGVyZSByb3dudW08MTAwMA==                      </item>                             </values>                         </item>                     </parameterNameValues>                     <reportAbsolutePath>/Custom/FAH/Sumit/QBReport.xdo</reportAbsolutePath>                     <sizeOfDataChunkDownload>-1</sizeOfDataChunkDownload>                 </reportRequest>                 <saveDataOption>true</saveDataOption>                 <saveOutputOption>true</saveOutputOption>                 <schedulePublicOption>true</schedulePublicOption>             </scheduleRequest>         </sch:scheduleReport>     </soap:Body> </soap:Envelope>    Response:   <env:Envelope     xmlns:env="http://www.w3.org/2003/05/soap-envelope">     <env:Header/>     <env:Body>         <ns0:scheduleReportResponse             xmlns:ns0="http://xmlns.oracle.com/oxp/service/ScheduleReportService">             <ns3:scheduleReport                 xmlns:ns3="http://xmlns.oracle.com/oxp/service/ScheduleReportService">534382             </ns3:scheduleReport>         </ns0:scheduleReportResponse>     </env:Body> </env:Envelope>    When we successfully submit a request via the ScheduleReportWSSService,  the jobId returned in the initial response is actually the Parent Job ID. While this ID confirms submission, it cannot be used for tracking progress or downloading the final output.  For all downstream activities—such as checking status or fetching the report,we must retrieve the Child Job ID. Note: There is often a 10–15 second lag between the submission of a parent job and the spawning of the child job within the BIP scheduler.  When automating this process, our code must include a retry mechanism or a "sleep" timer to account for this delay,  otherwise, our lookup for the child ID will return empty.