Skip Headers
Oracle® Fusion Middleware Visualizer User's Guide for Oracle Event Processing
11g Release 1 (

Part Number E14302-09
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

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

9 Overview of Server and Domain Tasks

This chapter introduces typical server and domain management tasks you can perform with Oracle Event Processing Visualizer, including managing deployment, multi-server domains, logs, caches, the event type repository, and more.

This chapter includes the following sections:

9.1 Deployment Management

Using the Oracle Event Processing Visualizer, you can view the applications and application libraries deployed to a selected Oracle Event Processing server.

For more information, see:

9.2 Jetty Management

Oracle Event Processing supports Jetty (see as the Java Web server to deploy HTTP servlets and static resources.

Oracle Event Processing support for Jetty is based on Version 1.2 the OSGi HTTP Service. This API provides the ability to dynamically register and unregister javax.servlet.Servlet objects with the run time and static resources.

Oracle Event Processing allows you to configure how your application prioritizes the execution of its work. Based on rules you define and by monitoring actual run time performance, you can optimize the performance of your application and maintain service level agreements. You define the rules and constraints for your application by defining a work manager.

For more information, see:

9.3 JMX Management

Oracle Event Processing provides standards-based interfaces that are fully compliant with the Java Management Extensions (JMX) specification. Software vendors can use these interfaces to monitor Oracle Event Processing MBeans, to change the configuration of an Oracle Event Processing domain, and to monitor the distribution (activation) of those changes to all server instances in the domain.

Oracle Event Processing Visualizer and the wlevs.Admin command line tool both use JMX to connect to a server. However, to use these tools, and the JMX interfaces in general, you must configure Oracle Event Processing with the JMX configuration information in the config.xml file.

For more information, see:

9.4 Data Source Management

Oracle Event Processing supports Java Database Connectivity (JDBC) 3.0 for relational database access.

The JDBC API provides a standard, vendor-neutral mechanism for connecting to and interacting with database servers and other types of tabular resources that support the API. The JDBC javax.sql.DataSource interface specifies a database connection factory that is implemented by a driver. Instances of DataSource objects are used by applications to obtain database connections (instances of java.sql.Connection). After obtaining a connection, an application interacts with the resource by sending SQL commands and receiving results.

For more information, see:

9.5 HTTP Publish-Subscribe Server Management

Oracle Event Processing includes an HTTP publish-subscribe server to which applications can publish messages. Applications publish messages to a particular channel; other applications can then subscribe to this channel to receive these published messages.

Oracle Event Processing HTTP pub-sub server channels may be:


When one application (application-1) advertises a channel that a second application (application-2) subscribes to and uses as a foreign stage, you cannot view the details of the advertised channel from application-2. To view the details of this channel, you must do so from application-1.

You can use Oracle Event Processing Visualizer to modify existing channels, as well as create new ones and delete existing ones. When you configure channels with Oracle Event Processing Visualizer, they are permanent and survive server restart. Channels configured using APIs from a custom HTTP pub-sub adapter are dynamic and do not survive server restart.

For more information, see:

9.6 Event Type Repository Management

Event types define the properties of the events that are handled by Oracle Event Processing applications. All the event types used by the applications of a server make up the event type repository.

For more information, see:

9.7 Persistent Event Store Management

The Oracle Event Processing event repository feature allows you to persist the events that flow out of a component of the event processing network (EPN) to a store, such as a database table, and then play them back at a later stage or explicitly query the events from a component such as an event bean. By default, Oracle Event Processing stores recorded events in a database, which means that before you can start using the record and playback feature in your own application, you must specify where the database server is located along with the name of the database server that will contain the recorded events.

For more information, see:

9.8 Multi-Server Domain Management

An Oracle Event Processing multi-server domain (or cluster) is a set of two or more servers logically connected for the purposes of management, and physically connected using a shared User Datagram Protocol (UDP) multicast address and port. All servers in an Oracle Event Processing multi-server domain are aware of all other servers in the domain and any one server can be used as an access point for making changes to the deployments in the domain.

Oracle Event Processing supports the following clustering systems:


Any changes to rules and Oracle high availability adapters are propagated to the other servers in the same group. That is, all rule and and Oracle high availability adapter configurations is automatically synchronized. Other configuration changes are not synchronized. For example, if you change record/playback or JMS adapter configuration on one server in a multi-server domain, then these changes are not synchronized with the other servers in the same group. For more information, see:

For more information, see:

9.9 Event Inspector Service Management

Using the Event Inspector service, you can:

You can use the Event Inspector service to test and debug Oracle CQL queries during development.

For more information, see:

9.10 Cache Management

A cache is a temporary storage area for events, created exclusively to improve the overall performance of your Oracle Event Processing application; it is not necessary for the application to function correctly. Oracle Event Processing applications can optionally publish or consume events to and from a cache to increase the availability of the events and increase the performance of their applications.

A caching system refers to a configured instance of a caching implementation. A caching system defines a named set of configured caches as well as the configuration for remote communication if any of the caches are distributed across multiple machines.

Oracle Event Processing supports the following caching systems:

For more information, see:

9.11 Log Management

Oracle Event Processing Visualizer allows you to change the server-wide logging configuration, such as the severity of log messages you want the server to print out, the name of the log file, and so on.

You can also view and modify the logging level of individual components and configure logging for new components.

For more information, see: