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:
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:
"Managing an Application Library" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
Oracle Event Processing supports Jetty (see http://www.mortbay.org/jetty/) 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:
"Configuring Jetty for Oracle Event Processing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
"Jetty Work Managers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
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:
"Configuring JMX for Oracle Event Processing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
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:
"Configuring JDBC for Oracle Event Processing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
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:
Static: those channels configured in the Oracle Event Processing server config.xml and used by Oracle Event Processing Visualizer itself.
Oracle Event Processing Visualizer includes the following static channels (preconfigured in config.xml) that are used by Oracle Event Processing Visualizer itself; they cannot be deleted or modified:
/evsmonitor
/evsalert
/evsdomainchange
Dynamic: those channels that are not configured in the Oracle Event Processing server config.xml but created dynamically when the Oracle Event Processing sever is running. You can view statistics for dynamic channels, including the number of messages sent to this channel and the number of subscribers. Dynamic channel configuration is read-only.
Oracle Event Processing Visualizer supports only the Event Inspector service dynamic channel.
User-defined: those static channels that your Oracle Event Processing application creates.
Note:
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:
Chapter 24, "Managing HTTP Publish-Subscribe Server Security"
"Configuring HTTP Publish-Subscribe for Oracle Event Processing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
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:
"Defining and Using Event Types" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
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:
"Storing Events in the Persistent Event Store" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
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:
evs4j: Oracle Event Processing native clustering implementation.
Oracle Coherence: a JCache-compliant in-memory distributed data grid solution for clustered applications and application servers. It coordinates updates to the data using cluster-wide concurrency control, replicates data modifications across the cluster using the highest performing clustered protocol available, and delivers notifications of data modifications to any servers that request them. You take advantage of Oracle Coherence features using the standard Java collections API to access and modify data, and use the standard JavaBean event model to receive data change notifications.
Note:
Before you can use Oracle Event Processing with Oracle Coherence, you must obtain a valid Oracle Coherence license such as a license for Coherence Enterprise Edition, Coherence Grid Edition, or Oracle WebLogic Application Grid. For more information on Oracle Coherence, see http://www.oracle.com/technology/products/coherence/index.html.
Note:
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:
Section 3.4.6, "Multi-Server Domains and Configuration History Management"
"Administering Multi-Server Domains With Oracle Coherence" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
"Administering Multi-Server Domains With Oracle Event Processing Native Clustering" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing
Using the Event Inspector service, you can:
View the events flowing out of any stage in the EPN
Inject events into any stage in the EPN
You can use the Event Inspector service to test and debug Oracle CQL queries during development.
For more information, see:
"Testing Applications With the Event Inspector" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
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:
Oracle Event Processing local cache: a local, in-memory single-JVM cache.
Oracle Coherence: a JCache-compliant in-memory distributed data grid solution for clustered applications and application servers. It coordinates updates to the data using cluster-wide concurrency control, replicates data modifications across the cluster using the highest performing clustered protocol available, and delivers notifications of data modifications to any servers that request them. You take advantage of Oracle Coherence features using the standard Java collections API to access and modify data, and use the standard JavaBean event model to receive data change notifications.
Note:
Before you can use Oracle Event Processing with Oracle Coherence, you must obtain a valid Oracle Coherence license such as a license for Coherence Enterprise Edition, Coherence Grid Edition, or Oracle WebLogic Application Grid. For more information on Oracle Coherence, see http://www.oracle.com/technology/products/coherence/index.html.
Third-party caches: you can create a plug-in to allow Oracle Event Processing to work with other, third-party cache implementations.
For more information, see:
"Configuring Oracle Event Processing Caching" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse
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:
"Configuring Logging and Debugging for Oracle Event Processing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Event Processing