| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.1.5) Part Number E14496-02 |
|
|
View PDF |
| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.1.5) Part Number E14496-02 |
|
|
View PDF |
This chapter describes how to configure and manage Oracle Enterprise Scheduler Service and Oracle Enterprise Scheduler jobs.
This chapter includes the following topics:
Navigating to the Oracle Enterprise Scheduler Administration Pages
Viewing General Oracle Enterprise Scheduler Instance Information
Starting and Stopping Oracle Enterprise Scheduler Service Components
Oracle Enterprise Scheduler provides the ability to define, schedule and run different types of job, including: Java, PL/SQL, spawned jobs and binary scripts. You can run jobs on demand, or schedule them to run in the future.
Oracle Enterprise Scheduler provides scheduling services for the following purposes:
Distributing job request processing across a grid of application servers
Running Java, PL/SQL, spawned and binary jobs
Processing multiple jobs concurrently
Oracle Enterprise Manager Fusion Applications Control (Fusion Applications Control) allows you to start and stop, monitor, configure and manage Oracle Enterprise Scheduler services, components and job requests.
The main Oracle Enterprise Scheduler page provides an overview of the status of scheduler components, the top running and completed scheduled job requests, as well as a performance summary of scheduled job requests. You can further monitor activity and diagnose problems by examining Oracle Enterprise Scheduler logs and comparing current to historical performance data.
Drilling down to the main components of Oracle Enterprise Scheduler, you can configure job request processors and dispatchers. A job request processor is bound to a particular Oracle Enterprise Scheduler server, and is responsible for allocating threads for job requests. A job request dispatcher polls for job requests.
Once the Oracle Enterprise Scheduler components have been configured, you can define work allocation and purge policies. Work allocation definitions allow you to configure windows of time during which jobs can run (work shifts), rules that govern their execution and bindings to a particular server and request processor (work assignments). Purge policies allow you to define for a particular request processor the conditions for retaining and purging job requests associated with that request processor. You can define a schedule for managing the execution of work assignments, work shifts and purge policies.
Finally, Oracle Enterprise Manager Fusion Applications Control allows you to define, control and manage Oracle Enterprise Scheduler job metadata, including job definitions, job requests, job sets (a collection of job requests), incompatibilities (job definitions and job sets that cannot run at the same time for a given application) and schedules governing the execution of job requests.
To navigate to Oracle Enterprise Scheduler administrative tasks:
From the navigation pane, expand the farm and then Scheduling Services, and select the Oracle Enterprise Scheduler component.
The Scheduling Service home page displays. See Section 5.3 for further information about the contents of the home page.
Select the Scheduling Service menu.
The Scheduling Service menu displays the following options.
| Menu Option | Description |
|---|---|
| Home | Displays the Scheduling Service home page. For more information about the contents of this page, see Section 5.3. |
| Control | Displays the following options:
|
| Logs | The View Log Message option displays the Log Messages page for viewing the contents of event log files. See "Managing Log Files and Diagnostic Data" chapter in Oracle Fusion Middleware Administrator's Guide for more information.
The log files are stored in the following directories:
|
| Search Job Requests | Allows you to search for job requests according to particular parameters. For more information, see Section 5.7.2. |
| Submit Job Request | Allows you to submit an execution request for a particular job. For more information, see Section 5.7.1. |
| Performance | Displays the following options:
|
| Request Processor | Displays the following options:
|
| Request Dispatcher | Displays the following options:
|
| Purge Policies | Allows you to configure and manage job request purge policies including job request purge criteria, retention criteria and purge policy schedules. For more information, see Section 5.9. |
| Work Allocation | Displays the following options:
|
| Job Metadata | Displays the following options:
|
| ESS Connections | Displays a page that enables defining connections to Oracle ADF. For more information, see Section 5.12. |
| Web Services | Displays a page that provides an overview of the web services in the application including web service endpoints and application-level metrics. For more information, see Section 5.14. |
| Security | Displays the following options:
|
| General Information | Displays general details about the Oracle Enterprise Scheduler instance. For more information, see Section 5.5. |
The Scheduling Service home page provides an overview of the performance of Oracle Enterprise Scheduler components and jobs, including component status, the number of completed job requests in the last hour, as well as the processing times for running jobs.
You can use this page as a starting point for monitoring and administering Oracle Enterprise Scheduler. Figure 5-1 shows a portion of the Scheduling Service home page.
These pages contain the following regions:
The Top Ten Long Running Requests region displays the top ten long running scheduled job requests, including request ID, job run time, job definition used, executing application, job execution type and description. You can set the scope of the top ten long running requests displayed to the current scheduling service only, or all scheduling services sharing the Oracle Enterprise Scheduler repository.
The Top Ten Ready Job Requests tab displays the top ten scheduled job requests that await execution. The tab displays the same information as the Top Ten Long Running Requests tab, except the wait time displays for each job rather than the run time.
The Scheduler Components region displays the components of Oracle Enterprise Scheduler, including the job request processor and dispatcher. The tab displays the status of each component, the name of the server to which it is deployed and whether or not the component is enabled. You can start and stop each component as required.
The Completed Requests region displays the scheduled jobs completed within the last hour.
The Response and Load region displays performance monitoring statistics regarding the time required to process to job requests.
Table 5-1 describes the performance monitoring statistics in the Response and Load region.
Table 5-1 Response and Load Statistics
| Statistic | Description |
|---|---|
|
Average Processing time for Last Hour |
This metric specifies the average time required to process jobs during the last hour. |
|
Requests Completed Per Hour |
This metric specifies the number of scheduled job requests completed within the last hour. |
The Performance region displays performance data for job requests, such as processing times and wait times.
Table 5-2 describes the performance monitoring statistics in the Performance region.
Table 5-2 Performance Statistics
| Statistic | Description |
|---|---|
|
Maximum Processing Time |
This metric specifies maximum amount of time required to process a scheduled job. |
|
Average Processing Time |
This metric specifies average amount of time required to process a scheduled job. |
|
Maximum Wait Time |
This metric specifies maximum amount of time during which a scheduled job waits before running. |
|
Average Wait Time |
This metric specifies the average amount of time during which a scheduled job waits before running. |
You can run Oracle Enterprise Scheduler as a single instance or as a cluster of servers. Each Oracle Enterprise Scheduler server includes a request processor and dispatcher, both of which must be configured.
Configuring Oracle Enterprise Scheduler involves the following main steps:
Configure a cluster. Optionally, configure a cluster of Oracle Enterprise Scheduler servers.
Configure the request processor. Configure the Oracle Enterprise Scheduler component which receives and manages job requests.
Configure the request dispatcher. Configure the Oracle Enterprise Scheduler component that polls the request processor for job requests and dispatches jobs.
This section contains the following topics:
An Oracle Enterprise Scheduler cluster is created as part of an Oracle Fusion Applications installation. You may want to expand the cluster to handle a larger load. You can add new cluster nodes to an Oracle Enterprise Scheduler cluster from the Oracle WebLogic Server Console.
When scaling out an Oracle Enterprise Scheduler cluster with an additional managed server, it may be undesirable for the new server to immediately begin processing requests in the default work assignment. This could be the case if all other servers have work assignments bound in standard mode. If one or more of the running servers is using the default work assignment, however, then the present work allocation is compatible with a server using the default work assignment.
Oracle Enterprise Scheduler provides protection for a new server so that work allocations can be configured before the server begins processing jobs. When a newly added server starts for the first time, Oracle Enterprise Scheduler determines whether the default work assignment can be used. If it cannot, Oracle Enterprise Scheduler binds a pre-seeded internal work assignment (ESSInternalWA) which includes a health check job. You can use the health check job to check the server, and unbind the internal work assignment and then bind your own work assignment as required.
Note:
When determining whether the default work assignment can be used, Oracle Enterprise Scheduler considers all running servers in the group without regard to the applications that are deployed to the servers. Servers that are down are not taken into account.For more information about work assignments, see Section 5.11.1.
For more information about expanding a cluster using Oracle WebLogic Server Console, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
A work assignment must be bound to a request processor before it can process job requests. A binding can be made in one of two modes: standard (the default) or exclusive.
Standard binding mode means the request processor can process job requests as defined by the specialization rules when an active workshift is defined. If a job request is specialized to two different work assignments, either of those work assignments or the default work assignment can process the job request.
When using exclusive binding mode, job requests specialized to the work assignment are processed exclusively by that work assignment when it is active. These job requests are excluded from all other work assignments, including the default work assignment. If the work assignment does not have an active workshift, then the job request can be processed by another work assignment.
Requirements for binding a work assignment are as follows:
The work assignment must be enabled, meaning its active flag must be set.
The work assignment must have at least one workshift.
Each workshift in the work assignment must have a thread allocation of at least one.
If the workshift includes a schedule, the following must be true:
The schedule must be active, meaning it is not expired.
The workshift duration must be at least one.
A work assignment can be bound to a particular server at most one time.
A work assignment can be bound to any number of servers in the group, but all bindings must use the same mode. Within a group, a work assignment cannot be bound in standard mode on one server and exclusive mode on another server.
For more information about work assignments, see Section 5.11.
To configure a request processor:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Request Processor and then select Configure.
Under the Enable Request Processor field, enable or disable the request processor. Select the Enable Request Processor checkbox to turn on request processing.
Optionally, under the Work Assignment Bindings section, bind a work assignment to the request processor.
Add: To bind a work assignment to the request processor, click Add.
From the Select Work Assignment popup window, select a work assignment from the list and click OK.
Remove: To delete a work assignment binding from the job request processor, select a work assignment from the list of bindings and click Remove.
Exclusive Binding: Select to bind a work assignment exclusively to the request processor. The binding applies even if the work assignment is not enabled in the work assignment definition, or if the server is down. If a work assignment is bound to multiple servers, all the servers to which it is bound must use the same binding mode.
Optionally, under the Advanced Configuration section, configure the number of threads and the starvation threshold in minutes.
Thread Count: In the text field, enter the number of threads you want the processor to handle.
Starvation threshold (min): In the text field, enter the starvation threshold in minutes. The starvation threshold specifies the wait time for job requests.
Click Apply to save your changes.
Use the Configure Request Dispatcher page to enable or disable the job request dispatcher. You can also configure the polling interval for the request dispatcher.
Requests remain in waiting state in the Oracle Enterprise Scheduler repository, until the request dispatcher polls the repository for requests that are ready to run. After polling the repository, the dispatcher sets all requests to ready state. The request processor takes over control of the job requests once they have been placed in ready state.
The default maximum polling interval is 15 seconds.
To configure a request dispatcher:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Request Dispatcher and then select Configure.
Under the Enable Request Dispatcher field, enable or disable the request processor.
Select the Enable Request Dispatcher checkbox to turn on request dispatching.
Optionally, under the Advanced Configuration section, configure the polling interval for the request dispatcher. In the text Maximum Poll Interval field, enter the minimum interval at which the dispatcher polls for requests.
Click Apply to save your changes.
Oracle Fusion Applications Control enables viewing information regarding the particular instance of Oracle Enterprise Scheduler. The general information popup window displays the locations of Oracle Fusion Middleware, the domain and the target application, as well as the version of Oracle Fusion Middleware currently running and the URI of the hosting server.
To view general information about Oracle Enterprise Scheduler:
From the Scheduling Service menu, select General Information.
Oracle Fusion Applications Control displays the following information.
Target Name: The location of the target application, in this case, Oracle Enterprise Scheduler, running on the domain.
Version: The version number of Oracle Fusion Middleware.
Middleware Home: The location of the Oracle Fusion Middleware directory.
Domain Home: The full path of the domain.
Host: The URI of the hosting server.
You can start up and shut down an instance of Oracle Enterprise Scheduler from Oracle Fusion Applications Control.
The following components can be started and stopped:
Oracle Enterprise Scheduler instance.
Job request processor and dispatcher.
Note:
Stopping an Oracle Enterprise Scheduler instance or component is not recommended. Shutting down an Oracle Enterprise Scheduler component does not stop job requests from accumulating in the queue.This section contains the following topics:
The Control menu for the scheduling service allows you to start an Oracle Enterprise Scheduler instance and consequently begin managing scheduled job requests.
Note:
Stopping an Oracle Enterprise Scheduler instance or component is not recommended.To start up an instance of Oracle Enterprise Scheduler:
From the Scheduling Service menu, select Control.
Select Start Up.
To shut down an instance of Oracle Enterprise Scheduler:
From the Scheduling Service menu, select Control.
Select Shut Down.
You can start or stop a configured request processor or dispatcher from the Scheduling Service menu.
Note:
Stopping an Oracle Enterprise Scheduler instance or component is not recommended.To stop a request processor or dispatcher:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
Start the request processor or request dispatcher as follows.
To start the request processor: From the Scheduling Services menu, select Request Processor and then select Start.
To start the request dispatcher: From the Scheduling Services menu, select Request Dispatcher and then select Start.
Stop the request processor or request dispatcher as follows.
To stop the request processor: From the Scheduling Services menu, select Request Processor and then select Stop.
To stop the request dispatcher: From the Scheduling Services menu, select Request Dispatcher and then select Stop.
When prompted as to whether or not to stop the processor or dispatcher, click OK.
A job request is a request sent from a deployed application to Oracle Enterprise Scheduler to execute a job. Jobs are configured using job definitions, which specify the parameters of the job and associate them with a particular application. A job set is a collection of job requests that is grouped together.
This section contains the following topics:
You can submit a job request for a particular application using a job definition and a schedule by which you want the job to run.
This section contains the following topics:
Creating a job request involves 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, or create a new job definition, as described in Section 5.10.1.2.
Navigate to the Submit job request page by clicking the Scheduling Service menu and selecting Job Requests. Then select Submit Job Request.
Select the application for which you want to submit the job request.
From the application dropdown list, select the J2EE application deployment name.
Under Job Request Details, enter details about the job request in the Details 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 Job Definition Name text field, enter the name of the job definition you want to find.
Click the arrow next to the text field to search for the job definition.
From the search results table, select the job definition name.
In the Parameters region, optionally define any parameters you want to use with the scheduled job request.
In the 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. Table 5-9 lists the names and descriptions of system properties.
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 icon.
Use existing schedule: Click the search button to search for and select an existing schedule.
Specify schedule: Create your own schedule on the fly. Follow the instructions in Section 5.7.1.2
In the Submit Job Request page, selecting Specify a 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 Section 5.10.1.2.
To specify a schedule:
In the Start section, select the starting date and time for the job request.
Select Immediately to submit the job request right away.
Select Later to select a subsequent start date.
In the Repeating section, select the desired frequency of the job request submission schedule.
From the Repeat dropdown list, select Every N minutes, Every N hours, Every N days or Every N weeks.
In the Frequency text field, enter the number of minutes, hours, days or weeks.
In the End Date section, select the date and time at which the schedule job is to end.
No End Date: Select to specify a continuous schedule for the job request.
Specified End Date: Select to specify a particular end date for the schedule. Click the calendar icon next to the Date text field and select a date and time. Optionally, save the schedule by selecting the Save Schedule checkbox and entering a name for the schedule in the Name text field. Optionally, enter the package name and description.
The Request Search page enables searching for job requests. Using the Request Search page, you can:
Conduct a simple 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 that returns the same information as the simple search, as well as the date and time of execution, the run time or wait time of the job request, the number of retries and any error type that may have occurred during execution.
Modify the column display in the search results table.
This section contains the following topics:
Searching for a Job Request Using the Advanced Search Feature
Configuring the Display of Columns in the Search Results Table
Simple 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:
Navigate to the Request Search page by clicking the Scheduling Service menu and selecting Job Requests. Then select Search Job Requests.
Select the scope of the job request search by selecting one of the following options:
Current Scheduling Service: Select this option to search for job requests submitted only to the scheduling service with which you are currently working.
All Scheduling Services sharing the ESS repository: Select this option to search for job requests submitted to all scheduling services sharing the repository, for example all scheduling services in a cluster of scheduling services.
To run a fast search, from the Quick Search dropdown list, select a pre-configured search option as shown in the following list.
Requests submitted in the last hour
Pending requests submitted in the last 24 hours
Errored requests submitted in the last 24 hours
All running requests
All pending requests
Requests currently being retried
Requests retried in the last 24 hours
Requests that resulted in System Error in the last 24 hours
Requests that resulted in Business Error in the last 24 hours
To run a regular job request search, skip this step.
Select the criteria by which to search for job requests.
Request ID: Enter the ID of the job request for which you want to search.
Application: From the Application dropdown list, select the name of the application related to the job request for which you want to search. Alternatively, select All to search for job requests in all applications.
Status: Select the status of the job request for which you want to search. Alternatively, select All to search for job requests with all statuses. Statuses are listed in the following table.
| Statuses | ||
|---|---|---|
WAIT |
VALIDATION_FAILED |
EXPIRED |
READY |
RUNNING |
SCHEDULE_ENDED |
PENDING_VALIDATION |
BLOCKED |
WARNING |
Execution Type: Select JAVA_TYPE, SQL_TYPE or PROCESS_TYPE.
Submitted: From the dropdown list, select the time period in which the job request to be searched has been submitted. Options include Last Hour, Last 24 Hours, Last 7 Days, Last 31 Days.
Submitted By: In the text field, enter the name of the user who submitted the job request you want to find.
Job Definition: Click the search button next to the text field and select the relevant job definition name.
Work Assignment: Click the search button next to the text field and select a work assignment from the list.
Optionally, conduct an advanced search by clicking the Advanced button.
Click Search to submit the job request search.
An advanced search is available in the Request Search page by clicking the Advanced button.
To search for a job request:
Enter a basic search for a job request. Navigate to the Request Search page by clicking the Scheduling Service menu and selecting Job Requests. Then Select Search Job Requests.
Select the scope of the job request search by selecting one of the following options:
Current Scheduling Service: Select this option to search for job requests submitted only to the scheduling service with which you are currently working.
All Scheduling Services sharing the ESS repository: Select this option to search for job requests submitted to all scheduling services sharing the repository, for example all scheduling services in a cluster of scheduling services.
Select your basic search criteria. For more information, see Section 5.7.2.1.
Click Advanced to display the fields for the advanced search.
In the Date Range section, configure the date range in which to search for job requests. The date on the left is the beginning date and the date on the right is the end date. For each date, click the calendar icon to the right of the text field to select the date and time.
Submitted between: Enter the start and end dates during which the job request was submitted.
Scheduled between: Enter the start and end dates during which the job request is scheduled to run.
Completed between: Enter the start and end dates during which the job request finished running.
In the Run Time/Wait Time section, select the run or wait time of the job request for which you are searching, such as long or short running requests.
None: Select if no run or wait time is to be specified.
Long running requests: Select to search for requests running longer than a specified number of seconds, minutes, hours or days.
In the Minimum Run Time text field, enter the lower limit of the time period for which the job request runs. From the dropdown list, select the required unit of time.
Short running requests that waited: Select to search for job requests running longer than a specified period of time and waiting less than a specified period.
In the Maximum Run Time text field, enter the upper limit of the time period for which the job request runs. From the dropdown list, select Seconds, Minutes, Hours or Days.
In the Minimum Wait Time text field, enter the lower limit of the time period during which the job request waits to run. From the dropdown list, select Seconds, Minutes, Hours or Days.
Waiting requests by time: Select to search for job requests waiting to run for a specified time period.
In the Minimum Wait Time text field, enter the lower limit of the time period during which the job request waits to run. From the dropdown list, select Seconds, Minutes, Hours or Days.
In the Maximum Wait Time text field, enter the upper limit of the time period during which the job request waits to run. From the dropdown list, select Seconds, Minutes, Hours or Days.
In the Retry of Failed Runs section, use the Number of Retries dropdown list to select an operator such as equal to, greater than, greater than or equal to, and so on.
In the text field, enter the number of retries.
In the Error Type section, use the dropdown list to select the type of error:
Business: A job ends in a business error when it must abort prematurely due to unforeseen conditions, but is otherwise able to exit with its data in a consistent state. A job request might end in a business error as a result of an application setup or configuration condition, a functional conflict that requires an early exit or corrupt or inconsistent data. You cannot retry running a job request that ends in a business error.
System: A job ends in a system error when a technical problem occurs from which the job cannot recover, but otherwise exits on its own. Alternatively, the computer running the job crashes. Examples include table space issues and unhandled runtime exceptions. You can retry running a job request that ends in a system error.
Click Search to submit the job request search.
After running a search for job requests, you can configure the display of columns in the search results table.
To configure job request search results table display columns:
Display the main Oracle Enterprise Scheduler Request search page and display the search interface.
Display the list of available column names.
Click the View dropdown list and select Columns, then Show More Columns.
Use the arrows between the columns to move column names from the Visible to the Hidden column, or vice versa.
Optionally, reorder the columns by selecting the relevant column names and using the vertical arrows on the right to move them up or down.
Alternatively, display all columns by clicking the View dropdown list and select Columns, then Show All.
Once you submit a search for job requests, you can view detailed information about an individual job request by clicking the job request ID or the request parent ID. If the job is in an error state, an information box displays details regarding the error that occurred.
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:
Search for the relevant job requests as described in Section 5.7.2.1
In the table displaying the job request search results, select the job request whose details you want to view.
To view job request details, click the job request ID. Alternatively, click the parent ID associated with the job request to view the details of the job set with which the job is associated.
In the job request details page, you can take any of the following actions.
Request Log: Select Action and then select Request Log to display log information for the job request.
Request Tree: Select Action and then select Request Tree to display the parent job set along with all related child jobs.
Cancel: Select Action and then select Cancel to cancel the job request.
Hold: Select Action and then select Hold to temporarily suspend the job request.
Resume: Select Action and then select Resume to resume a suspended job request.
Recover Stuck Request: Select Action and then select Recover Stuck Request to recover an incomplete job request that cannot continue.
Change Priority: Select Action and then select Change Priority to raise or lower the priority of the job request. Job requests with a higher priority will be dispatched prior to job requests with lower priority.
Change Schedule: Select Action and then select Change Schedule to assign a different schedule to the job request.
Submit Like: Select Action and then select Submit Like to submit a job or job set with parameters similar to this one.
You may hold or resume a job request following its submission.
To hold and resume a job request:
Search for a job request.
In the table of job request search results, select the job request you want to hold.
Click the Hold button.
To resume the paused job request, select the job request and click Resume.
You may cancel an executable job request following its submission. 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 5-3 displays the cancellation states applied to each executable request depending on its state when initiating cancellation.
Table 5-3 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 cancelled at any of these stages. If the job request cannot complete all three stages, it transitions to CANCELLED.
This section contains the following topics:
Initiating Cancellation During Pre-Process Handler Execution
Initiating Cancellation During Synchronous Java Job Execution
Initiating Cancellation During Asynchronous Java Job Execution
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 5-4 displays the job 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 5-5 displays the job state following cancellation initiation.
Table 5-5 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 5-6 displays the job state following cancellation initiation.
Table 5-6 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 5-7 displays 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 5-8 displays the job state following cancellation initiation.
A parent job request that is not executable must be in WAIT state to be cancelled. It then proceeds to CANCELLING. The cancellation operation propagates to all eligible child job requests. For example, job set steps are cancelled when the job set is canceled, sub-requests are cancelled when the parent request is cancelled and recurring executable job requests are cancelled when the recurring parent is cancelled. 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 cancelling 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 cancelled as well. The state of the sub-request does not affect the state of the parent request.
When cancelling 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:
Search for a job request.
In the table of job request search results, select the job request you want to cancel.
Click the Cancel button.
The main Oracle Enterprise Scheduler page displays information regarding the top ten long running scheduled jobs as well as the top ten job requests awaiting execution in two different tabs. By default, only the job requests within the current scheduling service display. However, you can change the scope such that all relevant scheduled jobs running on all scheduling services sharing the Oracle Enterprise Scheduler repository display in the tabs.
Each of the Oracle Enterprise Scheduler tabs include a table that displays a short list of top ten long running and waiting job requests, respectively. The Show All Ready or Show All Running link at the bottom of the region goes to a search page in which it is possible to search for a more comprehensive list of relevant job requests.
Each tab displays the following information about scheduled job requests:
Request ID: The ID associated with the job request.
Run Time/Wait Time: The period of time during which the job request has been running or awaiting execution, respectively.
Job Definition: The job definition associated with the job request.
Submitted by: The name of the user who submitted the job request.
Application: The name of the application with which the job request is associated.
Execution Type: The category of job being executed—Java, SQL or process job.
Description: An optional description of the scheduled job request.
You can also monitor Oracle Enterprise Scheduler job requests related to a given product. For more information about viewing the top scheduled job requests related to a product, see Section 9.2.4.
This section contains the following topics:
Viewing Top Ten Long Running Oracle Enterprise Scheduler Requests
Viewing Top Ten Oracle Enterprise Scheduler Jobs Ready to Be Executed
Use the Top Ten Long Running Job Requests tab to view the job requests that have been running for the longest period of time on the Oracle Enterprise Scheduler service. You can alternatively change the scope of the region to display the top ten long running job requests on all scheduling services sharing the same repository.
The job requests displayed will all have a status of RUNNING.
To view the top ten long running requests:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
At the top of the Oracle Enterprise Scheduler page, click the Top 10 Long Running Requests tab to display the ten job requests that have been running the longest.
To display all running job requests, click Show All Running at the bottom of the chart. This displays a search form that searches for all requests that are currently running. Click Search to display the requests.
Use the Top Ten Ready Job Requests tab to view the job requests that are awaiting execution on the Oracle Enterprise Scheduler service. You can alternatively change the scope of the region to display the top ten ready job requests on all scheduling services sharing the same repository.
The job requests displayed will all have a status of READY.
To view the top ten ready job requests:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
At the top of the Oracle Enterprise Scheduler page, click the Top 10 Ready Requests tab to display the ten job requests with the status READY.
To display all ready job requests, click Show All Ready at the bottom of the chart. This displays a search form that searches for all requests with the status READY. Click Search to display the requests.
Purge policies allow the scheduling service to remove scheduled jobs according to specified criteria. For example, a purge policy might specify the retention of all Java type job requests using a particular job definition submitted executed by a given application for three days. Another purge policy might retain a particular type of job request, say, all SQL job requests in a successful state, for only one day. You can also specify the frequency at which the purge policy is to run.
This section contains the following topics:
A purge policy determines which job requests are to be purged and which retained. Defining a purge policy involves:
Selecting the jobs to be purged: Selection criteria include the related application or product, a particular job definition or job type, the job submitter or a maximum number of requests.
Specifying retention criteria: Decide how long job requests are to be retained depending on their status.
Specifying purge frequency: Decide how often you want the purge policy to run.
Note:
After a purge policy has run, it is necessary to physically delete purged job requests from the database. For more information, see Section 5.9.2.To set up a new purge policy:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Purge Policies.
To configure a new policy, click Setup New.
In the Setup Purge Policy page, configure the purge policy.
In the Description text field, enter a description for the purge policy.
In the Request Criteria for Purge section, configure the characteristics of the job requests to be purged.
Application: From the dropdown list, select the application for which you want to create a purge policy.
Product: Enter the name of the product.
Job Definition: Click the browse button next to the Job Definition text field.
In the Select Job Definition window, enter the name of the job definition in the Job Definition Name text field.
Click the search button, and select the relevant job definition from those that display. Click OK.
Execution Type: From the dropdown list, select the job type required: All, JAVA_TYPE, SQL_TYPE or PROCESS_TYPE.
Submitted by: Enter the name of the job submitter.
In the Retention Criteria for Purge section, configure the characteristics of the job requests to be retained.
Default Retention Period (in days): Enter the default period, in days, during which requests are to be retained.
Retention Period - Success (in days): Enter the period, in days, during which successful job requests are retained.
Retention Period - Error (in days): Enter the period, in days, during which errored job requests are retained.
Retention Period - Warning (in days): Enter the period, in days, during which job requests ending in a warning status are retained.
Retention Period - Cancelled (in days): Enter the period, in days, during which cancelled job requests are retained.
In the Advanced section, select Maximum requests to be processed. Enter the maximum number of job requests to be processed.
In the Schedule section, set a schedule for the job request purge policy.
To run the purge policy only one time, select Once. Click the calendar icon to select the date and time you want the purge policy to run.
To set a schedule for the purge policy, select Use Existing Schedule. Click the browse button to search for a schedule.
In the Select Schedule window, select a schedule and click OK.
Click OK to save the purge policy.
Job request data is kept in the Oracle Enterprise Scheduler runtime store as records in the runtime store tables. These job requests records are kept in the runtime store until they are physically purged by a database administrator using SQL purge scripts. You must logically delete a job request before physically purging it.
Use the method esspurge.purge_requests on the Oracle Enterprise Scheduler schema to delete purged job requests from the database. In an Oracle Fusion Applications environment, the schema is typically called FUSION_ORA_ESS.
The ESSPURGE package contains a stored procedure which you can use to purge completed job requests. The package is normally loaded when the Oracle Enterprise Scheduler schema is created or updated. The stored procedure is shown in Example 5-1.
Example 5-1 ESSPURGE Stored Procedure for Purging Completed Job Requests
--- Purges job requests that have completed. --- --- p_older_than : Purge only job requests that have completed after this time. --- p_max_count : The maximum number of job requests to purge. --- p_max_runtime : The maximum time, in minutes, the purge should run. --- If null (default), this defaults to one day which effectively means --- there is no time limit. --- procedure purge_requests ( p_older_than in timestamp, p_max_count in number, p_max_runtime integer default null );
The basic syntax of esspurge.purge_requests is shown in Example 5-2, where FUSION_ORA_ESS is the name of the Oracle Enterprise Scheduler schema and password is the password.
Example 5-2 Purging Job Requests from the Database
sqlplus FUSION_ORA_ESS/password set serveroutput on size unlimited set timing on execute esspurge.purge_requests(systimestamp, 1000000);
Additional examples are shown in the following list.
To purge job requests completed earlier than the current time, at a maximum of 50000 job requests, execute the following command:
execute esspurge.purge_requests(systimestamp, 50000);
To purge job requests completed 30 days earlier, at a maximum of 50000 job requests, execute the following command:
execute esspurge.purge_requests(systimestamp - 30, 50000);
To purge job requests that completed before June 01, 2010 at 15:00:00 (UTC), at a maximum of 50000 job requests, execute the following command:
execute esspurge.purge_requests(TIMESTAMP '2010-06-01 15:00:00 -00:00', 50000);
You can view all purge policies defined for the scheduling service.
To display purge policies for the scheduling service:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Purge Policies.
You can edit the request or retention criteria of an existing purge policy, as well as the purge policy schedule.
To update a purge policy:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Purge Policies.
From the Purge Policies table, select the policy you want to update and click Update.
Edit the purge policy accordingly and click OK.
You can delete a given purge policy.
To delete a purge policy:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Purge Policies.
From the Purge Policies table, select the policy you want to delete and click Delete.
Oracle Enterprise Scheduler job metadata refers to the components that form the basis of scheduled job requests.
These include the following:
Job definition: A job definition is the smallest unit of work performed in the context of the application that executes the job. A job definition is defined by a job type, such as a Java or SQL job type.
Job set: A job set is a sequential or parallel set of job steps, where a job step can be a single job or another job set. A job set and each of its job set steps can have additional parameters, the values for which are provided when the job or job set is submitted as a job request.
Incompatibility: An incompatibility allows you to specify job definitions and job sets that cannot run concurrently.
This section contains the following topics:
The Job Definitions page in Oracle Enterprise Manager Fusion Applications Control allows you to view, create, edit, duplicate, delete and search for job definitions. Figure 5-2 shows the Manage Job Definitions tab in the Job Definitions page. The tab displays a table of job definitions and their attributes, including name, description, location, execution type and job type.
The Job Definitions page in Oracle Enterprise Manager Fusion Applications Control also allows you to register sources for lists of values related to job definitions and the applications that run job definitions. Figure 5-3 shows the Manage List of Values Sources tab in the Job Definitions page.
This section contains the following topics:
You can view the job definitions created for a given application. The table of job definitions displays details about the jobs related to an application such as the job definition name, the full path to which it is saved, the job type, and so on.
Note:
In the Job Definitions page, an asterisk displays next to those jobs in the list that are pre-seeded, and are not custom jobs. The asterisk also displays next to pre-seeded jobs that you have customized.To display job definitions:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Job Definitions.
The Job Definitions page displays.
From the Applications dropdown list, select the name of the UI application whose job definitions you want to view.
The job definitions for that application display in a table below the application dropdown list.
| Column Name | Description |
|---|---|
| Name | This column displays the name of the job definition. |
| Display Name | This column shows the name of the job definition as it displays. |
| Description | This column displays a description of the job definition. |
| Path | This column displays the full directory path to which the job definition is saved. |
| Execution Technology | This column displays the type of job request that you can create using the given job definition, such as a Java, C, PL/SQL, Perl or hosted script job. |
| Job Type Name | This column displays the name of the job type upon which the job definition is based. |
Note:
If there are applications with similar names, be sure to select the UI application. For example, given an application called ProjectFinancialsApp and ProjectFinancialsESSApp, select ProjectFinancialsApp as this is the UI application.To view the details of a specific job definition, click the name of the relevant job definition.
You can create a new job definition, which you can then use to create a job request for a particular application. The job definition includes the directory path of the job to be run, the name of the application with which the job definition is associated and the job type used for the job definition.
Additional properties can be defined for a job definition as follows:
Parameters. You can configure editable or read-only parameters to be submitted to the job request.
User properties. You can configure properties to be filled in by end users at run time, such as boolean, number and string values.
Lists of Values. You can search for and register sources for lists of values to be used for parameters.
This section contains the following topics:
To create a job definition:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Job Definitions.
The Job Definitions page displays.
From the Applications dropdown list, select the name of the UI application for which you want to create a job definition.
Note:
If there are applications with similar names, be sure to select the UI application. For example, given an application called ProjectFinancialsApp and ProjectFinancialsESSApp, select ProjectFinancialsApp as this is the UI application.Click Create to create a new job definition.
For the new job definition, configure the following required properties:
Name: Enter a name for the job definition.
Display Name: Enter the name to be displayed for the job definition.
Path: Enter the path of the job to be run.
Application Name: From the dropdown list, select the name of the application with which you want to associate the job definition.
Job Type Name: From the dropdown list, select the job type you want to use for the job definition.
Additional properties may display, depending on the job type selected.
Optionally, configure parameters, user properties, system preferences and access control. For more information, see Section 5.10.1.2.1, Section 5.10.1.2.2, Section 5.10.1.2.3 and Section 5.10.1.2.4.
Click Save and Close.
A parameter enables passing data of type string, boolean, number or date time to the job request. Parameters can be passed using a number of display controls, such as a text box, date picker, choice list or list of values.
To configure parameters for a job definition:
In the job definition creation user interface, click the Parameters tab.
Select Actions and then select New or click the New icon.
The Create Parameter dialog box displays.
In the Create Parameter dialog, enter the following information:
Prompt: Enter the text to be displayed at the prompt that displays during run time.
Data Type: From the dropdown list, select a data type for the parameter: String Numeric, DateTime, Number or Boolean. Required.
Field Type: Select Editable or Read Only as desired.
Value: Enter a value for the parameter. This field displays for String type parameters. Required.
Default Value: Enter a default value for the parameter.
Tooltip Text: Enter documentation for the parameter.
Required: Select this checkbox if the parameter must be filled in.
Do Not Display: Select this checkbox if you want to hide the parameter in the user interface.
Display Control: From the dropdown list, select the control you want to display in the user interface. Display control options include Text Box, Choicelist, List of Values (with search), Date Picker.
Once you select a data type, you must configure its display.
Boolean: From the Default Value dropdown list, select true or false.
DateTime: Select the Date Only or Date and Time radio buttons.
From the Date Format dropdown list, select the format in which to display the date.
From the Default Value dropdown list, select any of the following values: Today, Tomorrow, A week from now or Specific date.
If you select Specific date, use the calendar picker to select a date. This is required.
Numeric: From the Number Format dropdown list, select the format in which to display the number.
For the Data Alignment radio button, select Left or Right. This configures the alignment of the number value in the job request submission UI.
In the Default Value field, enter a default value for the number.
String: From the Display Widget dropdown list, select Text Box, Choicelist or List of Values (with search). Required.
Text Box: When selecting this value from the Display Widget dropdown list, enter the default text in the Default Value text field.
Choicelist/List of Values (with search): From the List of Values Source dropdown list, select the source for the list of values. For the List of Values (with search), enter a default value in the field provided. In the Display Attributes shuttle list, select the attributes you want to display. For information about searching for and registering a list of values, see Section 5.10.1.2.3 and Section 5.10.1.2.4.
Click Save and Close or Save and Create Another.
If your job definition requires additional properties to be filled in by end users at runtime, you can add these properties in the User Properties tab of the job definition creation user interface.
To configure user properties for a job definition:
In the job definition creation user interface, click the User Properties tab.
Select Actions and then select New or click the New icon.
The Create User Property dialog box displays.
In the Create User Property dialog, enter the following information:
Name: Enter a name for the user property.
Data Type: From the dropdown list, select a data type for the property. Data types include Boolean, Date, Number and String.
Default Value: Enter a default value for the property.
Read Only: Select Read Only if you want the property to be displayed only, not edited.
Click Save and Close.
If you define a user property or parameter that uses a list of values, you must first register the source for the list of values.
To register a source for a list of values:
In the job definition creation user interface, click the Manage List of Value Sources tab.
Select Actions and then select New or click the New icon.
The Create List of Value Source dialog box displays.
In the Create List of Value Source dialog, enter the following information:
Application Name: From the dropdown list, select the name of the application for the list of value. Required.
List of Values Source Definition Name: Enter the name of the source definition file for the list of values. Required.
User List of Values Source Name: Enter the name of the source for the list of values to be displayed to users. Required.
Description: Enter a description for the list of values.
Click Save and Close.
When defining a user property or parameter using a list of values, you must register a source for the list of values. The Search field enables searching for a source for a list of values. You can also save the search for future use.
For information about registering a source for a list of values, see Section 5.10.1.2.3.
To search for list of value sources:
In the job definition creation user interface, click the Manage List of Value Sources tab.
In the Search field, select any of the following:
Match: Select the All or Any radio button to search for any or all of the criteria.
Application Name: From the dropdown list, select the name of the application you want to search. Then select an operator such as Greater than or equal to.
User List of Values Source Name: Enter text for the user list of values source name. Then select an operator such as Contains.
Optionally, you can add additional fields to search by. Click Add Fields and select any of the following fields to search by:
Application ID
Created by
Creation Date
Data Source ID
Description
Last Update Date
Last Update Login
Last Updated By
List of Values Source Definition Name
Object Version Number
Product Short Name
User List of Values Source Name
Click Search to run the search, or Save to reserve the search for future use.
The Job Sets page in Fusion Applications Control allows you to view, create, edit, delete and search for job sets.
A job set is a collection of job requests that can be grouped together to run as a single unit. A job set may be nested, such that it may contain a collection of job requests or one or more child job sets. Each job request or job set included within a job set is called a job set step.
Figure 5-4 shows the Results table in the Job Sets page. The Results table displays job sets and their attributes, including name, package, execution mode and description.
This section contains the following topics:
You can view the job sets created for a given application.
To display job sets:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Job Sets.
The Job Sets page displays.
From the Applications dropdown list, select the name of the application whose job sets you want to view.
Enter the name and package name of the job set you want to find, and click Go.
The job sets for that application display in a table below the application dropdown list.
| Column Name | Description |
|---|---|
| Name | This column displays the name of the job set. |
| Package | This column displays the name of the Java package associated with the job set. |
| Execution Mode | This column displays the execution mode of the job set, Serial or Parallel. |
| Description | This column displays a description of the job set. |
To view the details of a specific job set, click the name of the relevant job set.
A job set is defined as either a serial or a parallel job set. At run time, Oracle Enterprise Scheduler runs parallel job set steps together, in parallel. When a serial job set runs, Oracle Enterprise Scheduler runs the steps one after another in a specific sequence. Using a serial job set Oracle Enterprise Scheduler supports conditional branching between steps based on the execution status of a previous step.
For each step in a job set, you can configure an action to be take upon completion of the step, depending on the state of the step. You can also configure parameters and system properties for the job set, such as elevating access privileges to complete a particular job request or specifying the number of times a job can be retried in the event of failure.
To create or edit a job set:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Job Sets.
The Job Sets page displays.
Click Create to define a new job set, or Edit to modify an existing job set.
In the Job Set field, enter the name of the job set in the text field provided. Optionally, add a description in the Description text field, and the name of the relevant job set Java package in the Package text field.
In the Job Set Steps field, select Serial or Parallel to create a serial or parallel job set.
Add steps as required by clicking the Add icon. Define each step as required.
In the Step tab, in the Step ID field, enter a meaningful ID for the step.
In the Job field, enter search text and click the browsing button. In the window that displays, select the job definition that you want to use for this step.
In the Effective Application region, select Insert into main diagram or Add to list of available steps. If you choose to add the step to the list of available steps, use the dropdown lists that display to define an action for the possible job outcomes, namely On Success, On Error and On Warning.
In the Parameters tab, click the Add icon to define any required parameters and enter their initial value in the field provided. For more information about defining parameters, see Section 5.10.1.2.1.
In the System Properties tab, click the Add icon to define any system parameters required for the step.
From the Name dropdown list, select the system property you want to specify. Possible system properties are shown in Table 5-9.
In the Initial Value text field, enter the value you want to assign to the system property.
Table 5-9 System Properties
| System Property | Description |
|---|---|
|
|
This property specifies whether multiple pending requests for the same job definition is allowed. This property has no meaning for a job set step. True or false. |
|
|
This property specifies the logical name of the J2EE application used for request processing. This property is automatically set by Oracle Enterprise Scheduler during request submission. |
|
|
This property specifies the process exit code for a process job request that denotes an execution business error. If this property is not specified, the system treats a process exit code of 4 as an execution business error. This property is optional for a process job type. It is not used for other job types. For more information about business errors, see Section 5.7.2.2 |
|
|
This property specifies the Java executable for a Java job request. This should be the name of a Java class that implements the |
|
|
This property specifies the command line used to invoke an external program for a process job request. This property is required for a Process job type. It is not used for other job types. |
|
|
This property specifies the logical name of the J2EE application that will be the effective application used to process the request. A job definition, job type, or a job set step can be associated with a different application by defining the |
|
|
This property specifies the environment variables to be set for the spawned process of a process job request.The property value should be a comma separated list of name value pairs (name=value) representing the environment variables to be set. This property is optional for a Process job type. It is not used for other job types. |
|
|
This property specifies whether instances of a repeating request with an execution time in the past should be generated. Instances are never generated before the requested start time nor after the requested end time. To cause past instances to be generated, you must set this property to TRUE and specify the requested start time as the initial time from which instances should be generated. Note that a null requested start time defaults to the current time. Valid values for this property are:
If this property is not specified, the system defaults to |
|
|
This property is for internal use only. |
|
|
This property specifies an identifier for an external portion of an asynchronous Java job. For example, an asynchronous Java job usually invokes some remote process and then returns control to Oracle Enterprise Scheduler. This property can be used to identify the remote process. This property should be set by the job implementation of asynchronous Java jobs when the identifier is known. It is never set by Oracle Enterprise Scheduler. |
|
|
This property specifies the name of the Oracle Enterprise Scheduler isolation group to which this request is bound. This property is automatically set by Oracle Enterprise Scheduler during request submission. |
|
|
This property specifies input to a job request. The input to a serial job set is forwarded as input to the first step only. The input to a parallel job set is forwarded as input to all the parallel steps. Oracle Enterprise Scheduler imposes no format on the value of this property. |
|
|
This property specifies the working directory used during job request processing for input files. Oracle Enterprise Scheduler sets the value of this property during job request processing. |
|
|
This property specifies the event listener class associated with the request. This should be the name of a Java class that implements the |
|
|
This property specifies a language code to apply to the job. |
|
|
This property specifies the logging working directory. |
|
|
This property specifies output from a request. The output of a serial job set is the |
|
|
This property specifies the working directory used during job request processing for output files. Oracle Enterprise Scheduler sets the value of this property during job request processing. |
|
|
This property specifies the post-process callout handler class. This should be the name of a Java class that implements the |
|
|
This property specifies the pre-process callout handler class. This should be the name of a Java class that implements the |
|
|
This property specifies the request processing priority. The priority interval is [0...9] with 0 as the lowest priority and 9 as the highest. Default: If this property is not specified, the system default value used is 4. |
|
|
This property specifies the name of the PL/SQL stored procedure to be called for a SQL job request. The stored procedure should be specified using schema.name format. The property is required for a SQL job type. It is not used for other job types. |
|
|
This property specifies the product within the application that submitted the request. |
|
|
This property specifies the file where standard output and error streams are redirected for a Process job request. This represents the full path of the log file where the standard output and error streams are redirected for the spawned process when the request is executed. This property is optional for process job types. It is not used for other job types. |
|
|
This property specifies the callout handler processing delay time. This represents the time, in minutes, to delay request processing when a delay is requested by a callback handler. Default: If this property is not specified, the system default used is 5. Integer type. |
|
|
This property enables the job request to time out. |
|
|
This property specifies an application-specific label for a request. The label, defined by an application or system administrator, allows administrators to group job requests according to their own specific needs. |
|
|
This property specifies the request processor node on which the request should be processed. This allows processor affinity to be specified for a job request. If this property is not specified, the request can run on any available request processor node. In general, this property should not be specified. If this property is specified for a request, the request processor's work assignments |
|
|
This property specifies the expiration time for a request. This represents the time, in minutes, that a request will expire after its scheduled execution time. A expiration value of zero (0) means that the request never expires. If this property is not specified, the system default value used is 0. Request expiration only applies to requests that are waiting to run. If a request waits longer than the specified expiration period, it does not run. After a request starts running the request expiration no longer applies. |
|
|
This property specifies the retry limit for a failed request. If request execution fails, the request will retried up to the number of times specified by this property until the request succeeds. If retry limit is zero (0), a failed request will not be retried. If this property is not specified, the system default used is 0. |
|
|
This property enables elevating access privileges for completing a scheduled job. Normally, a request runs as the submitting user. However, if this property is set in the metadata of the job associated with the request, then the request executes under the user identified by this property. This property can only be specified via metadata and cannot be specified as a submission parameter. |
|
|
This property specifies whether the result state of a job set step affects the eventual state of its parent job set. In order for the state of a job set step to be considered when determining the state of the job set, the |
|
|
This property specifies an Oracle Enterprise Scheduler job class to be assigned to the Oracle Enterprise Scheduler job used to execute a SQL job request. This property need not be specified unless the job used for a job request is associated with a particular Oracle Database resource consumer group or has affinity to a database service. If this property is not specified, a default Oracle Enterprise Scheduler job class is used for the job that executes the SQL request. That job class is associated with the default resource consumer group. It belongs to the default service, such that it has no service affinity and, in an Oracle RAC environment, any one of the database instances within the cluster might run the job. No additional privilege or grant is required for an Oracle Enterprise Scheduler SQL job request to use that default job class. This property is optional for a SQL job type. It is not used for other job types. |
|
|
This property specifies the logical name of the J2EE application for the submitted (absolute parent) request. This property is automatically set by Oracle Enterprise Scheduler during request submission. |
|
|
This property has been deprecated. |
|
|
This property specifies the process exit code for a process job request that denotes an execution success. If this property is not specified the system treats a process exit code of 0 as execution success. This property is optional for a process job type. It is not used for other job types. |
|
|
This property specifies a base directory in the file system where files, such as input and output files, may be stored for use by the request executable. Oracle Enterprise Scheduler supports a configuration parameter that specifies a file directory where requests may store files. At request submission, a |
|
|
This property specifies the name of the user used to execute the request. Normally, this is the submitting user unless the |
|
|
This property specifies the process exit code for a process job request that denotes an execution warning. If this property is not specified, the system treats a process exit code of 3 as execution warning. This property is optional for a process job type. It is not used for other job types. |
|
|
This property specifies the working directory for the spawned process of a Process job request. This property is optional for a process job type. It is not used for other job types. |
If you configured the step as a serial step, it displays in the job set flow diagram. Configure the action to be taken upon reaching error and warning states, respectively. From the dropdown list for the error and warning icons, select Stop or the name of the job definition to run upon reaching an error or warning state.
Continue to define steps as required for the job set.
Define parameters and system properties as required towards the bottom of the job set window.
Configure access control for the job set.
In the Access Control section of the Create Job Set page, click the Add icon to add access control to the job set.
The Add Access Control dialog box displays.
From the Role dropdown list, select the name of the role you want to apply to the job set. The role defines the users with sufficient permissions to access the job set.
Select the actions you want to allow role members to take: Read, Execute, Update and Delete.
Click OK to save the job set.
You can delete a job set.
To delete a job set:
Search for the relevant job set, as described in Section 5.10.2.1.
In the Results table, select the job set you want to delete and click the Delete icon.
An Oracle Enterprise Scheduler incompatibility specifies which job definitions are incompatible with other job definitions. At runtime, when job definitions are specified in an incompatibility, any job requests associated with the job definitions that are incompatible cannot run simultaneously.
A given incompatibility defines either a global incompatibility or a domain-specific, property-based incompatibility.
This section contains the following topics:
The Incompatibilities page displays information about incompatibilities including name, the Java package associated with a given incompatibility and a description for the incompatibility.
To view job incompatibilities:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Incompatibilities.
The Incompatibilities page displays.
From the Applications dropdown list, select the name of the application whose incompatibilities you want to view.
Enter the name and package name of the incompatibilities you want to find, and click Go.
The incompatibilities for that application display in a table below the application dropdown list.
| Column Name | Description |
|---|---|
| Name | This column displays the name of the incompatibility. |
| Package | This column displays the name of the Java package associated with the incompatibility. |
| Incompatibility Type | This column displays the type of incompatibility, global or domain specific. |
| Description | This column displays a description of the incompatibility. |
To view the details of a specific incompatibility, click the name of the relevant incompatibility.
An incompatibility consists of two or more job definitions configured as incompatible, and the resource over which they need to be incompatible. A resource is not specified for a global incompatibility. This resource is represented by the property name that forms the Incompatibility. The property name might be different across job definitions. For example, if two job definitions, JobA and JobB, are made incompatible, then the property identified for incompatibility might have different names in JobA and JobB.
Domain-specific: Two or more job definitions are marked as incompatible within the scope of a resource, where the resource is identified by a system property name or a user-defined parameter name. An incompatibility specifies two or more incompatible entities where each entity consists of a job definition or a job set definition and a property name that represents the resource over which the entities are incompatible. Each entity can use the same property name or a different property name. A property-based incompatibility is used when the incompatible entities are incompatible over a given property. For property-based incompatibility, a job definition or a job set and a property name must be specified for each entity. Oracle Enterprise Scheduler ensures that requests for the incompatible jobs or job sets, with a property that has the same property value, do not run at the same time.
Global: Two or more job definitions cannot run together at any time. A global incompatibility is used when the incompatible entities are not to be run at the same time regardless of any property. For global incompatibility, only the job definition or job set is specified for each entity. Oracle Enterprise Scheduler ensures that requests for the incompatible Jobs or job sets do not run at the same time.
Defining an incompatibility involves the following:
Package and scope: Select a relevant Java package to use for the incompatibility and set the scope for the incompatibility (global or domain only).
Jobs: Select the jobs that are incompatible.
Parameters and properties: Define parameters and properties as required.
Access control: Define access control as required.
To create or edit an incompatibility:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Job Metadata and then select Incompatibilities.
The Incompatibilities page displays.
Click Create to define a new incompatibility, or Edit to modify an existing incompatibility.
The Create Incompatibilities page displays.
Enter the following information:
Name: Enter a name for the incompatibility.
Package: Enter the name of the relevant incompatibility Java package.
Description: Optionally, add descriptive text for the incompatibility.
Type: Configure the scope of the incompatibility by selecting Global or Domain.
In the Entities field, click the Add icon to add jobs to the incompatibility.
The Add Entity dialog box displays.
Select one or more jobs and click OK.
Define parameters and system properties as required towards the bottom of the incompatibility window. For more information about defining parameters and system properties, see Section 5.10.2.2.
Configure access control for the incompatibility, as described in step 9 of Section 5.10.2.2.
Click OK to save the incompatibility.
Deleting an incompatibility results in the incompatible job requests or job sets becoming compatible again.
To delete an incompatibility:
Search for the relevant incompatibility, as described in Section 5.10.3.1.
In the Results table, select the incompatibility you want to delete and click the Delete icon.
Work allocation is the process of defining constraints on where and when jobs run as well as the amount of resources that can be used to process the jobs. This process includes creating a work assignment, and binding the work assignment to a request processor.
A work assignment consists of a specialization rule and one or more workshifts. The specialization rule defines restrictions on which jobs can be processed. A workshift defines the temporal windows when the jobs can be processed and what resources can be used during those periods. The resources defined in a workshift include threads, which are a local resource of the request processor, and asynchronous workers, a global resource. The number of asynchronous workers can be specified to throttle the use of a shared global resource, such as database jobs.
Binding associates a work assignment with a request processor on a server, determining where the jobs can run. An exclusive binding mode is supported to not only determine when the jobs can run but to prevent them from running anywhere else.
By default, no work assignments are bound. When there is no bound or active work assignment, a virtual default work assignment will be started to process all jobs using all available resources.
This section contains the following topics:
Work assignments provide the following controls for processing job requests:
At runtime, work assignments can be attached to a request processor and can limit the period during which job requests of a certain type can be processed.
At runtime, a request processor can be controlled and a work assignment can limit the resources that are available to process all job requests.
Determining Active Work Assignments
A bound work assignment is active if it is enabled, has an active workshift and the enabled flag is set on the work assignment definition. A workshift is active if it has an allocation greater than zero and includes a current schedule (where the current time is within a time window defined by the schedule and duration), or the workshift is a 24x7 workshift. If there are no bound work assignments on the server, the default work assignment will be active using all threads and having no limits on asynchronous workers.
Only one workshift can be active for a given work assignment at any point in time. If a work assignment has more than one active workshift, Oracle Enterprise Scheduler chooses the most specific of these to be the actual active workshift. The most specific workshift is the one that ends soonest, or, given two workshifts that have ended at the same time, the workshift that started most recently.
Determining Work Assignment Thread Allocation
An active work assignment is assigned the thread allocation specified by the active workshift unless the total number of threads needed to satisfy the allocations of all active work assignments exceeds the configured thread count. In this case, Oracle Enterprise Scheduler weighs the thread allocation against the percentage of threads allotted to the workshift out of the total number of thread allocations for all work assignments.
For example, suppose work assignment 1 has a thread allocation of 70, work assignment 2 has a thread allocation of 30, and there are 20 processor threads configured. The total desired allocation is 100, so the weight for work assignment 1 is 70% while the weight for work assignment 2 is 30%. Oracle Enterprise Scheduler allocates 14 threads to work assignment 1 and six threads to work assignment 2.
If the default work assignment is active, the number of threads allocated to the work assignment is equal to the configured thread count.
Note:
Each active work assignment is assigned at least one thread.Processing Active Work Assignments
After determining work assignments and thread allocations, Oracle Enterprise Scheduler begins a thread pool for each active work assignment. The threads are responsible for processing job requests that are specialized to the work assignment, except for requests that are specialized to an exclusive work assignment. The exclusion is effective for all work assignments, including the default work assignment. If an exclusive work assignment is bound to any server in the group, no other work assignment can process job requests specialized to that exclusive work assignment.
Note:
All work assignments bound in exclusive mode are excluded, including disabled work assignments. Exclusive bindings apply even if the server to which they are bound is unavailable. You must unbind an exclusive work assignment if you do not want it to be excluded.This section contains the following topics:
A work assignment includes two primary components that define request processor constraints:
Specialization rules: Define restrictions for job request processing on a request processor.
Workshifts: Specify temporal windows for processing job requests and thus describe the schedule for when job requests can be processed on a request processor
This combination of work assignment controls, including specialization rules and workshifts gives you the ability to select the kinds of job requests to be processed and decide how to allocate the request processor resources. For example, you can define two workshifts: a day shift and a night shift to allocate processing for these periods. The day shift could have more resources allocated for a peak usage period while the night shift could provide a different mix for its resource allocation.
By default, no work assignments are bound to a request processor and the request processor processes any ready job request. The default behavior is similar to using a request processor with no specialization rules and a workshift of 24/7 duration, all configured threads are used and there are no limits on the number of asynchronous jobs.
Table 5-10 shows the properties that you can define for specialization rules.
Table 5-10 Specialization Properties Available for Specialization Rules
| Specialization Property | Description |
|---|---|
|
Application |
Specifies the name of the application associated with a job request. |
|
Product |
Specifies the name of the product within an application. |
|
Submitted By |
Specifies a user who submitted a job request. |
|
Job Definition |
Specifies a specific job request name. |
|
Request Category |
Specifies a label defined by the system administrator allowing administrators to group job requests for specific needs. |
The following operators can be used to join the conditions of a rule: AND, OR (both of type binary), CONTAINS and NOT (unary).
Example 5-3 shows sample specialization rules that can be used in a work assignment.
Example 5-3 Sample Specialization Rules
application = 'EssDemoApp' AND (definition = 'JobDefinition://mypackage/Job_essdemo1' OR definition = 'JobDefinition://mypackage/LongRunningJob') requestCategory ='Priority' user = 'sam' (requestCategory ='LongRunning') AND NOT (definition = 'JobDefinition://mypackage/LongRunningJob')
If a job request is specialized to two different work assignments, either of those work assignments may process the job request depending on resource availability. Similarly, if the same work assignment is bound to two different servers, either server may process the job request.
To create or edit a work assignment:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Work Assignments.
The Work Assignments page displays.
Click the Create or Edit buttons to create or edit a work assignment.
The Create Work Assignment page displays.
Enter a name and description for the work assignment in the relevant text fields.
Select the Enabled checkbox to enable the work assignment.
Click Create Specialization to add conditions under which the work assignment runs.
In the Workshifts section, click the Add icon to add one or more workshifts to the work assignment.
Click OK to save the work assignment.
You can delete a work assignment from the list of work assignments. Before deleting a work assignment, make sure that it is not bound to a request processor.
To delete a work assignment:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Work Assignments.
The Work Assignments page displays.
Select the work assignment you want to delete and click Delete.
A workshift indicates the operating, active times for a request processor. Specifically, a workshift defines a sequence of temporal windows in which resources or threads, are made available for processing job requests. When a work assignment is bound to a request processor, one or more workshifts are associated with the work assignment. At runtime, Oracle Enterprise Scheduler determines the resource allocation for the workshifts within the work assignment.
A workshift defines the following resources:
Thread allocation,
Asynchronous job limits for asynchronous Java and PL/SQL jobs.
Thread allocation specifies the number of threads that can be used by the request processor. These threads are used to perform local tasks, including processing synchronous jobs, initiating and finalizing asynchronous jobs, pre- and post-processing of job requests and updating events. When the workshift in a work assignment is active, each request processor for the work assignment can use the specified number of threads. For example, suppose a work assignment includes a 24x7 workshift with a thread allocation of 15. If that work assignment were bound to three request processors, each request processor could use 15 threads, for a total of 45 threads across all three servers.
Asynchronous, PL/SQL and asynchronous Java jobs use a global resource that must be shared across the entire system. The workshift can specify limits on the number of PL/SQL jobs and asynchronous Java jobs that can be active for the work assignment. This limit applies across all request processors for the work assignment in the entire system. For example, suppose a work assignment includes a 24x7 workshift with a PL/SQL job limit of ten. If that work assignment were bound to three request processors, all three request processors would share the ten PL/SQL asynchronous workers, for a maximum of ten PL/SQL jobs active for that work assignment.
When deciding on thread allocation and asynchronous job limits for a workshift, take note of the types of jobs specialized to the work assignment where the workshift is to be used.
This section contains the following topics:
Creating a workshift involves the following:
Schedule: Associate a schedule with the workshift.
Duration: Enter a duration for the workshift.
Thread allocation: Specify the number of threads you want to allocate to the workshift.
To create or edit a workshift:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Workshifts.
The Workshifts page displays.
Click the Create or Edit buttons to create or edit a workshift.
The Create Workshift page displays.
Enter the following information for the workshift.
Name: Enter a name for the workshift.
Description: Enter a description for the workshift.
In the Active Period section, select one of the following activation periods for the workshift.
Active 24x7: Select to always enable the workshift. Selecting this option removes the Duration text field.
Use existing schedule: Select to enable the workshift using a schedule you created previously. Click the Browse button to display the Select Schedule window and search for the schedule using the Name and Package fields.
In the Duration text field, enter the duration of the workshift in minutes.
Specify schedule: Select to create a schedule for the workshift. Enter a name and description for the schedule in the text fields provided.
From the Time Zone dropdown list, select a time zone for the schedule.
In the Start region, select Immediately or Later. If you choose Later, select the date and time using the calendar icon.
In the Repeating region, use the Repeat dropdown list to select the frequency at which the workshift schedule will repeat: Do not repeat, Every N minutes/hours/days/weeks, Specific days of the week, Specific days of the month. Enter the number of minutes, hours, days or weeks. Alternatively, select the days of the week or dates of the month on which the schedule is to run.
In the End Date region, select No End Date or Specified End Date. When selecting Specified End Date, use the calendar icon to set an end date in the Date text field.
In the Duration text field, enter the duration of the workshift in minutes.
Expand the Advanced region. Specify the thread allocation and the asynchronous job limits.
In the Thread Allocation field, enter the number of threads to be allocated to the processor when the workshift is active. If the total thread allocation of the active workshifts exceeds the number of available threads, then the threads are allocated proportionately to this workshift.
In the Asynchronous Job Limits region, enter the number of asynchronous Java and PL/SQL jobs that can be active for the work assignment. This limit applies across all processors to which the work assignment is bound.
Click OK to save the workshift.
You can delete a workshift from the list of workshifts.
To delete a workshift:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Workshifts.
The Workshifts page displays.
Select the workshift you want to delete and click Delete.
Schedules are used to configure the start and end times as well as the frequency of work allocations, purge policies and job requests.
This section contains the following topics:
A job schedule specifies a predefined time or recurrence for scheduling and executing a job request, work allocation or purge policy. Schedules are defined independent of jobs and can be associated with one or more jobs.
To create or edit a schedule:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Schedules.
The Schedules page displays.
Click Create to define a new schedule, or Edit to modify an existing schedule.
The Create Schedules page displays.
Enter the following information:
Name: Enter a name for the schedule.
Description: Optionally, add descriptive text for the schedule.
Time Zone: From the dropdown list, select the time zone in which the schedule will run.
Configure the beginning of the schedule. In the Start field, select Immediately or Later.
If you select Later, use the date picker to select a date and time for the beginning of the schedule.
In the Repeat field, configure the frequency of the schedule.
From the Repeat dropdown list, select the unit of time by which you want to repeat the schedule. Options include: Do Not Repeat, By the Minute, Hourly, Daily, Weekly or Weeks.
In the Frequency text field, enter the number of units for the schedule frequency. Enter the number of minutes, hours, weeks or times per day.
If selecting Weekly, use the Day of the Week dropdown list to select the day or days of the week you want to run the schedule.
In the End date field, select an end date for the schedule. Select No End Date or Specified End Date. If selecting Specified End Date, use the date picker to select the end time and date.
Click OK to save the schedule.
You can delete a schedule from the list of schedules.
To delete a schedule:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select Work Allocation and then select Schedules.
The Schedules page displays.
Select the schedule you want to delete and click the Delete button.
The ADF Connections Configuration page allows you to create connections to services such as ADF Business Components services, Oracle Business Activity Monitoring, Oracle Enterprise Scheduler Service, URLs and web services.
Figure 5-5 shows the ADF Connections Configuration page.
Use the ADF Connections Configuration page to configure the following properties for Oracle Enterprise Scheduler:
NotificationServiceURL: Configure this property when using the notification service with Oracle Enterprise Scheduler. Set the URL of this property to that of the UMS Server NotificationServiceURL.
RequestFileDirectory: Configure this property to indicate the path of the folder to which job request logs are to be written. This property is used for job requests submitted by Oracle ADF applications.
SAMLTokenPolicyURI: Set this property to the URI of the SAML policy used to secure job requests submitted by Oracle ADF applications.
EssCallbackClientSecurityPolicyURI: Configure this property to enable the security policy used in the WS-Security headers for web service invocations from Oracle Enterprise Scheduler for web service callbacks.
To create or edit an ADF connection:
From the navigation pane, expand the Scheduling Services folder and select the Oracle Enterprise Scheduler application.
From the Scheduling Services menu, select ESS Connections.
The ADF Connections Configuration page displays.
In the Create Connection field, click the Connection Type dropdown list and select the type of connection you want to create.
In the Connection Name field, enter a name for the connection.
Click Create Connection to add the connection.
The new connection displays under the relevant connection category.
To configure the connection, scroll down to the relevant connection category and select the new connection. Click Edit.
The connection window displays.
Configure the connection accordingly. For more information about the attributes you can configure for each type of connection, see the online help by clicking the help icon on the ADF Connections Configuration page.
Click Apply to activate the connection.
Oracle Enterprise Scheduler application and role policies are the same as other application and role policies. For more information about managing application and role policies, see Chapter 4.
Oracle Enterprise Scheduler web services are the same as other Fusion application web services. For information about managing the web services related to Oracle Fusion Applications, see the"Understanding Oracle WSM Policy Framework" chapter in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
You can search for and view log data for individual job requests, as well as set log levels for Oracle Enterprise Scheduler. You can also save job request logs to a file, and trace job requests for additional troubleshooting information.
This section contains the following topics:
Note:
The Oracle WebLogic Server logger (
logging.xml) only shows logs written by Oracle Enterprise Scheduler job running in Oracle WebLogic Server. Once Oracle Enterprise Scheduler transfers control of running PL/SQL and C jobs to the PL/SQL or C process, respectively, PL/SQL and C job logging data is not written to the Oracle Enterprise Scheduler logs as they run in a separate process.Job request logs can often be written to different files. You can find log data regarding a given job request using its Execution Context Identifier (ECID), a unique identifier that enables finding log data for the job request.
For more information about finding the ECID for a job request, see Section 17.5.3
You can view the log for a particular job request from the Request Details pane.
To view job request logs:
Search for the relevant job requests as described in Section 5.7.2.1
In the table displaying the job request search results, select the job request whose log you want to view.
To view job request details, click the job request ID. Alternatively, click the parent ID associated with the job request to view the details of the job set with which the job is associated.
In the job request details page, select Action and then select Request Log to display log information for the job request.
You can use the Oracle Enterprise Scheduler Log Messages page to view logging information regarding scheduled job requests.
For more information about logging, see Chapter 13.
To view log messages for scheduled job requests with Fusion Applications Control:
From the navigation pane, expand the farm, and then Scheduling Services.
Select the ESSAPP application for the appropriate Managed Server.
In the Scheduling Service home page, from the Scheduling Service menu, choose Logs and then select View Log Messages.
Search for the relevant log messages using the Date Range, Message Types and Message fields. You can optionally add additional search fields. For more information about logging, see Chapter 13.
You can use the ECID to retrieve more information about a given job request. The Execution Context ID (ECID) is a global unique identifier of the execution of a particular request in which the originating component participates. You can use the ECID to correlate error messages from different components
By default, when view the logs for a request, Fusion Applications Control displays only messages logged in the scope of the Oracle Enterprise Scheduler cluster. If the Oracle Enterprise Scheduler application is not deployed to a cluster, Fusion Applications Control displays the messages logged in the managed server scope. However, Oracle Enterprise Scheduler propagates the ECID associated with the job request across sub-systems such as SOA, ADF, and so on.
To view messages logged by other sub-systems, broaden the target scope to display messages logged across the domain or farm. Click Broaden Target Scope and select the target whose log messages you want to view.
It is possible to configure Oracle Enterprise Scheduler server logging for a Oracle WebLogic Server by modifying the logging.xml file of that Oracle WebLogic Server. By default, there is no explicit logger entry for Oracle Enterprise Scheduler. Oracle Enterprise Scheduler inherits the logging level and log handlers configured for the parent logger, typically the oracle logger or the root logger.
By default, the log messages for the Oracle Enterprise Scheduler logger can be found in the Oracle WebLogic Server diagnostic log file for that Oracle WebLogic Server. The logging.xml file is located under DOMAIN_HOME/config/fmwconfig/servers/WebLogic_Server_Name, where DOMAIN_HOME is the domain home directory for the Oracle WebLogic Server domain and WebLogic_Server_Name is the name of the Oracle WebLogic Server that uses the logging.xml file.
Table 5-11 shows the Oracle Enterprise Scheduler logger names, log levels and a description for each level.
Table 5-11 Loggers and log levels for Oracle Enterprise Scheduler
| Logger Name | Log Level | Description |
|---|---|---|
|
|
|
Problems encountered by Oracle Enterprise Scheduler runtime in the context of request processing that result in the request errors. Errors include exceptions thrown by the job code, unchecked exceptions when running the job code and exceptions when running Oracle Enterprise Scheduler code. Problems encountered by Oracle Enterprise Scheduler runtime outside the context of request processing, such as dispatching, system event handling, and so on. |
|
|
Less severe problems encountered by Oracle Enterprise Scheduler runtime during or outside of request processing, which might not cause requests to enter error state. |
|
|
|
Messages for request state transitions. Messages related to work assignment activities. Messages about batch delete failures. Start and stop of Oracle Enterprise Scheduler resource adapter. |
|
|
|
Application endpoint activation and de-activation for Oracle Enterprise Scheduler resource adapter. |
|
|
|
|
Any problems that occur during UI rendering to submission. |
|
|
Messages related to job fetch and submission API calls. |
|
|
|
Details tracing messages for the scheduled job request submission UI. |
|
|
|
|
Any problems that occur during UI rendering to operations in the UI. |
|
|
Messages related to job request fetch and various API calls. |
|
|
|
Details tracing messages for the job request monitoring UI. |
|
|
|
|
Records any errors occurred when creating a session for Oracle Fusion Middleware Extensions for Applications, or when creating a file during pre- and post-processing. |
|
|
Records messages related to terminating sessions and closing files during pre- and post-processing |
|
|
|
Messages related to pre- and post-processing execution activity. |
Application Logging: Oracle Enterprise Scheduler job implementation might call standard Oracle Fusion Applications logging code. For proper operation, the AFLOG_ENABLED profile option must be set to Y. For PL/SQL jobs, set AFLOG_PLSQL_FILENAME to Y. For C jobs, set AFLOG_FILENAME to Y. For more information about configuring log settings, see Section Section 13.7 and Section 17.2. For more information about setting the AFLOG_ENABLED property, see the section "Enabling JBO Logging in the Provisioned Environment" in the "Debugging Oracle ADF and Oracle SOA Suite" chapter in the Oracle Fusion Applications Developer's Guide.
Request Logging: Oracle Enterprise Scheduler job implementation might write business-specific job request execution log information to the job request log file. This log file is specific to each request, and is automatically enabled by default. For more information about viewing the log file for a job request, see Section 5.15.2.
For information about setting the log levels for Oracle WebLogic Server, see Section 5.15.5. For more information about Oracle Diagnostic Logging levels, see Section 13.7.3.
Set the log levels for the Oracle WebLogic Server running Oracle Enterprise Scheduler as described in the Oracle WebLogic Server documentation.
Enabling tracing for Oracle Enterprise Scheduler jobs provides additional information regarding job requests, which can then be relayed to Oracle technical support to help solve any Oracle Enterprise Scheduler-related issues.
This section contains the following topics:
Before You Begin
Before enabling tracing, note that tracing log messages may produce a considerable amount of output. By default, log message traces go to the Oracle WebLogic Server console stdout. If the stdout is re-directed to a file, it may occupy a significant amount of disk space and possibly affect server performance.
For more information about Oracle Diagnostic Logging levels, see Section 13.7.3.
To enable tracing for Oracle Enterprise Scheduler jobs:
Navigate to the Log Configuration pane and expand the Specify Loggers region.
In Fusion Applications Control, in the navigation pane, select WebLogic Domain and then select the domain and server names.
Click the WebLogic Server menu and select Logs and then select Log Configuration.
The Log Configuration pane displays.
In the Log Levels tab, from the View dropdown list select Loggers with Persistent Log Level State. Expand the Specify Loggers region toward the bottom of the pane.
Create the following loggers: oracle.as.scheduler.security.internal.SecurityExecutorFactory and oracle.as.scheduler.security.internal.SecurityHelper.
In the Name text field, enter the name of the logger.
From the Oracle Diagnostic Logging Level (Java Level) dropdown list, select the desired logging level.
Repeat for the second logger name.
Attach the loggers to the Oracle Diagnostic Logging Handler.
In the Log Configuration pane, click the Log Files tab.
From the list of handlers, select odl-handler and click Edit Configuration.
From the Loggers to Associate dropdown list, select the loggers you created and click OK.
Download the trace file.
In Fusion Applications Control, in the navigation pane, select WebLogic Domain and then select the domain and server names.
Click the WebLogic Server menu and select Logs and then select View Log Messages.
The Log Messages pane displays.
In the Search field, expand the Selected Targets region and select the relevant Oracle Enterprise Scheduler target.
Select the relevant date range, message type and so on, and click Search.
From the list of log messages that displays, select the relevant message.
In the Log File column, click the name of the log file.
The View Log File pane displays.
Next to the name of the log file, click Download to download the file.
By default, job request logs are written to the fnd_log API if Oracle Fusion Applications logging is set to FINER.
It is possible to save job request log data to the server log file. Job request logs are normally stored to Oracle Universal Content Management. However, when setting the log level to FINER, all job request logs are copied to the server log file.
To save job request logs to the server diagnostic file:
In Fusion Applications Control, in the navigation pane, select WebLogic Domain and then select the domain and server names.
Click the WebLogic Server menu and select Logs and then select Log Configuration.
The Log Configuration pane displays.
In the Log Configuration pane, click the Log Levels tab.
In the Search text field, search for oracle.as.scheduler. and find the oracle.as.scheduler.security.internal.SecurityExecutorFactory logger.
Set the log level to FINER and click Apply.
Run a diagnostic test, as described in Chapter 13. The log messages are now saved to the <server>-diagnostic.log file.
The logs are saved to the server diagnostic file, <Oracle Enterprise Scheduler server name>-diagnostic.log.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|