Skip Headers
Oracle® Enterprise Manager Cloud Control Extensibility Programmer's Guide
12c Release 4 (12.1.0.4)

E25159-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Using the Jobs Framework

This chapter includes the following topics:

6.1 Introduction to the Jobs Framework

Enterprise Manager includes a job framework for managing the automation of administrative tasks performed against targets or groups of targets. The automation framework is tightly integrated with other Enterprise Manager subsystems such as targets, credentials, events, and so on, so the customer can monitor as well as manage their targets from the single console.

You can support automation requirements for target types defined in your plug-in by using the interfaces provided by the job framework. You can define job types as part of your plug-in, providing the automated support of critical administrative capabilities.

Enterprise Manager administrators can then schedule, execute, and monitor those jobs, in order to manage the targets supported by the plug-in. These jobs may be used to enforce management best practices, respond to alerts as corrective actions, and to otherwise automate the management of the enterprise in general.Enterprise Manager includes a job console that allows administrators to submit and monitor the execution of jobs.

6.2 What's New in Jobs?

The following features are new to this release:

6.2.1 About Credentials Enhancements

Before Oracle Enterprise Manager 12c Release 4 (12.1.0.4), job credentials were represented as two parameters, one for the user name and one for password. This required knowledge about the credential set, credential types and their columns, and also knowledge about various authentication mechanisms that would be supported by the job type, irrespective of the pool of authentication schemes that could be supported by Enterprise Manager.

To overcome these issues and to evolve a unified mechanism in the job type to specify the credentials, Oracle introduced a new concept called credential usage. Credential usage allows for a more direct link between the job type and a set of credentials, without having to specifically reference individual items included in the credentials. For information about specifying credential information, see the Enterprise Manager Programmer's Reference.

6.2.1.1 Understanding Credential Types

The credential type is the type of authentication supported by a target type. For example, a host can support a user name/password based authentication, public key authentication, or kerberos authentication. Various authentication schemes are supported, including native agent authentication and SSH.

The native agent authentication scheme employs a user name/password structure, while the SSH Key authentication scheme user a user name/private key/public key structure.

6.2.1.2 About Named Credentials

A named credential is a users' authentication information on a system. A named credential can be a user name/password, a public key-private key pair, or an X509v3 certificate. An Enterprise Manager administrator can store these credentials as named entities in Enterprise Manager to use when performing operations like running jobs, patching, and other system management tasks. For example, you can store the user name and password that you want to use for patching as MyPatchingCreds. You can then later submit a patching job that uses MyPatchingCreds to patch the production databases.

6.2.2 Overview of Logging Enhancements

Starting in Oracle Enterprise Manager 12c Release 4 (12.1.0.4), Oracle is providing an Enterprise Manager Diagnosability Framework to help improve diagnosability within the various Enterprise Manager components. This framework captures structured first failure diagnostic data easily and automates the process of diagnostic data collection, packaging, and uploading to Oracle.

When you are defining job types in your plug-in, you can take advantage of this framework by logging messages from a job step running on the Management Agent.

6.3 Understanding Jobs

A job is the unit of work to be run by the job system. An administrator creates a job and specifies a schedule for when the job should run, such as patch system B at midnight Sunday. The Management Server schedules and runs jobs.

A job is based on a job type definition that defines the steps included in the job as well as the parameters required as input to run the job and the credentials necessary to access the targets accessed by the job. When a job is submitted, the values for parameters and credentials are supplied by the submitter.

A job execution is a collection of inter-related job steps. Steps can be grouped into step-sets. Steps within a step-set can run serially (one after another) or in parallel (simultaneously), but not both. Steps (and step-sets) can also be run depending on the success or failure of the other steps. For more information about these concepts, see the Enterprise Manager Programmer's Reference.

The steps in a job can process commands, scripts, and so on, on the Management Agent. Enterprise Manager provides several common commands that can be included in job type definitions that you create. These include such commands as remote operation (allows script execution), and file transfer commands including put and get.

The commands associated with each step are typically run on a remote node through the Management Agent. The coordination and overall status of a job is maintained by the Management Server and stored in the Management Repository.

Figure 6-1 Jobs Overview

jobs overview

A job may have one or more target lists. However, some jobs do not have targets and for these jobs the target list is empty or null. The target list is a set of targets that are required for one execution of the job. It is up to the job type to interpret the target list. For example, the OSCommand job type runs the specified command with the specified parameters in parallel against all the targets in the list. A job that clones schema in a database might interpret its target list a little differently. It might, for instance, consider the first target to be the source database from which to clone. It might consider the second argument to be a target database where it should populate the cloned schema. Note that a job can be submitted with multiple target lists, each one resulting in a separate execution.

Finally, every job must have a schedule. A schedule specifies when the job will run. The job system provides extensive scheduling capabilities including the ability to submit a job for immediate execution or to submit a job to run repeatedly according to any number of different scheduling options.

6.3.1 Defining Job Types

A job type is a specific job category, which carries out a well-defined unit of work. A job type is uniquely identified by a name. For example, AppPatch could be a job type that applies a patch to an Oracle applications installation. OSCommand could be a job type that runs a remote command, and so on.

A job type can be defined by an XML document that specifies the steps in the job, the work (command) that each step performs, and the relationships between the steps. Job types are included in a plug-in by using the jobType metadata service.

In addition to the job type definition, it is necessary to package any scripts referenced by the job type with the plug-in, as part of the Management Agent deployment.

For information about the definition and packaging of jobs, see the Enterprise Manager Programmer's Reference.