Top
Interstage Big DataComplex Event Processing Server V1.1.0 User's Guide
FUJITSU Software
Chapter 5 Development > 5.4 Design (Definition File) > 5.4.4 Designing a Rule Definition
PreviousNext

5.4.4 Designing a Rule Definition

A rule definition consists of two types of rules: the filter rules to be used in high-speed filter processing and the complex event processing rules to be used in complex event processing.

This section explains the following items, including considerations when designing rules and the creation procedures to use:

5.4.4.1 High-speed Filter Processing

Define the filter rules to be used by the high-speed filter.

Considerations when creating filter rules

The items to consider when creating filter rules are as follows:

Processing pattern of filter rules

By defining filter rules in the high-speed filter, the user can describe event extraction as well as extraction and join processing in combination with master data. The output of the high-speed filter is used directly as the input of complex event processing.

The processes performed by the high-speed filter are generally represented by the following four patterns and their combinations:

5.4.4.1.1 Extraction process

This processing pattern extracts from the input events those events that meet the conditions described in IF-THEN statements in the filter rules.

Consider using this processing pattern if only the events required are to be extracted from massive volumes of events.

Example

Example of an extraction process

This is an example of extracting events using the content of the events (value).

"value > 10" is defined as the extraction condition.

Rule to be created

The rule to be created in the example above is as follows:

on inputEventTypeID {
    if ($value > 10) then output() as inputEventTypeID;
}

  • inputEventTypeID is the development asset ID of the target event type definition.

Information

Filtering the items in the events to be output

Items in the events to be output can also be filtered. Below is an example of outputting only "key" in the example shown above.

To output using a different format from that of the input events, a corresponding event type definition (filtered) will also be required.

Refer to Section 2.7, "Output Expression Format" in the Developer's Reference for details.

on inputEventTypeID {
    if ($value > 10) then output($key) as outputEventTypeID;
}

  • inputEventTypeID is the development asset ID of the target event type definition.

  • outputEventTypeID is the development asset ID of the event type definition (filtered) that represents the results of filtering the item.

5.4.4.1.2 Extraction process using master data matching

This processing pattern matches the relevant entries of master data (CSV files) on the basis of values such as those of the ID or code contained in the input events, and then extracts the events based on the values of the relevant entries.

Consider using this processing pattern if only the events required are to be extracted from massive volumes of events but the events themselves do not contain the information required for extraction.

To perform the processing of this pattern, a master definition must also be designed.

Example

Example of the extraction process using master data matching

This is an example of referencing the relevant entries of master data based on the "key" contained in the events, and then extracting the events based on the values of "address" in the entries. "address==Fukuoka" is defined as the extraction condition.

Rule to be created

The rule to be created in the example above is as follows:

on inputEventTypeID {
    if (lookup("masterDefinitionID", $key == $key, string($address)) == "Fukuoka") then output() as inputEventTypeID;
}

  • inputEventTypeID is the development asset ID of the target event type definition.

  • masterDefinitionID is the development asset ID of the master definition that corresponds to the master data to be referenced.

  • To compare "$address" as a string, use "string($address)" to fetch the values.

  • The left side of "$key == $key" is "key" of the input events and the right side is "key" of the master data.

Note

The master data information will not be assigned to the input events if they are only matched using "lookup". If join processing with master data is required, a join expression must be described. Refer to "5.4.4.1.3 Join processing with master data" below for information on join processing.

5.4.4.1.3 Join processing with master data

This processing pattern joins input events with master data. Consider using this processing pattern to assign the required data for the next complex event processing. It enables faster join processing than RDB referencing using complex event processing rules.

To pass the results of joining to complex event processing, an event type definition (filtered) corresponding to the join results will also be required.

Example

Example of join processing with master data

This is an example of joining the corresponding master data on the basis of "key" contained in the events, and then assigning "address" to the events.

Rule to be created

The rule to be created in the example above is as follows:

on inputEventTypeID {
    join("masterDefinitionID", $key == $key) output($key, "masterDefinitionID".$address) as outputEventTypeID;
}

  • inputEventTypeID is the development asset ID of the event type definition that is the rule target.

  • masterDefinitionID is the development asset ID of the master definition that corresponds to the master data to be referenced.

  • outputEventTypeID is the development asset ID of the event type definition (filtered) that represents the results of joining.

5.4.4.1.4 Weighting processing of text

This processing pattern can weight the text in input events by registering the weight of the keywords in the master data. This in turn allows applications including those that extract only those events with a total weighting that is above a threshold, and those that detect consecutively issued events that are above a threshold.

Example

Example of weighting processing of text

If the text contained in events contains search words that have been defined in the master data, assign the number of search words it contains as well as the total weighting value set for each search word, and then output them.

Rule to be created

The rule to be created in the example above is as follows:

on inputEventTypeID {
    join("masterDefinitionID", $message = $word)
        output($ID, 
               $subject,
               "masterDefinitionID".$word,
               "masterDefinitionID".$weight,
               lookup_count("masterDefinitionID".$word),
               lookup_sum("masterDefinitionID".$weight)) as outputEventTypeID;
}

  • inputEventTypeID is the development asset ID of the event type definition that is the rule target.

  • masterDefinitionID is the development asset ID of the master definition that corresponds to the master data to be referenced.

  • outputEventTypeID is the development asset ID of the event type definition (filtered) that represents the results of joining.

5.4.4.2 Complex Event Processing

Define the rules to be used by complex event processing.

Considerations when creating complex event processing rules

The items to consider when creating complex event processing rules are as follows:

Creation procedure for complex event processing rules

This section uses examples to explain the following creation procedure for complex event processing rules:

  1. Consider what is to be achieved by using complex event processing.

    Decide on what is to be achieved by using complex event processing. If this is unclear at this point, analyzing the collected events can sometimes clarify this.

    Example

    Example of a rule

    "When someone is home, if rain is likely, recommend using the drying feature of the washing machine."

  2. Consider the events, external data to be referenced, and output content.

    Consider the events, the external data for referencing, and the output content required to create the rule. Also consider using a named window for retaining events in memory.

    Example

    Examples of events, external data, output, and named window

    The rule example above uses the following events, external data, output content, and named window:

    • Events

      • TV control event
        For the household appliance event data sent from the home gateway of each household, the value of the device category property is to be "Television".

      • Weather forecast event
        The forecast is to be represented by the time and weather.

    • External data

      • Washing machine model information (whether it has a drying feature)
        Whether the washing machine in that household has a drying feature is to be apparent from the home gateway ID.

    • Output content

      • Home gateway ID of the household to be given the recommendation

      • Recommendation details

    • Named window

      • Named window for weather forecast events
        The weather forecast events for each time are to be retained for one day.

  3. Refine the processing content.

    Refine the content of the events and of the complex event processing for detecting them.

    Here, "refine" is the task of using events and specific information such as complex event processing conditions and external data to make what was previously expressed in everyday language as "what is to be achieved" into a representation closer to the rule to be created.

    Example

    Example of refining the content of complex event processing

    The table below shows the results of refining the "When someone is home, if rain is likely, recommend using the drying feature of the washing machine" rule.

    Element of the rule

    Refined processing content

    "When someone is home"

    Determine that someone is home in the household where the TV was controlled (detect a TV control notifying event).

    "If rain is likely"

    Reference the weather forecast information stored in the named window and, from the time of the weather forecast and the time of the TV control, check whether or not there is a forecast of rain after this time.

    "Drying feature of the washing machine"

    Obtain product information on the washing machine connected to the home gateway from the Terracotta cache.

    "Recommend"

    If there is a forecast of rain and if the washing machine has no drying feature, recommend hanging the clothes inside the house.

    If there is a forecast of rain and if the washing machine has a drying feature, recommend using it.

  4. Create an event flowchart.

    After refining the processing content is completed, summarize the event processing flow to create an event flowchart. An event flowchart associates events and their processing content in chart form. Create an event flowchart before describing the processes using complex event processing rule language, as it is useful for checking the processing content to be achieved.

    Information

    Legend of event flowchart

    This is the legend for the event flowcharts to be used in this manual.

    Example

    Example of an event flowchart

    This is an event flowchart for "When someone is home, if rain is likely, recommend using the drying feature of the washing machine".

    1. Create a named window for retaining weather forecast events.

    2. Create a Virtual Data Window (Terracotta cache) to see whether the washing machine has a drying feature.

    3. Store weather forecast events in the weather forecast window.

    4. Detect any TV control events from among the household appliance events.

    5. Check the weather forecast from after the time that the TV control events occurred and leave only those events with a forecast of rain.

    6. Search the washing machine feature window for the households for which a TV control was performed and for which there is a weather forecast of rain, and then add recommendation information according to whether the washing machine has a drying feature and send it to the user-developed Web service.

    7. Based on the information received by the user-developed Web service, send a recommendation to the household. Control the user-developed Web service so that the same recommendation is not made to the same household twice within a fixed time period.

  5. Create complex event processing rules.

    Describe complex event processing rules that correspond to the respective elements in the event flowchart.

    Example

    Example of complex event processing rules that correspond to the event flowchart

    Refer to Chapter 1, "Complex Event Processing Language Reference" in the Developer's Reference for information on the meanings of rules.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    // 1. Create a named window for retaining weather forecast events.
    @Name    ('WeatherWin')
    create window WeatherForecastWin.std:unique    (FORCASTIME).win:time(1 day)
          (FORCASTIME long, WEATHER string);
     
    // 2.     Create a Virtual Data Window to check whether the washing machine 
    //        has a drying feature.
    @VDW    (cacheName='ProductFuncCache', keyProperty='gatewayId')
    create window ProductFuncWin.vdw    :ehcache('ProductFuncCache', 'gatewayId')
          as (gatewayId string, dryFunc string);
     
    // 3.     Store weather forecast events in the named window.
    @Name    ('InputWeather')
    insert into WeatherForecastWin
      select weathfore.FORCASTIME as FORCASTIME, weathfore.WEATHER as WEATHER
        from WeatherForecastEvent as weathfore;
     
    // 4.     Detect TV control events.
    @Name    ('ChkTVEvent')
    insert into TVControl
      select heevnt.gatewayId as gatewayId, heevnt.updateTime as updateTime 
            from HEEvent as heevnt
        where heevnt.deviceCategory = 'Television';
     
    // 5.     Check the weather when TV control events occurred (detect forecast 
    //        of rain).
    //     Use the following expression to evaluate the time zone of weather 
    //     forecasts. Assume FORCASTIME is "long" (milliseconds):
    //       timeOfWeatherForecast
    //          <= updateTimeOfTVcontrolEvent
    //          <= timeOfWeatherForecast + 1 hour (3600000 milliseconds)
    @Name    ('GetRainyEvent')
    insert into TVControlRain
      select tvevnt.gatewayId as gatewayId
        from TVControl as tvevnt unidirectional, WeatherForecastWin as weather
        where updateTimeToMillis    (tvevnt.updateTime) between weather.FORCASTIME 
          and     (weather.FORCASTIME + 3600000) 
          and weather.WEATHER = 'rainy';
     
    // 6.     Check whether the washing machine has a drying feature and send the 
    //        recommendation.
    //     Check whether ProductFuncWin dryFunc property has drying feature ("1": Yes).
    //     Use the SOAP listener to send the output to the application.
    //       'USE_DRY_FUNC' = Recommendation ID if there is drying feature
    //       'HANG_LAUNDRY_INSIDE' = Recommendation ID if there is no drying feature
    //     Use the logging listener to log the output.
    //       table      : set log storage area.
    //   properties : set property names output (output results) 
    //                by delimiting with commas.
    @Name    ('PutRecommend')
    @SoapListener    ('soap-001')
    @LoggingListener    (table='/logsoap',properties='gatewayId,recommendId')
    select tvevnt.gatewayId as gatewayId,
      case when product.dryFunc = '1' 
               then 'USE_DRY_FUNC' 
               else 'HANG_LAUNDRY_INSIDE'end as recommendId
      from TVControlRain as tvevnt     unidirectional, ProductFuncWin as product
      where product.gatewayId = tvevnt.gatewayId;

5.4.4.3 Terracotta Collaboration

This section explains considerations when performing Terracotta collaboration, and explains how to use Terracotta collaboration, as follows:

5.4.4.3.1 Considerations when using Terracotta collaboration

This section explains the items to consider when using Terracotta collaboration for referencing external data in complex event processing, as follows:

5.4.4.3.2 Preparing a configuration information file for Terracotta cache

To use Virtual Data Window in order to use a Terracotta cache (known as Ehcache), you must place an Ehcache configuration file (ehcache.xml) on the CEP Server. Place the Ehcache configuration file in the following location:

/etc/opt/FJSVcep/config/ehcache.xml

Refer to the Terracotta manual for information on the Ehcache configuration file. The table below explains the settings required for Terracotta Collaboration.

Element or attribute

Description

ehcache

Root element of the configuration file.

name

Specify the name of the cache manager specified when creating the cache.

maxBytesLocalHeap

Size of the data pool to be used.

terracottaConfig

Element for defining a Terracotta server.

url

List of Terracotta servers in the format "hostNameOrIpAddress:portNumber", delimited with a comma (,).

cache

Element for defining cache.

Multiple <cache> elements can be specified in a single <ehcache> element.

name

Name of the cache. This is the cache name specified using vdw:ehcache.

terracotta

Defined for using a Terracotta server.

nonstop

Defined for use as nonstop cache.

immediateTimeout

Specify whether to respond with a timeout when a network disconnection is detected. Specify "true" as the value.

timeoutMillis

Specify the standby time until timeout.

timeoutBehavior

Specify operation to be performed if a timeout occurs.

type

Specify "exception" as the value.

searchable

Defined for searching the cache.

Example

The following example uses the cache "Cache001" configured on two Terracotta servers (192.168.1.1 and 192.168.1.2) using Terracotta collaboration.

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
  name="SearchConfig">
  maxBytesLocalHeap="64M">
    <terracottaConfig url="192.168.1.1:9510,192.168.1.2:9510"/>
    <cache name="Cache001">
        <terracotta>
            <nonstop immediateTimeout="true" timeoutMillis="3000">
                <timeoutBehavior type="exception"/>
            </nonstop>
        </terracotta>
        <searchable />
    </cache>
</ehcache>
5.4.4.3.3 Using Terracotta cache

This section explains how to create a Virtual Data Window and how to use the created Virtual Data Window.

Creating a Virtual Data Window

Create a Virtual Data Window (hereafter referred to as a "VDW") within complex event processing rules in order to use a Terracotta cache from the rules.

Specifically, describe this as follows:

Syntax: If an event type ID is used

create window windowName.vdw:ehcache("cacheName","keyPropertyName") as eventTypeID;

Syntax: If type information is specified directly

create window windowName.vdw:ehcache("cacheName","keyPropertyName") as (propertyName type, propertyName type, ...);

Example

Definition example for creating a Virtual Data Window (VDW)

This is an example of creating a VDW (MarketWindow) to reference a Terracotta cache (MARKET).

create window MarketWindow.vdw:ehcache("MARKET", "code") as (code string, high int, low int);

  • "code" is specified as a key property.

  • "code (string type)", "high (int type)", and "low (int type)" are defined as the properties.

Using a Virtual Data Window

Use a created Virtual Data Window in the same way as an ordinary window. However, to access cache data, use an INSERT INTO clause, join that specifies UNIDIRECTIONAL, ON SELECT statement, ON UPDATE statement, ON DELETE statement, ON MERGE statement, or subquery.

Example

Example of using a created Virtual Data Window (VDW)

This example inserts a MarketEvent event into a VDW.

insert into MarketWindow select code, high, low from MarketEvent;

This example references a VDW MarketWindow when a TicketEvent event occurs to obtain the data of the VDW events (cache entries) that meet the condition. This example uses TicketEvent as a trigger, so UNIDIRECTIONAL is specified in TicketEvent for joining the events.

select W.high, W.low from TicketEvent as Input unidirectional, MarketWindow as W
    where W.code = Input.code;

This example references a VDW (MarketWindow) when a TicketEvent event occurs to obtain the data of the VDW events (cache entries) that meet the condition. This example uses an ON SELECT statement.

on TicketEvent as Input
    select W.high, W.low from MarketWindow as W
        where W.code = Input.code;

This example references a VDW (MarketWindow) when a TicketEvent event occurs to obtain the data of the VDW events (cache entries) that meet the condition. This example uses a subquery.

select (select W.high from MarketWindow as W where W.code = Input.code) as high from TicketEvent as Input;

This example updates an event that has the same code in a VDW when a MarketEvent event occurs.

on MarketEvent as New
    update MarketWindow as W
        set high = New.high, set low = New.low
            where W.code = New.code;

Note

Notes on using a Virtual Data Window

  • Do not specify another view.

    Do not specify another view such as win:length(1) at the same time as the vdw:ehcache() specification in a CREATE WINDOW statement that defines a Virtual Data Window. Specifying another view does not cause a syntax error, but the view specification cannot be used to operate Terracotta cache data (even if you specify win:length(1), the number of events in the cache will not be "1").

  • An INSERT INTO clause is not merely an insertion.

    A Terracotta cache holds only one event (cache entry) for the value of a key property. Therefore, if a new event is inserted into a Virtual Data Window using an INSERT INTO clause and the cache already contains an event that has the same key property value, the event is updated using the new event.

  • Cache entries added outside the CEP engine do not propagate.

    For a simple SELECT statement that specifies Virtual Data Window in a FROM clause or a join that does not specify UNIDIRECTIONAL, an event inserted into the Virtual Data Window by the INSERT INTO clause using the complex event processing rules on the same CEP engine propagates. However, an event (cache entry) added from a Terracotta application or a different CEP engine does not propagate. To access cache data, use an ON SELECT statement, a subquery, or a join that specifies UNIDIRECTIONAL.

    The following example shows a simple SELECT statement:

    select W.high, W.low from MarketWindow;

    The following example shows a join that does not specify UNIDIRECTIONAL:

    select W.high, W.low from TicketEvent.std:lastevent() as Input, MarketWindow as W
            where W.code = Input.code;

    If the INSERT INTO clause inserts an event into MarketWindow, the inserted event propagates to the SELECT statements. However, events added outside the CEP engine does not propagate.

  • A WHERE clause must uniquely identify cache entries.

    The WHERE clause, which can be used for accessing information stored in a Virtual Data Window, must contain a condition for uniquely identifying cache entries. This condition uses "=" to perform a comparison with the key property specified using vdw:ehcache(). An example is shown below.

    In the following example, W.code = T.code is valid, because it uniquely identifies a cache entry.

    create window MarketWindow.vdw:ehcache("MARKET", "code") as (code string, high int, low int);
     
    on TicketEvent as T
        select W.high, W.low from MarketWindow as W
            where W.code = T.code and ( T.price > W.high or T.price < W.low);

The table below shows valid and invalid definition examples of using the above rule to change the WHERE clause only.

No.

Definition example

Valid/
Invalid

Explanation

1

where W.code = '1111'

Valid

Valid because the condition can uniquely identify a cache entry by using "=" to perform a comparison with the key property

2

where ( T.price > W.high or T.price < W.low) and W.code = T.code

Valid

Preceded by a different condition but valid because it includes "=" for performing a comparison with the key property and can uniquely identify a cache entry

3

where W.high = 1000

Invalid

Invalid because a comparison using "=" is not performed for the key property.

4

where W.code > '1111'

Invalid

Invalid because an operation other than "=" is performed for the key property.

5

where W.code = '1111' or W.high = 1000

Invalid

Includes "=" for performing a comparison with the key property but is invalid because there is an OR condition and a cache entry cannot be uniquely identified

5.4.4.4 RDB Collaboration

This section explains the items to consider when implementing RDB collaboration and how to use it.

To reference a relational database as external data, create an RDB reference definition that contains information about connection to the relational database.

This section explains the following items:

5.4.4.4.1 Considerations when using RDB collaboration

The items to consider when using RDB collaboration are as follows:

5.4.4.4.2 Specifying RDB referencing in complex event processing rules

You can use the results of a query to a relational database by specifying them using the following syntax in a FROM clause of complex event processing rules.

Syntax:

sql:databaseName [" sqlQuery "] or
sql:databaseName [' SqlQuery ']

In databaseName, specify the "development asset ID" specified in the RDB reference definition.

Enclose sqlQuery in double quotation marks (") or single quotation marks ('), and enclose this specification in square brackets "[" and "]".

Alternate parameters can be included in sqlQuery. Specify alternate parameters in the ${expression} format. The expression is evaluated when the statement is executed.

Note

  • Minimize RDB referencing, because it may cause a decline in the performance of Complex Event Processing.

  • Multibyte characters cannot be used for definition names in a relational database, such as table names and table item names to be referenced from the complex event processing language. Multibyte characters can be used for item values.

  • To specify a nonnumeric literal enclosed in single quotation marks (') in an SQL query that is further enclosed in single quotation marks ('), use the escape notation (\') or the Unicode notation (\u0027).

Example

Example of using RDB referencing

This example uses RDB referencing in a complex event processing rule (SELECT statement).

@Name("PutRecommend")
@SoapListener("soap-001")
select tvevnt.gatewayId as gatewayId,
  case when db.DRY_FUNC = '1' then 'USE_DRY_FUNC' else 'HANG_LAUNDRY_INSIDE' end as recommendId
  from TVControlRain as tvevnt, 
      sql:app_db[ 'SELECT DRY_FUNC FROM PRODUCTFUNC_TBL WHERE HGW_ID=${tvevnt.gatewayId}' ] as db;

  • The development asset ID of the RDB reference definition to be used is set to "app_db".

  • The relational database table being referenced is "PRODUCTFUNC_TBL".

  • The alternate parameter "${tvevnt.gatewayId}" is specified in the condition for referencing the relational database table.

  • The alias "db" is assigned to the reference results and is used in a SELECT statement.


5.4.4.5 SOAP Listener

Use the SOAP listener to send the processing results of complex event processing statements to a user-developed Web service using SOAP.

To use the SOAP listener, assign the @SoapListener annotation in front of the complex event processing statement (SELECT statement) for which the processing results are to be sent.

Refer to "5.4.8 Designing a SOAP Listener Definition" for information on the send destination of processing results and the contents of SOAP messages.

Syntax

@SoapListener("soapListenerDefinitionId")
complexEventProcessingStatement(selectStatement)
soapListenerDefinitionId

Specify the development asset ID in the SOAP listener definition that defines information such as the URL that is the send destination of the Web service to which the processing results are to be sent.

complexEventProcessingStatement (selectStatement)

Specify the complex event processing statement (SELECT statement) for which the processing results are to be sent.

5.4.4.6 Custom Listener

Use the custom listener to pass the results of complex event processing statements to a Java program (hereafter referred to as a user-developed Java class) for processing.

To use the custom listener, assign the @CustomListener annotation in front of the complex event processing statement (SELECT statement) to which you want to pass the processing result.

Refer to "5.6.3 Designing a User-developed Java Class" for information on user-developed Java classes.

Syntax

@CustomListener(mainClass="nameOfUserDevelopedJavaClass" [, args={"argument1", "argument2", ...}])
complexEventProcessingStatement(selectStatement)

Alternatively, the format may use single quotation marks (') instead of double quotation marks (").

nameOfUserDevelopedJavaClass

Specify the name of the Java class that receives the results of complex event processing statements. Use FQCN format (format that includes the package name) for specifying this name. The CustomListener interface must have been implemented for this Java class.

argument1, argument2, ...

Specify these arguments for the user-developed Java class. If there is no need to pass arguments, omit the "args" parameter.

5.4.4.7 Logging Listener

Use the logging listener to log the processing results of complex event processing statements in the event log using Logging.

To use the logging listener, assign the @LoggingListener annotation in front of the complex event processing statement (SELECT statement) for which the processing results are to be logged.

Syntax

@LoggingListener(table="logStorageArea", properties="propertyNameToBeOutput")
complexEventProcessingStatement(selectStatement)
logStorageArea

Use an absolute path to specify the path in the Hadoop system in which the event log is logged.

Even if events are to be logged in the engine log of the CEP Server (if "file" is specified in the "type" element of the engine configuration file), specify a virtual path name that begins with a slash (/) (for example, /eventName) to identify the events.

Note

The "table" specification is mandatory. Even if a null value is specified, such as 'table=""', the CEP engine will start normally but logging will not be performed.

propertyNameToBeOutput

Out of the processing results of the SELECT statement, specify the property name to be logged. Multiple properties can also be specified if delimited using commas (,).

For a property with nested processing results, use periods (.) between the nested properties to join them.

Example

If a "child" property is nested in a "parent" property

If a "child" property is nested in a "parent" property, as shown below, specify the "child" property by describing "parent.child".

<root>
    <parent>
        <child>aaa</child>
    </parent>
</root>

Note

The "properties" specification is mandatory. Even if a null value is specified, such as 'properties=""', the CEP engine will start normally but logging will not be performed.

complexEventProcessingStatement (selectStatement)

Specify the complex event processing statement (SELECT statement) for which the processing results are to be logged using logging.

Note

  • The logging to be defined in an event type definition and the logging to be defined in a rule definition (logging listener) can have separate log storage areas as output destinations. However, note that logging to a different Hadoop system is not possible.

  • If the value of the output property is "null", this is converted to a blank space before being output to the event log.

  • If the output property is a numeric item, this undergoes string conversion before being output to the event log.

  • If an output property name that does not exist is specified, a blank space is output to the event log.

  • If there are double quotation marks (") in data, these will be output in duplicate within double quotation marks in the data.

    Output example of 'aa"bb"aa':

    "aa""bb""aa"
PreviousNext
Copyright 2012-2014 FUJITSU LIMITED