Release 1.4.0
A53701_01
 Library |
 Product |
 Contents |
 Index |
| Oracle Enterprise Manager Application Developer's Guide Release 1.4.0 A53701_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 4.2 (MFC) and Microsoft Visual C++ 4.2 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).
