An application uses Oracle Enterprise Scheduler to execute jobs on the application's behalf. When the application wants to execute a job, it sends a job request to Oracle Enterprise Scheduler. You configure those jobs by using job definitions that specify the job's parameters and associate them with the application. When you want to group together a collection of job requests, you create a job set.
The work of administering job requests includes submitting requests, searching for existing requests and viewing information about them, and pausing and canceling requests. You can do these tasks with Fusion Middleware Control Console.
This section contains the following topics:
You can submit a job request by choosing a job definition that defines the metadata you want and by defining a schedule that guides when the job runs.
This section contains the following topics:
You create a job request by selecting a job definition for the job request, then selecting or creating a schedule.
You may want to configure system properties for the job request, such as the number of retries to attempt in the event of an execution error and a time out value for the job.
To submit a job request:
Use a pre-existing job definition. You can also first create a new job definition, as described in Creating or Editing a Job Definition.
Navigate to the Submit Job Request page by clicking the Scheduling Service menu selecting Job Requests, then selecting Submit Job Request.
Select the application for which you want to submit the job request.
From the Application dropdown list, select the application deployment name.
Under Job Request Details, enter a description of the job request in the Submission Notes text field.
Select a job definition.
Under Job Definition, click the search button next to the Job Definition text field.
Search for the required job definition.
In the Name text field, enter the name of the job definition you want to find. You can also enter the job definition's package in the Package field.
Click Go to search for the job definition.
From the search results table, select the job definition name.
Click OK.
In the Parameters region, optionally define any parameters you want to use with the scheduled job request.
In the Job Parameters region, click Add to add a parameter.
Fill in a name and value for the parameter.
You can set a value for any of the system properties available.
For example, you may want to configure the number of permissible retries for the job (SYS_retries), or a time out value (SYS_request_timeout).
Select a schedule by which the job is to run.
Once: Select a single date and time by clicking the Calendar button.
Use existing schedule: Click the search button to search for and select an existing schedule. For more on defining saved schedules, see Creating or Editing Predefined Job Schedules.
Specify schedule: Create your own schedule on the fly. Follow the instructions in Specifying a Job Request Schedule
Click OK.
In the Submit Job Request page, selecting Specify schedule enables configuring your own schedule for a job request. You can configure a recurring job request using a job request schedule. Alternatively, you can configure a job request to run immediately or before a specified end date. Use a pre-existing job definition, or create a new job definition, as described in Creating or Editing a Job Definition.
To specify a schedule:
The Request Search page enables searching for job requests. Using the Request Search page, you can:
Conduct a quick search by selecting a pre-configured search option from the Quick Search dropdown menu.
Conduct a basic search that returns a list of job request details, including job request ID, executing application, job request status, and so on.
Conduct an advanced search based on Run Time/Wait Time, Retry of Failed Runs, Date Range, Error Type and Request ECID/Correlation Flow ID along with the fields available as part of Basic Search.
Modify the column display in the search results table.
This section contains the following topics:
Basic search allows you to find a job request according to particular criteria such as job request ID, related application, job request status, and so on, or by any one of a number of pre-configured quick searches.
To search for a job request:
An advanced search is available in the Request Search page by clicking the Advanced button.
To search for a job request:
You can define and save schedules for later use in submitting job requests.
Navigate to the Schedules page by clicking the Scheduling Service menu, selecting Job Requests, then selecting Define Schedules.
On the Schedules page, you can choose one of the following actions:
To create a new schedule:
From the Application dropdown list, select the name of the application for which you want to create a schedule.
Click Create.
Enter the following information:
Name: Enter a name for the schedule. This is the name that appears when you assign the schedule to a job request.
Package: Optionally enter the name of a Java package related to this schedule if it helps you find or group schedules.
Description: Optionally enter a description.
From the Frequency dropdown, select how often you want job requests using this schedule to run. Each frequency option has its own way to specify details for the option As you specify details, note that you can click Select date and time icons to specify time zones as well.
Click OK.
To view details for an existing schedule:
In the Results area, locate the schedule whose details you want to view.
From the Application dropdown list, select the name of the application whose schedules you want to view.
In the Name column, click the schedule's name.
From the Schedule Details page, you can remove schedule times or click the Edit button to edit schedule details.
To edit an existing schedule:
In the Name and Package fields, enter values to search for.
Click Go to search.
In the Results area, locate the schedule you want to edit.
Select the schedule you want to edit, then click Edit.
On the Edit Schedule page, edit details about the schedule.
Click OK.
You can view detailed information about an individual job request by clicking the job request ID or the request parent ID in job request search results. If the job is in an error state, an information box displays details regarding the error that occurred. For more on searching for job requests, see Searching for Oracle Enterprise Scheduler Job Requests.
You can take the following actions on an individual job request:
Display log information for the job request.
Display the job set and all child job requests.
Submit a job or job set request with parameters similar to those of a given job request.
Recover an incomplete job request.
To view job request details:
You can hold or resume a job request after it has been submitted.
To hold and resume a job request:
You can cancel an executable job request after it has been submitted. Executable job requests include job sets and job requests submitted without schedules. A job request can be canceled when it is not in a state of execution.
When initiating a job request cancellation, the resulting cancellation state depends on the current state of the job request. A job request that is not executing is set directly to CANCELLED state. A job request in RUNNING, PAUSED or COMPLETED states are placed in CANCELLING state following the initiation of request cancellation.
The final state of a request depends on the processing stage the job request at the point when cancellation has been initiated.
Table 4-1 displays the cancellation states applied to each executable request depending on its state when initiating cancellation.
Table 4-1 Executable Requests and Cancellation States
| Job State When Initiating Cancellation | New Cancellation State |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Any terminal state |
No state change |
|
|
No state change |
|
|
No state change |
An executable request is processed in three major stages: pre-processor, executable and post-processor. Requests can be canceled at any of these stages. If the job request cannot complete all three stages, it transitions to CANCELLED.
This section contains the following topics:
When initiating cancellation during the pre-processor stage, the state to which the job request transitions depends on the status returned by the pre-processor.
Table 4-2 displays the job state following cancellation initiation.
Table 4-2 Pre-processor States and States Following Cancellation Initiation
| State Returned by the Pre-Processor | State Following Cancellation Initiation |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When initiating cancellation during the job execution stage, the state to which the request transitions depends on the manner of completion.
Table 4-3 displays the job state following cancellation initiation.
Table 4-3 Returned Synchronous Java Job States and States Following Cancellation Initiation
| State Returned by the Job | State Following Cancellation Initiation |
|---|---|
|
Normal return (success) |
|
|
|
|
|
|
|
|
|
|
|
|
|
When initiating cancellation during the job execution stage, the state to which the request transitions depends on the manner of completion.
Table 4-4 displays the job state following cancellation initiation.
Table 4-4 Returned Asynchronous Java Job States and States Following Cancellation Initiation
| State Returned by the Job | State Following Cancellation Initiation |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No state change. Wait for further updates. |
|
|
|
|
|
|
If the job executable is executing, Oracle Enterprise Scheduler attempts to kill the running RDBMS Scheduler job. If the job is successfully killed, the request transitions to CANCELLED state. If the RDBMS Scheduler job completes before it can be killed, the state to which the job request transitions depends on the result of the job execution.
Table 4-5 displays the job state following cancellation initiation.
Table 4-5 Returned PL/SQL Job States and States Following Cancellation Initiation
| State Returned by the Job | State Following Cancellation Initiation |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If the spawned job is executing, Oracle Enterprise Scheduler attempts to kill the running process. If the process is successfully killed, the request transitions to a CANCELLED state. If the process completes before it can be killed, the state to which the request transitions depends on the result of the process execution.
Table 4-6 displays the job state following cancellation initiation.
Table 4-6 Returned Spawned Job States and States Following Cancellation Initiation
| State Returned by the Job | State Following Cancellation |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A parent job request that is canceled transitions to a CANCELLING state until all child requests complete or have been canceled. The cancellation operation propagates to all eligible child job requests. For example, job set steps are canceled when the job set is canceled, sub-requests are canceled when the parent request is canceled and recurring executable job requests are canceled when the recurring parent is canceled. If a child job request is executable, it is subject to the rules described in the preceding sections. When all the child requests have completed, the parent request transitions to CANCELLED state.
A child job request may be an executable or a parent job request. When canceling a sub-request that completes in CANCELLED or another terminal state, the parent job request resumes as usual as long as the parent job request has not been canceled as well. The state of the sub-request does not affect the state of the parent request.
When canceling a step within a job set, the job set transitions to a CANCELLED state when the job set step transitions to a CANCELLED state. However, the job set may not revert to CANCELLED state if another job set step results in an error.
To cancel a job request: