Generating Reports using Oracle Enterprise Scheduling Services (ESS)

Let me start of by stating that Oracle ESS does not provide any in-built mechanism or feature for generating reports. Oracle Business Intelligence Publisher (BIP) is the report generation and delivery engine for Fusion Applications and ESS simply takes advantage of this.

Here is some high level information on how ESS-BIP job submission works. The best part for application developers is that, they do not have to implement the code to invoke BIP from ESS; they just need to focus on defining the ESS job definition using  BIP or Java JobType and specify the report attributes. ESS invokes the BIP agent API to submit a job report request, which will be picked up by the BI Publisher report processors. BIP agent API implementation internally calls asynchronous web service to generate data and process all delivery channels for that job report request. As part of ESS-BIP job submission, request parameters like requestId, job definition, job package name etc are updated in the ApplSession, which is propagated to the BIP server. Callback to the configured ESS web service happens after BIP finishes a report job.

ESS global submission user interface 'Output' tab provides options through which an end user can specify layout templates for reports, document formats (PDF, RTF), and report destinations (email, fax, printer). Depending on the file management group (FMG) property set for the ESS job definition, the relevant post-processing action is selected for the job. Post-processing actions can also be invoked programmatically from a client using a Java or web service API.

Also, you might want to check out the BI Publisher report bursting capability, where in report will slice the data to generate multiple output files by identifying required format and delivery options during report runtime. Each output can be delivered to multiple delivery channels. ESS Central Submission UI allows developers to specify bursting or non bursting using property name 'outputCollection' with value 'Y' or 'N'. Value 'N' indicates that no further BI report post processing action should be allowed.

Note that Report output (bursting and regular BIP report) will be stored in BIP repository.

As always, please refer the official Oracle ESS/Fusion Apps Developers Guide for more details.

Oracle ESS FND Data Security

In the Oracle Enterprise Scheduling Services (ESS) world, the mechanism to protect job request information is data security. ESS relies on the Oracle Fusion Data Security technology to implement data security and enforce security authorization for a specific data record or a set of records. Data security provides access control within Oracle Fusion applications on the data a user can access and the actions a user can perform on that data.

An overview of the high level steps involved in securing ESS request data is shown below:

Note: ESS Request History Access Control feature depends on FND_GRANTS, and so depends on FND_SESSION (application session). The application user session is the session that Oracle Fusion Data Security expects to see. Creating a ViewObject using ESS REQUEST HISTORY table will bypass ESS data security, as it is not protected by Virtual Private Database (VPD); and therefore it is strongly discouraged to do so. Moreover, this approach will lead to inconsistent behavior with ESS data security model.

Remember to always check the official Oracle ESS documentation for latest information on this topic ...

Introduction to Oracle Enterprise Scheduling Services (ESS)

The much awaited Oracle Fusion Applications release is finally out (in the later half of 2011) and with this the Oracle Enterprise Scheduling Services (ESS) application enters the Oracle marketplace.  So, what is Oracle ESS - a batch processing application? The official Oracle documentation describes ESS as an enterprise application that provides time and schedule based callbacks to other applications to run their jobs. In simple technical terminology, ESS is primarily a J2EE application that is deployed to the Oracle Weblogic Server providing scheduling services for distributed job request processing across a grid of application servers. 

Oracle Fusion Applications is a deployment of applications product offerings built on the Oracle Fusion Middleware technology stack and the Oracle Database. Oracle ESS is not currently shipped as a separate product offering, but is generally available with the Fusion Applications product offerings. All the Fusion Applications product families (for e.g. Fusion - HCM, CRM, Financials, Projects) heavily use the ESS functionality to offload larger business transactions processing to run at a future defined schedule and monitoring of job requests. 

In the Oracle e-Business suite, “Concurrent Manager” served several important administrative, batch processing and report generation functions to ensure that the Oracle Applications are not overwhelmed with job requests.  Similarly, in the context of Oracle Fusion Apps, “ESS” complements the functionality of ‘Concurrent Processing’ and is a key component for the Fusion Applications, performing important transaction processing, monitoring and notification functions.

Oracle ESS provides the ability to run different job types, including: Java, PL/SQL and spawned jobs. For now, I will leave you with a high level snapshot of the possible ESS execution methods commonly used in Fusion Apps: