![]() ![]() ![]() ![]() ![]() ![]() |
This section contains information on the following subjects:
Your WebLogic Event Server 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 WebLogic Event Server 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 WebLogic Event Server 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).
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.
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.
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.
<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 WebLogic Event Server knows to which particular processor component in the EPN assembly file this processor configuration applies. See Creating the EPN Assembly File for details. 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:processorid="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. |
<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.
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>
<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.
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.xm
l file of your domain. For details about configuring the server, see
Configuring Access to a Relational Database.
<processor>
<name>firstProcessor</name>
<rules>
....
</rules><database>
</processor>
<name>myDataSource</name>
<data-source-name>rdbmsDataSource</data-source-name>
</database>
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:<processormonitoring="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"
/>
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.
![]() ![]() ![]() |