Release 1.6
A63733-01
Library |
Product |
Contents |
Index |
| Oracle
Enterprise Manager Application Developer's Guide
Release 1.6 A63733-01 |
|
This chapter introduces Oracle Enterprise Manager (OEMGR) and the process of integrating applications with Enterprise Manager. Topics include:
Oracle Enterprise Manager (OEMGR) is Oracle's new generation of enterprise-wide system management tools that solves the problem of managing distributed Oracle systems with:
System management applications and utilities developed by
Oracle or by third-party vendors can be integrated with the Console, providing
a single point of control for system management.
The Console and integrated applications communicate using
Microsoft's OLE2 technology. This technology allows applications to easily
integrate into the Console. This guide describes the set of application
programmer interfaces (APIs) to Enterprise Manager Console and its services.
These external interfaces allow developers to create tools that integrate
into the Console. By adding applications that Oracle, third-parties, or
you create, you can enhance or increase the scope of Oracle Enterprise
Manager's capabilities.
To the end user of Oracle Enterprise Manager, the Console
looks like a window with several components. See Figure
1-1, "Oracle Enterprise Manager Console".
The components that function with the Oracle Enterprise Manager Console are:
You can launch an application from the Console by clicking
the application's icon in a tool palette or by selecting the application's
menu item in the Tools menu. When you integrate your application, your
application's icon appears in the appropriate tool palette, and a menu
item for your application appears in the Tools menu.
You can integrate your application into Oracle Enterprise
Manager Console with tool palette and menu integration. See Chapter
2, "Tool Palette and Menu Integration".
Underlying the Console are various common services that applications can use. These services are:
The repository is used to store system information that Oracle
Enterprise Manager collects and uses. The repository consists of a set
of internal tables installed in an Oracle database either locally on the
host PC or remotely on the network. The repository external interfaces
allow application developers to retrieve user preferences from the repository
and to store their own information in the repository. See Chapter
4, "Repository Control Integration".
The discovery cache is responsible for servicing requests for information about the network and its services. The cache holds the current state of each node and service on the network. The discovery cache keeps track of:
Information in the discovery cache is retrieved with the
Navigator Service Discovery option or by reading Oracle Parallel Server
information in the topo_ops.ora file. The discovery cache also keeps track
of user-defined groups. A Console user can create named groups of nodes
or services. A group can contain only nodes or services of the same type.
For example, a user can create a group of listeners or a group of databases.
A group can also contain a sub-group. The sub-group must be of the same
type as the group. For example, a group of databases can also contain a
sub-group of databases.
The discovery cache is also responsible for discovering and
maintaining lists of all user-defined service types. User-defined services
are accounted for in the same way as internally defined service types.
The discovery cache interfaces allow application developers
to retrieve information about nodes, services, and user-defined groups.
See Chapter 6, "Discovery Cache Integration".
The Navigator provides a tree listing of the nodes, objects,
services, and other objects that can be administrated in the system. Each
object type is identified by an icon. You specify the icons you want to
appear for the services. You can administer each of these objects individually,
and you can navigate between them by expanding and collapsing parts of
the Navigator tree. The Map provides a graphical view of the objects in
the system.
You can define your own service types to appear within the
Navigator and on the Map. You must implement an interface that the discovery
cache will call to discover which services are a part of the network environment.
After these services have been discovered, they appear in the Navigator
and the Map just as any internally-defined service type, such as databases
or listeners.
You can use the Related Tools menu to launch applications
to administer selected services. You can also use the Quick Edit command
to launch property sheets from the Console user interface. From within
the Console, you can specify preferred credentials for each of your services.
See Chapter 5, "Navigator and
Map Integration".
The Job Scheduling system allows users to create, schedule,
and delete jobs. The Console user interface provides property sheets and
dialog boxes to perform these operations, and to view information about
jobs in the system. The Job Scheduling system interfaces allow you to submit
both batch and interactive jobs.
A job is a Tcl script that is executed remotely via the Oracle
intelligent agent. There are predefined jobs that ship with Enterprise
Manager, but applications developers can write new job scripts using the
Tcl language. For information on job scripts, see Chapter
9, "Jobs and Events Scripts".
The Job Scheduling system external interfaces allow application
developers to create and manage jobs. The Job Scheduling system can also
notify the submitter of a job whenever there is a change in the job's status.
See Chapter 7, "Job Scheduling Integration".
The Event Management system (EMS) allows you to set up, register,
and manage events on selected destinations in the network. EMS provides
a mechanism for alerting administrators about possible or actual problems
with selected services, such as databases or nodes. An event is a Tcl script
that is executed remotely via the Oracle intelligent agent. There are numerous
predefined events that ship with Enterprise Manager.
You can integrate into the EMS in two ways. On the Console
machine, you can build an application which registers interest in a set
of events and gets notifications when they are fired. On a remote node,
you can send your own customized event information through the Oracle Intelligent
Agent back to the Console machine. Integrating in both of these ways together
can provide a powerful end-to-end communications from your remote services
to your administration applications. See Chapter
8, "Event Management Integration".
Some general programming considerations are:
Use of OLE2 does not commit the third-party developer to
the use of any particular programming language or model. However, throughout
the documentation and code examples, Microsoft Foundation Classes (MFC)
and Microsoft Visual C++ conventions are used. You do not have to use this
class library or compiler, but it is strongly recommended.
The SDK provides a library of C++ classes and functions which
make the development of integrated applications much easier. Classes are
provided to save you the trouble of implementing much of the routine, uninteresting,
or complicated OLE2 process.
All of the code you need to build using the library is provided
within the SYSMAN\SDK\VOX subdirectory in the ORACLE_HOME directory.
The ORACLE_HOME directory is the location where Oracle products
have been installed. The default for Windows NT is the ORANT directory.
Two static import libraries are provided within the SYSMAN\SDK\VOX\LIB
subdirectory: vox.lib for release builds, and voxd.lib for debug builds.
These correspond to the two DLLs that your applications will use, vox.dll
and voxd.dll, both of which are supplied with the Oracle Enterprise Manager
Console. Note that you can link with and run the debug DLL with a debug
version of your application yet still execute side-by-side with the release
(non-debug) version of the console. All of the header files that you might
need to include can be found in the ORACLE_HOME\SYSMAN\SDK\VOX\INCLUDE
subdirectory.
The SDK comes with two sample applications that provide examples
of calls to the Oracle Enterprise Manager Console OLE APIs and demonstrate
the use of the VOX library. The first application, smpsrv (SMP sample SeRVer),
demonstrates the use of almost all the functionality exposed by the console,
including launch in context, repository and discovery cache calls, job
submission and notification, and event registration and notification. The
second application, smpxsrvc (SMP eXternal SeRViCe), is an example of how
to create an OLE service for Navigator and Map integration. All of the
files necessary to each project can be found within the SYSMAN\SDK\ subdirectories.
Makefiles are included with the samples in order to build
working executables. The makefiles are configured based on the assumption
that your ORACLE_HOME is C:\ORANT. If it is not, you will need to reconfigure
them accordingly. Move the executables into the ORACLE_HOME\BIN subdirectory
after they have been built, and then execute either smpsrv.reg or smpxsrvc.reg
as appropriate. You then have working examples that you can use and debug.
Most likely you will find it very useful during the development of your
application to test its functionality against that of the smpsrv application.
Both of the sample applications are designed to be used primarily
as examples of code use and integration techniques. They have not been
developed as full fledged applications for end user use; their user interfaces
are functional but unrefined. Most of the dialogs in smpsrv, for example,
are just thin wrappers around the underlying API they are meant to demonstrate.
They do not pretend to maintain state or re-synchronize properly, and as
such should be used for one invocation of the API and then dismissed.
Throughout this book there are references to the source code
files where you can find examples for the functionality that is being discussed.
All strings that are returned to your application are buffers
of wide characters (UNICODE).
