Oracle® Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduler 11g Release 1 (11.1.1.7) Part Number E24712-04 |
|
|
PDF · Mobi · ePub |
This chapter describes how you can add metadata to refine Oracle Enterprise Scheduler job logic, including how to add work specifics, group jobs into meaningful sets, assign schedules that guide when the work occurs, and create exceptions, such as when jobs should not run simultaneously.
This chapter includes the following sections:
You can define meaningful work by associating metadata with job types and by assigning schedules to the work. When managing the work of Oracle Enterprise Scheduler jobs, you can:
Associate request instance-specific data through properties -- whether your own or the system's -- that tie jobs to the context in which they're running
Determine what level of access a group of people have to data related to the work done by jobs.
Organize jobs into job sets so that they can be run as a unit, whether in sequence or at the same time.
Specify that certain job definitions may not run at the same time, and the circumstances under which they cannot.
Define the constraints within which jobs may run, based on factors such as system resources.
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 Fusion Middleware Control allows you to view, create, edit, duplicate, delete and search for job definitions.
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.
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 Application dropdown list, select the name of the application whose job definitions you want to view.
In the Name and Package fields, enter values to search for.
Click Go to search.
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. |
Package |
This column displays the name of the Java package associated with the job definition. |
Description |
This column displays a description of the job definition. |
To view the details of a specific job definition, click the name of the relevant job definition.
You can create or edit a job definition. With a job definition created, you can 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 runtime, such as boolean, number and string values.
This section contains the following topics:
To create or edit 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 application for which you want to create a job definition.
Click Create to create a new job definition, or Edit to modify an existing job definition.
For the job definition, configure the following properties:
Name (required): Enter a name that will uniquely identify this definition. This value may not contain spaces.
Display Name: Enter a value that will be displayed to users for this definition. This value may contain spaces and should be memorable for users who might later view or search for the definition in the user interface.
This property supports internationalization for adapting to differing locales.
Package: Enter the package of the job to be run.
Description: Enter a description for the job.
This property supports internationalization for adapting to differing locales.
Job Type (required): From the dropdown list, select the job type you want to use for the job definition. Select the Overwrite check box to
The Job Type you choose will determine which one of the following fields is displayed beneath the Job Type. Note that you won't be able to edit the field's value if the corresponding value in this definition's job type was specified to be read only.
Class Name (for JavaJobType)
The class name that is associated with the job definition's job type. If you can edit the field, select OverWrite and enter the class path and name or click Browse to specify a path name for the Java class.
Procedure Name (for PlsqlJobType)
The procedure name for the PL/SQL procedure associated with this job definition's job type. If you can edit this field, select OverWrite and enter the procedure name to be used by this job definition. You can also click the Browse button to use an already defined database connection to browse for a stored procedure.
Command Line (for ProcessJobType)
The string that is the command associated with the job type. If you can edit this field, select OverWrite and enter the command to be used by this job definition.
Optionally, configure parameters, system properties, and access control. For more information, see Section 5.2.1.2.1, Section 5.2.1.2.2, and Section 5.2.1.2.3.
Click OK.
You use a parameter to pass data to the job request. In the job submission user interface, 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:
On the Create Job Definition page, expand the Parameters section.
Click the Add icon.
The Add Parameter dialog box displays.
In the Add Parameter dialog, enter the following information:
Type: From the dropdown list, select a data type for the parameter: String Long, Integer, DateTime, Number or Boolean. Required.
Name: Enter a name for the parameter.
Read Only: Select the check box to have this parameter be read only to the user.
Initial Value: Enter the value that should be used for this parameter until the user changes it.
Click OK.
System properties are parameter names that are known to and used by the system. You can specify that certain system properties should be used in your metadata.
To configure system properties for a job definition:
On the Create Job Definition page, expand the System Properties section.
Click the Add icon.
The Add System Property dialog box displays.
From the Name dropdown list, select the system property you want to specify. Possible system properties are shown in Table 5-1.
Table 5-1 System Properties
System Property | Description |
---|---|
|
For a process job type, this specifies a string representing the command line command on Unix. If the SYS_cmdLine property is defined, this property is ignored. |
|
For a process job type, this specifies a string representing the command line command on Windows. If the SYS_cmdLine property is defined, this property is ignored. |
|
For a process job, this specifies the directory where the process executable is located on Unix. |
|
For a process job, this specifies the directory where the process executable is located on Windows. |
|
For a process job, this specifies the name of the process executable. |
|
Specifies the suffix for SYS_EXT_executableName on Unix. The default is ".sh". |
|
Specifies the suffix for SYS_EXT_executableName on Windows. The default is ".cmd". |
|
For process and Java job types, this specifies a value that prompts Oracle Enterprise Scheduler to automatically export any previously imported output files to the request's output directory at the start of the execute stage. Using this property assumes that the request sets the SYS_EXT_supportOutputFiles property to "output" and the SYS_EXT_executeAutoExport property to "true". This can be useful in the case that RequestFileDirectory is a local directory and the execute stage needs access to output files that were created in the pre-processor or during a previous execution attempt, in case of retry. |
|
Set this to "true" to specify that the current job is Fusion Applications CP job type. |
|
For a process job, this specifies the arguments. |
|
Specifies the log level for Java and PL/SQL request loggers. The default is "INFO". |
|
For a process job type, after the job is successfully started, this property provides a place for Oracle Enterprise Scheduler to save the actual command line (with substitution performed). This property is for diagnostic purposes only. It is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
|
Specifies a string indicating whether the job will create files in the file system. The following values are supported:
|
|
Set this to "copy" to have Oracle Enterprise Scheduler upload request log and output files from its content store to a separate repository (UCM). The request log and output content will remain in the content store, but will also be available to user interfaces and tools that expect log/output in UCM. |
|
Set this to "true" to get environment properties from Fusion Applications-style files. The default is "false". |
|
Set this to "true" to have Oracle Enterprise Scheduler set up extended functionality, such as ApplSession, for each stage of the request if that functionality is available. |
|
For process and Java job types that may create files in the file system, this will prompt Oracle Enterprise Scheduler to save in the request the configured RequestFileDirectory and RequestFileDirectoryShared from the ess-config.xml file. These values are saved as the properties SYS_userFileDir and SYS_EXT_userFileDirShared, respectively. Oracle Enterprise Scheduler uses these properties to create the request work and output directories, depending on SYS_EXT_supportOutputFiles. This for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
|
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. |
|
Specifies the logical name of the J2EE application used for request processing. This property is automatically set by Oracle Enterprise Scheduler during request submission. |
|
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 4.2.2.2 |
|
Specifies the Java executable for a Java job request. This should be the name of a Java class that implements the |
|
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. |
|
Specifies 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 |
|
Specifies 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. |
|
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. Values for this property are:
If this property is not specified, the system defaults to |
|
For internal use only. |
|
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. |
|
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. |
|
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. |
|
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. |
|
Specifies the event listener class associated with the request. This should be the name of a Java class that implements the |
|
Specifies a language code to apply to the job. |
|
Specifies the logging working directory. This is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
|
Specifies output from a request. The output of a serial job set is the |
|
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 is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
|
Specifies the post-process callout handler class. This should be the name of a Java class that implements the |
|
Specifies the pre-process callout handler class. This should be the name of a Java class that implements the |
|
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. |
|
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. |
|
Specifies the product within the application that submitted the request. |
|
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 process when the request is executed. This is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
|
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. |
|
Specifies that job request can time out. |
|
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. |
|
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 |
|
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. |
|
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 using metadata and cannot be specified as a submission parameter. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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 is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. Note that if this property is deleted, its value defaults to a system-defined value of <server log path>/ess_request/ and the value of the SYS_EXT_userFileDirShared property is assumed to be false. |
|
Specifies the name of the user used to execute the request. Normally, this is the submitting user unless the |
|
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. |
|
Specifies the working directory for the process of a process job request. This is for use by Oracle Enterprise Scheduler and other values might be overwritten by the service. |
In the Initial Value text field, enter the value you want to assign to the system property.
Select the Read Only check box to have this property be read-only to the user.
Click OK.
You can specify the level of access to this metadata that groups of users have. The roles you visible here are defined in a jazn.xml file used by the application.
On the Create Job Definition page, expand the Access Control section.
Click the Add icon.
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. Users grouped by that role will have the level of access you specify here.
Select the actions you want to allow role members to take: Read, Execute, Update and Delete.
You can delete a job definition.
To delete a job definition:
Search for the relevant job definition, as described in Section 5.2.1.1.
In the Results table, select the job definition you want to delete and click the Delete icon.
You can view, create, edit, delete and search for job sets, which are collections of job requests that can be grouped together to run as a single unit. You can nest a job set so 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.
You manage job sets with the Job Sets page in Fusion Middleware Control.
Figure 5-1 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.
Figure 5-1 The Job Sets Page and Results Table
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 the application you selected display in the Results table below the Filter Criteria section of the page.
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 job set you're interested in.
You define a job set as either serial or parallel. At runtime, Oracle Enterprise Scheduler runs parallel job set steps together, in parallel. When a serial job set runs, on the other hand, Oracle Enterprise Scheduler runs the steps one after another in a specified sequence. With 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 taken on 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.
From the Applications dropdown list, select the name of the application for which you want to create or edit job sets.
Click Create to define a new job set, or Edit to modify an existing job set.
In the Name field, enter the name of the job set. 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 section, 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, click the search button. In the window that displays, select the job or job set that you want to use for this step, then click OK.
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 select actions 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.2.1.2.1.
In the System Properties tab, click the Add icon to select system properties and enter their initial value in the field provided. For more information about selecting system properties, see Section 5.2.1.2.2.
Click OK.
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.
If your job set requires them, define parameters and system properties in sections toward the bottom of the job set window.
Configure access control for the job set. For more on defining access control, see Section 5.2.1.2.3.
On the Create Job Set page, 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.2.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 should not run simultaneously with one another.
An incompatibility defines either a global incompatibility or a domain-specific, property-based incompatibility.
This section contains the following topics:
The Incompatibilities page displays an incompatibility's name, the Java package associated it, 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 Application 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 incompatibility's name.
An incompatibility consists of two or more job definitions configured as incompatible, and optionally the resource over which they need to be incompatible. A resource is not specified for a global incompatibility.
In a domain incompatibility, the 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.
The following gives more information about the difference between domain and global incompatibilities:
Domain-specific: In a domain incompatibility, 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.
You add two or more job definitions as incompatible within the scope of a resource, where the resource is identified by a system property name or a parameter name. Each entity can use the same property name or a different property name. For a property-based incompatibility, you must specify a job definition or a job set and a property name for each entity.
Global: In a global incompatibility, Oracle Enterprise Scheduler ensures that requests for the incompatible Jobs or job sets do not run at the same time.
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.
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.
From the Application dropdown list, select the name of the application whose incompatibilities you want to create or edit.
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 section, click the Add icon to add jobs to the incompatibility.
The Add Entity dialog box displays.
Select one or more jobs and click OK.
If this is a domain incompatibility, select each entity listed in the Entities table, click the Edit icon, and select the property whose value should be incompatible with the other entities in the list.
If entities in the list are self incompatible -- meaning that they should not run simultaneously with other instances of the same entity -- edit the entity and select the Self Incompatible check box.
Configure access control for the incompatibility, as described in Section 5.2.1.2.3.
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.2.3.1.
In the Results table, select the incompatibility you want to delete and click the Delete icon.
With work allocation, you can define 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 default work assignment is limited to the number of threads configured for the processor, but there is no default limit for asynchronous workers. To limit asynchronous workers, it is necessary to create and bind one or more work assignments.
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 percent while the weight for work assignment 2 is 30 percent. 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-2 shows the properties that you can define for specialization rules.
Table 5-2 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 labels defined by the system administrator allowing administrators to group job requests for specific needs. You can include multiple labels that are separated by a delimiting character. |
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-1 shows sample specialization rules that can be used in a work assignment.
Example 5-1 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. In fact, different stages of the same request may be processed on different servers, such as pre-processing on one server and job execution on another server.
Note that the requestCategory value can be several label terms separated by a comma. In this way you can specify labels that mimic the behavior of tags, with specializations based on combinations of labels.
For example, you could define the following labels:
Example 5-2 Request Category Labels That Combine Terms
",NODE1,CRITICAL," ",NODE1,STANDARD," ",NODE1,IMPORTANT,"
Assuming the preceding labels, you could write a requestCategory expression such as the following examples:
Example 5-3 requestCategory Expressions That Use Multiple Combined Labels
(requestCategory contains ',NODE1,') AND (requestCategory contains ',CRITICAL,') (requestCategory contains ',STANDARD,') OR (requestCategory contains ',IMPORTANT,') OR (requestCategory contains ',CRITICAL,')
If you use commas to delimit terms, you must enclose every separate label term with the comma on both sides, as shown in Example 5-2. Your requestCategory expression must specify the full term including the commas, as shown in Example 5-3, to ensure that the expression doesn't select another term that contains the one you specify.
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 check box 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.
You can use different amounts of resources during different periods of time by using multiple workshifts, each with a different time window and resource limits. For example, you could create daytime workshift that starts at 8 a.m. and has your daytime thread allocation and async job limits; and you could create a nighttime workshift that starts at 6 p.m. and has your nighttime thread allocation and async job limits.
Note that workshifts may overlap, but Oracle Enterprise Scheduler will choose one workshift as the current workshift.
While there is at most one currently active workshift for a given work assignment, there may still be active requests for a workshift that is no longer active. This can happen if a request runs beyond the defined operating window for the workshift it started running in. For example, if a request started running while the daytime workshift was active and that request is still running when the nighttime workshift starts. Oracle Enterprise Scheduler uses the limits of the currently active workshift and accounts for all active requests that started during any workshift in the work assignment. If the number of active requests exceeds the current limit, no more requests will be run until the number of active requests drops below the limit.
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 Schedule page displays.
Enter the following information:
Name: Enter a name for the schedule.
Description: Optionally, add descriptive text for the schedule.
Frequency: From the dropdown, select how often you want items using this schedule to run. Each frequency option will have its own way to specify details for the option. As you specify details, note that you can click calendar icons to specify time zones as well.
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.
You can manage the level of access assigned for working with job metadata. Using Fusion Middleware Control, you can create policies that grant permissions for resources in your application.
You grant permissions by associating specific actions with resources, then granting those permissions (or permission/resource combinations) to particular users, groups, or roles.
When granting permissions, you specify the actions that someone can take with a given resources. Table 5-3 lists possible actions.
Table 5-3 Grant Actions for Metadata Security
Action | Effect |
---|---|
|
Read the job metadata. |
|
Submit a job request. |
|
Add metadata. |
|
Change the metadata. |
|
Delete the metadata. |
The resources with which you associate permissions are expressed as entities known to the application, such as by the entities' containing package. That list includes items you or application developers might have defined as well as items Oracle Enterprise Scheduler has defined. Table 5-4 lists a few examples of the effect of granting permission for certain actions to certain resources.
Table 5-4 Sample Permission Grants for Security
Resource | Actions | Effect |
---|---|---|
|
|
Grants the ability to submit requests for a single metadata item. |
|
|
Grants to ability to create and execute any new metadata items in /mypackage/subpackage |
|
|
Grants ad hoc submission permission |
|
|
Grants wide-open permissions |
You can use Enterprise Manager to create functional To manage metadata permissions:
From the navigation pane, expand the WebLogic Domain folder and select the domain for which you're creating policies.
From the WebLogic Domain menu, select Security and then select Application Policies.
The Application Policies page displays.
In the Search section, from the Application Stripe dropdown, select the application stripe with which you want to work.
Click Create to begin granting permissions to certain users, groups, or application roles.
The Create Application Grant page appears.
In the Create Application Grant page, in the Grantee section, click Add.
In the Add Principal window, from the Type dropdown, select a type of principal, then enter a principal name or display name and click the search button to find the principal you want to add.
Under Search Principals, click the principal you want, then click OK.
In the Permissions section, click Add.
In the Search section, click Permissions.
From the Permission Class dropdown, select oracle.as.scheduler.security.MetadataPermission.
Click the Search button.
Under Search Results, select the resource to which you want to assign permissions.
The Search Results table lists resources that represent entities known to the application. Table 5-4 lists a few examples.
Click Continue.
In the Add Permission window, in the Permission Actions field, edit the comma-separated list of permission actions so that the list reflects the permissions you want to grant.
Table 5-3 lists possible actions.
Click OK.