Application Development Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring the Complex Event Processor

This section contains information on the following subjects:

 

Overview of the Complex Event Processer Configuration File

Your Oracle Complex Event Processing (or Oracle CEP for short) application contains one or more complex event processors, or processors for short. Each processor takes as input events from one or more adapters; these adapters in turn listen to data feeds that send a continuous stream of data from a source. The source could be anything, from a financial data feed to the Oracle CEP load generator. The main feature of a processor is its associated Event Processing Language (EPL) rules that select a subset of the incoming events to then pass on to the component that is listening to the processor. The listening component could be another processor, or the business object POJO that typically defines the end of the event processing network, and thus does something with the events, such as publish them to a client application.

Each processor in your application must have an associated XML file that defines its initial configuration. This XML file is deployed as part of the Oracle CEP application bundle. You can later update this configuration at runtime using the wlevs.Admin utility or manipulating the appropriate JMX Mbeans directly.

In addition to configuring the initial set of EPL rules of the processor, you can configure the following in the processor XML file:

You are required to create a configuration XML file for each processor in your application. If your application has more than one processor, you can create separate XML files for each processor, or create a single XML file that contains the configuration for all processors. Choose the method that best suits your development environment.

You can optionally create configuration files for the other components in your application (adapters and streams), although if their default configuration is adequate you do not need to change it. If you do create configuration files for these components, you can create separate files or combine them with the processor configuration file(s).

 

Configuring the Complex Event Processor: Main Steps

This section describes the main steps to create the processor configuration file. For simplicity, it is assumed in the procedure that you are going to configure all processors in a single XML file, although you can also create separate files for each processor.

See Example of a Processor Configuration File for a complete example of a processor configuration file.

See XSD Schema Reference for Component Configuration Files for the complete XSD Schema that describes the processor configuration file.

  1. Design the set of EPL rules that the processor executes. These rules can be as simple as selecting all incoming events to restricting the set based on time, property values, and so on, as shown in the following two examples:
    2. SELECT * from Withdrawal RETAIN ALL
    SELECT symbol, AVG(price) 
    FROM (SELECT * FROM MarketTrade WHERE blockSize > 10)
    RETAIN 100 EVENTS PARTITION BY symbol WITH LARGEST price
    GROUP BY symbol
    HAVING AVG(price) >= 100
    ORDER BY symbol

    EPL is similar in many ways to Structure Query Language (SQL), the language used to query relational database tables, although the syntax between the two differs in many ways. The other big difference is that EPL queries take another dimension into account (time), and the processor executes the EPL continually, rather than SQL queries that are static.

    For additional conceptual information about EPL, and examples and reference information to help you design and write your own EPL rules, see the EPL Reference Guide.

  2. Create the processor configuration XML file that will contain the EPL rules you designed in the preceding step, as well as other optional features, for each processor in your application.

    3. You can name this XML file anything you want, provided it ends with the .xml extension.

    The root element of the processor configuration file is <config>, with namespace definitions shown in the next step.

  3. For each processor in your application, add a <processor> child element of <config>. Uniquely identify each processor with the <name> child element. This name must be the same as the value of the id attribute in the <wlevs:processor> tag of the EPN assembly file that defines the event processing network of your application. This is how Oracle CEP knows to which particular processor component in the EPN assembly file this processor configuration applies. See Creating the EPN Assembly File for details.

    4. For example, if your application has two processors, the configuration file might initially look like: 

    <?xml version="1.0" encoding="UTF-8"?>
    <n1:config xsi:schemaLocation="http://www.bea.com/xml/ns/wlevs/config/application  wlevs_application_config.xsd"
     xmlns:n1="http://www.bea.com/xml/ns/wlevs/config/application" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <processor>
        <name>firstProcessor</name>
         ...
      </processor>
      <processor>
        <name>secondProcessor</name>
         ...
       </processor>
    </n1:config>

    In the example, the configuration file includes two processors called myFirstProcessor and mySecondProcessor. This means that the EPN assembly file must include at least two processor registrations with the same identifiers: 

    <wlevs:processor id="firstProcessor" ...>
      ...
    </wlevs:processor>

    <wlevs:processor id="secondProcessor" ...>
    ...
    </wlevs:processor>

    WARNING: Identifiers and names in XML files are case sensitive, so be sure you specify the same case when referencing the component’s identifier in the EPN assembly file.
  4. Add a <rules> child element to each <processor> to group together one or more <rule> elements that correspond to the set of EPL rules you have designed for this processor.

    5. Use the required id attribute of the <rule> element to uniquely identify each rule. Use the XML CDATA type to input the actual EPL rule. For example: 

    <processor>
        <name>firstProcessor</name>
        <rules>
          <rule id="myFirstRule"><![CDATA[
          SELECT * from Withdrawal RETAIN ALL
          ]]></rule>
          <rule id="mySecondRule"><![CDATA[
          SELECT * from Checking RETAIN ALL
          ]]></rule>
        </rules>
    </processor>
  5. Optionally add a <database> child element of the <processor> element to define a JDBC data source for your application. This is required if your EPL rules joing a stream of events with an actual relational database table.

    6. Use the <name> child element of <database> to uniquely identify the datasource.

    Use the <data-source-name> child element of <database> to specify the actual name of the data source; this name corresponds to the <name> child element of the <data-source> configuration object in the config.xml file of your domain. For details about configuring the server, see Configuring Access to a Relational Database.

    For example: 

    <processor>
        <name>firstProcessor</name>
        <rules>
        ....
        </rules>
        <database>
          <name>myDataSource</name>
          <data-source-name>rdbmsDataSource</data-source-name>
        </database>
    </processor>
  6. Optionally use the monitoring Boolean attribute of the <processor> element to enable or disable monitoring of the processor; by default monitoring is enabled. When monitoring is enabled, the processor gathers runtime statistics, such as the number of events inbound and outbound on it, and forwards this information to an Mbean:
    7. <processor monitoring="true">
        <name>firstProcessor</name>
        <rules>
        ....
        </rules>
    </processor>

    To truly enable monitoring, you must have also enabled the manageability of the processor, otherwise setting the monitoring attribute to true has no effect. You enable manageability by setting the manageable attribute of the corresponding component registration in the EPN assembly file to true, as shown in bold in the following example: 

    <wlevs:processor id="firstProcessor" manageable="true" />

 

Example of a Processor Configuration File

The following example shows how to configure one of the sample EPL queries shown in Configuring the Complex Event Processor: Main Steps for the myProcessor processor: 

<?xml version="1.0" encoding="UTF-8"?>
<n1:config xsi:schemaLocation="http://www.bea.com/xml/ns/wlevs/config/application  wlevs_application_config.xsd"
 xmlns:n1="http://www.bea.com/xml/ns/wlevs/config/application" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<processor>
    <name>myProcessor</name>
    <rules>
      <rule id="myRule"><![CDATA[
      SELECT symbol, AVG(price) 
      FROM (SELECT * FROM MarketTrade WHERE blockSize > 10)
      RETAIN 100 EVENTS PARTITION BY symbol WITH LARGEST price
      GROUP BY symbol
      HAVING AVG(price) >= 100
      ORDER BY symbol
      ]]></rule>
    </rules>
  </processor>
</n1:config>

In the example, the <name> element specifies that the processor for which the single EPL rule is being configured is called myProcessor. This in turn implies that the EPN assembly file that defines your application must include a corresponding <wlevs:processor id="myProcessor" /> tag to link this EPL rules with an actual myProcessor processor instance.


  Back to Top       Previous  Next