2 Planning Job Development

The Oracle Enterprise Scheduler is flexible and provides implementation and deployment options. Some options use out-of-the-box components that are simpler to implement, while other options are more complex but allow for a great deal of customization. This chapter describes the different options you should consider when planning your Oracle Enterprise Scheduler deployment.

This chapter includes the following sections:

2.1 Job Development Flow

This section describes the steps in the job development process and describes the options available for each step.

Figure 2-1 contains a diagram that shows the Oracle Enterprise Scheduler components.

  1. Create and deploy the hosting application. You have the following options:

    • Use the pre-deployed native hosting application instead of creating a hosting application.

    • Generate and deploy the hosting application from an Ant script.

    • Use JDeveloper to create the hosting application from scratch and then deploy it.

  2. Create and deploy the UI or client application. You have the following options:

    • The client application uses the thin client shared library.

    • The client application uses the client library.

    • Use Oracle Enterprise Manager Fusion Middleware Control as the client application instead of creating a UI or client application.

  3. Create and deploy the job implementation. You have the following options:

    • For non-Java-based jobs, you can implement and deploy the job independent of Oracle Enterprise Scheduler.

    • For Java-based jobs, the Java class must be part of a custom hosting application.

  4. Create job metadata. You have the following options:

    • Define the metadata in Oracle Enterprise Manager Fusion Middleware Control.

    • Use Oracle JDeveloper to create predefined/seeded job metadata for deployment as part of the hosting application.

    • Programmatically create the job metadata using the metadata service API.

  5. Provide submission and metadata permissions to the deployed job. You have the following options:

    • Use Oracle Enterprise Manager Fusion Middleware Control to specify permissions.

    • Provision permissions as part of your hosting or client application EAR deployment.

    See chapter Oracle Enterprise Scheduler Security for more information.

Figure 2-1 Oracle Enterprise Scheduler Components

Description of Figure 2-1 follows
Description of "Figure 2-1 Oracle Enterprise Scheduler Components"

2.2 The Hosting Application

Jobs execute in the context of a hosting application. If the job is remote (for example, an EJB), the job is invoked in the hosting application. The pre-deployed native hosting application is convenient to use, but cannot execute custom Java jobs.

The pre deployed native hosting application is well suited for custom remote jobs like EJB and web service jobs. See Using the Pre-Deployed Native Hosting Application for details about the pre-deployed native hosting application.

See chapter Using Oracle JDeveloper to Generate an Oracle Enterprise Scheduler Application for more information about developing a custom hosting application using JDeveloper.

See Using Ant to Generate a Hosting Application for more information about developing a custom hosting application using the Oracle Enterprise Scheduler Ant script.

2.3 The Client Application

Client applications are J2EE applications that are typically used to:

  • Submit jobs

  • Request status

  • Read job output and logs

  • Possibly, host EJB job implementations that Oracle Enterprise Scheduler can invoke remotely

Client applications can be combined with a hosting application, but this is not a best practice.

Deploying a client application to a server other than the Oracle Enterprise Scheduler server is an advanced use case and requires use of Oracle Enterprise Scheduler internal templates that are only available to other Oracle embedding products.

Client applications use the thin client shared library or the client shared library. The main differences between the two libraries are:

  • The thin client shared library does not depend on the Oracle Enterprise Scheduler server or any of the Oracle Enterprise Scheduler data sources being deployed and is ideal if Oracle Enterprise Scheduler deployment is optional. The thin client shared library contacts a hosting application to access the Oracle Enterprise Scheduler metadata and runtime store to do its work.

  • The client shared library has an advantage. The Oracle Enterprise Scheduler server need not be running to submit the job and query status because the library allows direct access to the Oracle Enterprise Scheduler metadata and runtime store. It is recommended for use when the client application is co-located on the same WebLogic server as the Oracle Enterprise Scheduler

  • Developing client applications using the thin client shared library is easier because the client application is not required to have an adf-config.xml file to talk to MDS or have Oracle Enterprise Scheduler EJB deployment descriptors that the client shared library requires.

If the metadata is not automatically provisioned by the client application at deployment time, then the thin client application does not depend on the Oracle Enterprise Scheduler MDS data source.

Refer to Creating a Thin Client Application for more information about creating a client application.

2.4 Create the Job Implementation

You use different job implementations for non-Java_based jobs, Java-based jobs, and EJB jobs.

For non-Java-based jobs (PL/SQL and binary process jobs), you can implement, setup and deploy the process binaries or PL/SQL procedures independent of Oracle Enterprise Scheduler.

For Java-based jobs, the Java implementation must conform to the Oracle Enterprise Scheduler defined interface and must be included as part of a custom hosting application.

For EJB jobs, the EJB interface must conform to an Oracle Enterprise Scheduler defined interface. The interface is in the Oracle Enterprise Scheduler shared library. See Creating and Using EJB Jobs for information about how to create an EJB job implementation.

See chapter Creating and Using Web Service Jobs for information about how to use a SOA composite as a web service job implementation.

2.5 Create Job Metadata

The simplest way to create job metadata is to define it through the Oracle Enterprise Manager Fusion Middleware Control.

You can also use JDeveloper to create metadata and place it in a MAR archive that is part of a client or hosting application and then deploy the metadata to MDS when the application is deployed. SOA Suite creates the metadata programmatically on first use using the metadata APIs.

See Using the Metadata Service for a description of the metadata API.

2.5.1 Automatic Metadata Refresh Post-Submission

Oracle Enterprise Scheduler ensures that a job request and all of its children use a consistent snapshot of metadata from submission until the request reaches a terminal state. This is accomplished by caching, at job request submission, all metadata known to be used by the request. However, this caching prevents long-running recurring requests from using important metadata changes. In order for incompatibilities to function as expected, new and updated incompatibilities must apply to all relevant requests, whether previously or newly submitted. For job metadata, customizable parameters might have changed and should apply to previously submitted requests. For example, the request category on a job definition might have changed and this must be applied to pre-existing requests so that work allocation functions as expected.

To address these issues, Oracle Enterprise Scheduler automatically refreshes metadata for previously submitted requests that are:

  • Singleton requests that have not yet run

  • Recurring requests that have more recurrences to run

Cached metadata remains consistent during execution of an instance request tree that consists of the instance parent and all child requests of that instance parent, including jobset steps and sub-requests. For a singleton request, the instance request tree includes the submitted request and any child requests. For a recurring request, each recurrence is an instance request tree that includes the instance parent and any child requests of that instance parent.