Event Handler

This article provides XML configuration reference for event handlers in ONE MDM. Use it for informational purposes: configuration changes made in the file are overwritten after generating your MDM project again.

For conceptual information and step-by-step configuration instructions, see:

Adding a Data Event Handler and Publisher - Overview of event handler types and use cases.
Streaming Event Handler - Streaming Event Handler configuration (recommended).
Async Event Handler - Async Event Handler overview (legacy).
Processors - Async Event Handler processor configuration.
Publishers - Async Event Handler publisher configuration.

Event handlers configuration file

Once you define event handlers, a list of all configured event handlers and their settings is generated to nme-event_handler.gen.xml. This file is referenced in the MDM model configuration.

Event handlers can be named. If the name is skipped, the name of the event handler implementation class is used instead.

If you are using multiple event handlers, names are no longer optional and each handler must have a unique name.

<?xml version="1.0" encoding="utf-8"?>
<handlers>
  <handler class="first.desired.handler.Class" name="firstHandler">
    ... handler configuration ...
  </handler>
  <handler class="second.desired.handler.Class" name="secondHandler">
    ... handler configuration ...
  </handler>
  ...
</handlers>

EventHandlerStreaming

The Streaming Event Handler combines processing, batching, grouping, and traversing into a single component with database persistence. For details, refer to Streaming Event Handler.

<handler name="streamingHandler"
         class="com.ataccama.nme.engine.event.handlerStreaming.EventHandlerStreaming">

  <persistence>
    <dataSource>eh_db</dataSource>
    <prefix>streamingHandler</prefix>
  </persistence>

  <filter>
    <!-- Optional session and event filtering -->
  </filter>

  <streaming seconds="5" size="100"/>

  <processor>
    <publishers>
      <!-- Publisher configuration -->
    </publishers>
  </processor>
</handler>

persistence - Database persistence configuration.
- dataSource - The database connection source where events will be stored.
- prefix - The prefix for database table names. Matches the handler name, which must be unique across all event handlers.
filter - A filter to pre-select events that will be persisted and published.
streaming - Controls batch collection timing.
- seconds - Maximum time (in seconds) to wait before triggering a batch. Default: 5.
- size - Maximum number of sessions to collect before triggering a batch. Default: 100.
processor - Contains the publisher configuration. The publisher configuration also determines processing behavior (these configurations are separate in the legacy async event handler).

StreamingRetryingPublisher

The Streaming Event Handler uses a specialized retrying publisher wrapper.

<publisher class="com.ataccama.nme.engine.event.handlerStreaming.StreamingRetryingPublisher">
  <maxRetryTimeout>60</maxRetryTimeout>
  <delegate class="com.ataccama.nme.dqc.event.EventPlanPublisherStreaming">
    <publishBatchSize>1000</publishBatchSize>
    <planFileName>../engine/events/publish_party.comp</planFileName>
    <entities>
      <entity layer="master" masterView="masters" name="party"/>
      <entity layer="master" masterView="masters" name="address"/>
    </entities>
    <root>
      <master name="party" view="masters">
        <childEntities>
          <entity name="address" relationshipName="party" view="masters"/>
        </childEntities>
      </master>
    </root>
  </delegate>
</publisher>

maxRetryTimeout - Maximum time (in seconds) to retry failed publishing attempts before marking the batch as failed.
delegate - The actual plan publisher configuration.
- publishBatchSize - Maximum number of root entities included in a single batch sent to the ONE plan. Large batches are automatically split into chunks of this size.
- entities - List of entities to publish.
- root - Traversing model configuration defining entity relationships.

Filters

Applies to both the Streaming and Async Event Handlers.

Filter allows pre-filtering the events so only certain events are actually accepted. See Processors > Filtering.

<filter>
  <filterExpression>meta.event_type = "UPDATE"</filterExpression>
  <entities>
    <entity name="party" layer="instance">
      <filterExpression>new.src_name != old.src_name</filterExpression>
    </entity>
    <entity name="party" layer="master" masterView="MasterView" />
  </entities>
</filter>

Operation type filtering (Streaming Event Handler only)

The Streaming Event Handler supports additional filtering based on the operation type that triggered the event.

<filter>
  <filterExpression>
    (meta.event_type = 'INSERT' OR meta.event_type = 'UPDATE')
  </filterExpression>

  <entities>
    <entity name="party" layer="master" masterView="masters">
      <filterExpression>new.status != old.status</filterExpression>
    </entity>
  </entities>

  <operationTypes>
    <operationType>SERVICE</operationType>
    <operationType>WEB_APPLICATION</operationType>
    <operationType>STREAM</operationType>
  </operationTypes>
</filter>

operationTypes - Filters events based on their origin.
- operationType - Possible values (one of): SERVICE, BATCH, WEB_APPLICATION, STREAM, BATCH_SERVICE.

Complete configuration example

The example shows a possible streaming event handler configuration for the following business scenario.

A financial services company needs to synchronize customer and account data changes to a data warehouse for analytics. The requirements are:

Track all customer (party) profile changes and new accounts.
Include related addresses only for US, Canada, and Mexico.
Ignore routine batch loads (analytics team only needs real-time changes).
Group related data (customer + addresses) into complete messages.

Streaming Event Handler configuration example

<handler name="Customer_Account_Analytics"
         class="com.ataccama.nme.engine.event.handlerStreaming.EventHandlerStreaming">

  <!-- Database Persistence -->
  <persistence>
    <dataSource>eh_db</dataSource>
    <prefix>Customer_Account_Analytics</prefix>
  </persistence>

  <!-- Filtering -->
  <filter>
    <!-- Capture INSERT and UPDATE events only (no purges) -->
    <filterExpression>
      (meta.event_type = 'INSERT' OR meta.event_type = 'UPDATE')
    </filterExpression>

    <!-- Entity-specific filters -->
    <entities>
      <!-- Monitor all changes to customer profiles -->
      <entity name="party" layer="master" masterView="masters"/>

      <!-- Monitor address changes in North America only -->
      <entity name="address" layer="master" masterView="masters">
        <filterExpression>
          new.country is in {'US', 'CA', 'MX'}
        </filterExpression>
      </entity>

      <!-- Monitor instance party records -->
      <entity name="party" layer="instance"/>
    </entities>

    <!-- Operation type filter: real-time changes only (no batch loads) -->
    <operationTypes>
      <operationType>SERVICE</operationType>
      <operationType>WEB_APPLICATION</operationType>
      <operationType>STREAM</operationType>
    </operationTypes>
  </filter>

  <!-- Processing and Publishing -->
  <processor>
    <publishers>
      <publisher class="com.ataccama.nme.engine.event.handlerStreaming.StreamingRetryingPublisher">
        <!-- Retry for up to 60 seconds with exponential backoff -->
        <maxRetryTimeout>60</maxRetryTimeout>

        <delegate class="com.ataccama.nme.dqc.event.EventPlanPublisherStreaming">
          <!-- Send batches of up to 1000 root entities -->
          <publishBatchSize>1000</publishBatchSize>

          <!-- ONE plan to execute -->
          <planFileName>../engine/events/customer_analytics_sync.comp</planFileName>

          <!-- Publisher Data Model: Customer + Addresses -->
          <root>
            <master name="party" view="masters">
              <!-- Specify columns to reduce payload size -->
              <columns>
                <column name="cmo_name"/>
                <column name="eng_active"/>
                <column name="eng_modified_by"/>
              </columns>

              <!-- Include related addresses -->
              <childEntities>
                <entity name="address" relationshipName="party_has_address" view="masters">
                  <columns>
                    <column name="street"/>
                    <column name="city"/>
                    <column name="country"/>
                    <column name="zip_code"/>
                  </columns>
                </entity>
              </childEntities>

              <!-- Include instance party record -->
              <instance name="party">
                <columns>
                  <column name="source_id"/>
                  <column name="src_name"/>
                  <column name="master_id"/>
                </columns>
              </instance>
            </master>
          </root>
        </delegate>
      </publisher>
    </publishers>
  </processor>
</handler>

EventHandlerAsync

The Async Event Handler stores all necessary data during processing to a specified storage (file or database). Once the operation is completed, it initiates publishing of the data.

For details, refer to How Async Event Handler Works.

<handler class="com.ataccama.nme.engine.event.handler.EventHandlerAsync">
  <persistence class="com.ataccama.nme.engine.event.persistence.db.NmeEventPersistenceDbConfig">
		<dataSource>eh_db</dataSource>
		<prefix>EH_DEFAULT_</prefix>
	</persistence>
  <filter>
    ...
  </filter>
  <publishers>
    <publisher class="first.desired.publisher.Class">
      ... publisher configuration ...
    </publisher>
    <publisher class="second.desired.publisher.Class">
      ... publisher configuration ...
    </publisher>
    ...
  </publishers>
</handler>

persistence:
- class - Specifies the class implementing the persistence mechanism. Possible values:
  1. com.ataccama.nme.engine.event.persistence.file.NmeEventPersistenceFileConfig - Event data is stored in the form of files in the file system.
    
    Sample configuration
    
    <persistence class="com.ataccama.nme.engine.event.persistence.file.NmeEventPersistenceFileConfig"> <dir>../storage/eventHandler</dir> </persistence>
    
    dir - The path to a directory where all the persisted data is temporarily stored (before it is published).
    
    Do not store anything else in this directory. Use one directory per event handler.
  2. com.ataccama.nme.engine.event.persistence.db.NmeEventPersistenceDbConfig - Event data is stored in database tables.
    
    Sample configuration
    
    <persistence class="com.ataccama.nme.engine.event.persistence.db.NmeEventPersistenceDbConfig"> <dataSource>eh_db</dataSource> <prefix>EH_DEFAULT_</prefix> </persistence>
    
    dataSource - The database connection source where events will be stored.
    
    prefix - The prefix of the database table names used by this persistence configuration.
filter - A filter can pre-select events that will be persisted (and consequently published).
publishers - A list of all publishers which distribute data into various systems, depending on their nature and configuration.

Processors

A processor is a component for consuming events in the Async Event Handler. A single asynchronous event handler configuration requires a single processor.

The following processors are available. To determine which processor is the right for your use case, see Types of processors.

SimpleEventProcessor

Passes events on the input straight to the configured publishers (grouping events per operation).

<handlers>
    <handler name="default" class="com.ataccama.nme.engine.event.handler.EventHandlerAsync">
    <processor class="com.ataccama.nme.engine.event.handler.SimpleEventProcessor"/>
        ...
    </handler>
    ...
</handlers>

BatchingEventProcessor

Groups events by entity type and then passes them to publishers in small groups. See Batching event processor.

<handlers>
    <handler name="default" class="com.ataccama.nme.engine.event.handler.EventHandlerAsync">
        <processor class="com.ataccama.nme.engine.event.handler.BatchingEventProcessor"/>
        ...
    </handler>
    ...
</handlers>

GroupingEventProcessor

Groups related events in a logical model-like configuration of entities (entities are contained in the <roots> element). See Grouping event processor.

<handlers>
    <handler name="grouping" class="com.ataccama.nme.engine.event.handler.EventHandlerAsync">
        <processor class="com.ataccama.nme.engine.event.handler.GroupingEventProcessor">
            <roots>
                <root>
                    <master name="party" view="masters">
                        <childEntities>
                            <entity name="address" relationshipName="party"/>
                            <entity name="contact" relationshipName="party_has_contact"/>
                            <entity name="rel_party_party" relationshipName="parent child"/>
                            <entity name="id_document" relationshipName="party"/>
                            <entity name="consent" relationshipName="party"/>
                        </childEntities>
                    </master>
                </root>
            </roots>
        </processor>
        ...
    </handler>
    ...
</handlers>

Processor behavior comparison

The following table shows the differences in the behavior of event processors.

There are two master entities with 1:N relation (parent - party, and child - contact). Assume there are also two event handler publishers: one plan publisher for party and contact, and one party SQL publisher. The publish batch size (nme.eventHandler.publish.batchSize) is set to 1.

Table 1. Changed entity data events
Party (PK: id)	Contact (FK: party_id)
id=1, event_type="U"	/
id=2, event_type="I"	party_id=2, event_type="I"
id=3, event_type="U"	/
/	party_id=4, event_type="U"
/	party_id=5, event_type="U"

Event processor type Description No of executed batches per publisher Recommended use

Event processor type	Description	No of executed batches per publisher	Recommended use
Simple	There are three distinct party events and three distinct contact events. The processor calls the plan publisher once and passes all six data events (three for party, three for contacts) in one publishing action. All events will be available, therefore aggregating or joining related records is possible.	1	Aggregations File outputs
Batching	There are three distinct party events and three distinct contact events. The processor calls the plan publisher MN times, where M is the number of entities, and N is evaluated as follows: `roundUp(distinct records/nme.eventHandler.publish.batchSize, 0)`. Party* events and contact events are delivered to the plan publisher sequentially, so aggregations or joins are not possible.	6	Faster events delivery (data chunks) Append storage (database)
Grouping	There are three distinct party events and three distinct contact events. The processor has the master party configured as the root model entity and contact as the related (silver) entity. The processor uses the model relationships to send the party record (`id=2`) together with the contact (`party_id=2`) while all other records (party and contact) are sent to the plan publisher independently (for `nme.eventHandler.publish.batchSize=1`) or in a small group. Therefore, the plan publisher always has the corresponding events sent together. However, missing (non-triggered records) are not retrieved from the MDM Storage. See TraversingPlanPublisher.	5	Grouping of related events

Simple

There are three distinct party events and three distinct contact events.

The processor calls the plan publisher once and passes all six data events (three for party, three for contacts) in one publishing action. All events will be available, therefore aggregating or joining related records is possible.

Aggregations

File outputs

Batching

There are three distinct party events and three distinct contact events.

The processor calls the plan publisher M*N times, where M is the number of entities, and N is evaluated as follows: roundUp(distinct records/nme.eventHandler.publish.batchSize, 0). Party events and contact events are delivered to the plan publisher sequentially, so aggregations or joins are not possible.

Faster events delivery (data chunks)
Append storage (database)

Grouping

There are three distinct party events and three distinct contact events. The processor has the master party configured as the root model entity and contact as the related (silver) entity.

The processor uses the model relationships to send the party record (id=2) together with the contact (party_id=2) while all other records (party and contact) are sent to the plan publisher independently (for nme.eventHandler.publish.batchSize=1) or in a small group. Therefore, the plan publisher always has the corresponding events sent together. However, missing (non-triggered records) are not retrieved from the MDM Storage. See TraversingPlanPublisher.

Grouping of related events

Delegating publishers

A delegating publisher can be used wherever a publisher is expected.

Such publishers are used to add a functionality other than publishing. In this case, a different publisher is used for actual event publishing.

This delegate can also be a delegating publisher, cascading the event handling chain one level further.

FilteringPublisher

Adds the possibility to filter the flow of incoming events to the underlying publisher.

<publisher class="com.ataccama.nme.engine.event.handler.publishers.FilteringPublisher">
  <filter>
    ...
  </filter>
  <delegate class="delegate.publisher.Class">
    ...
  </delegate>
</publisher>

filter - A filter.
delegate - Another publisher that will be used for the actual publishing of the events that pass through the specified filter (this publisher can also be another delegating publisher).

RetryingPublisher

Adds the possibility to retry a failed attempt to publish an event. Each time publishing an event fails, one global retry is used to retry publishing the event after the specified retry delay.

If there are no global retries left, the publishing fails like it would without the retrying publisher.

In addition, after the specified number of consecutive publishing attempts that were all successful, one additional global retry is generated. This way, the reserve of global retries can grow to be used later (up to the specified maximum number of retries).

<publisher class="com.ataccama.nme.engine.event.handler.publishers.RetryingPublisher">
  <globalRetries>5</globalRetries>
  <retryDelay>20</retryDelay>
  <numberOfConsecutiveSuccessesGrantingRetry>10</numberOfConsecutiveSuccessesGrantingRetry>
  <maximumRetries>30</maximumRetries>
  <delegate class="delegate.publisher.Class">
    ...
  </delegate>
</publisher>

globalRetries - The initial amount of retries.
retryDelay - The delay after a failed attempt to publish an event before retry (in seconds).
numberOfConsecutiveSuccessesGrantingRetry - The number of consecutive successes that generate another retry; 0 means no retries will be generated.
maximumRetries - The limit of retries in reserve.

Publishers

A publisher is a component for publishing events in the Async Event Handler. A single event handler configuration requires a single publisher but can have multiple.

StdOutPublisher

Outputs events to standard output. See Standard output publisher.

<publisher class="com.ataccama.nme.engine.event.handler.publishers.StdOutPublisher">
  <transformer>
    ...
  </transformer>
</publisher>

EventHttpSoapPublisher

Constructs a SOAP message and sends it through an HTTP protocol to a specified destination. See HTTP SOAP publisher.

<publisher class="com.ataccama.nme.engine.event.handler.publishers.EventHttpSoapPublisher">
  <urlResourceName>dataChangesTargetSystem</urlResourceName>
  <soapAction>SOAP_ACTION</soapAction>
  <soapVersion>SOAP_1_1</soapVersion>
  <timeout>5000</timeout>
  <encoding>UTF-8</encoding>
  <delayBetweenRequestsMs>0</delayBetweenRequestsMs>
  <transformer>
    ...
  </transformer>
</publisher>

urlResourceName - Name of the URL resource configured in the MDM runtime configuration.
soapVersion - Optional, defaults to SOAP 1.1. Possible values: SOAP_1_1, SOAP_1_2.
timeout, encoding and delayBetweenRequestsMs - Optional. Default values are listed in the example configuration.
transformer - The specification of the transformer element used to transform the event into text (in this instance, the SOAP message).

iSMPublisher

Compiles a XML message from every event it receives. See iSM publisher.

<publisher class="com.ataccama.nme.engine.event.handler.publishers.IsmPublisher">
  <host>localhost</host>
  <port>8888</port>
  <targetSystem>SYSTEM</targetSystem>
</publisher>

host - Target host.
port - Target port.
targetSystem - The "targetSystem" property in the message. This property is a template of general nested ONE expressions.

Message example

<?xml version='1.0' encoding='UTF-8'?>
<mdc.Event targetSystem="SYSTEM">
    <party changeType="UPDATE">
        <attributes>
            <source_id>100</source_id>
            <master_id>2</master_id>
            <src_name>John Smith</src_name>
            ... more data columns ...
            <eng_active>true</eng_active>
        </attributes>
    </party>
</mdc.Event>

EventSqlPublisher

Executes an SQL statement on a database. See Event SQL publisher.

<publisher class="com.ataccama.nme.engine.event.handler.publishers.EventSqlPublisher">
  <dataSource>DATA_SOURCE</dataSource>
  <templates>
    <template>
      <entity name="party" layer="master" masterView="MasterView" />
      <template>insert into TABLE values (${new.src_name}, ${old.src_name})</template>
    </template>
    ...
  </templates>
</publisher>

dataSource - Specifies the MDM data source: a named database connection defined in the MDM runtime configuration.
templates - Unlike other publishers, SQL publisher doesn’t feature a transformer for creating target text messages.

Instead, a set of SQL-specific templates is used to create SQL statements directly, which considerably improves the publishing performance.

SQL templates have some additional constraints over the common templates: they only allow to bind ONE expressions to SQL variables. They do not allow changing the SQL statement itself.

Every template is mapped to one entity (one template per entity). If a template for an entity is not defined, events for such entity are not published.
Allowed templates
```
insert into TEST (column1, column2) values (${old.src_name}, ${new.src_name})

delete from TEST where column1=${
  case (
  meta.eventType is 'INSERT', 1,
  meta.eventType is 'UPDATE', 2,
                3) }

{ call PACKAGE_NAME.PL_SQL_FUNCTION_NAME(${parameter1}, ${parameter2}) }
```
Not allowed
```
${'INSERT'} into TEST values (1)

insert into ${old.table_name} values (1)

{ call ${'PACKAGE_NAME'}.${PL_SQL_FUNCTION_NAME()} }
```

EventPlanPublisher

Sends events as records to a configured plan. See Event plan publisher.

<publisher class="com.ataccama.nme.dqc.event.EventPlanPublisher">
    <planFileName>../engine/events/eh-test.comp</planFileName>
    <entities>
        <entity layer="master" masterView="master" name="party"/>
        <entity layer="instance" name="party"/>
        <entity layer="instance" name="address"/>
        <entity layer="instance" name="contact"/>
        <entity layer="instance" name="contact_info"/>
    </entities>
</publisher>

Integration input step can have the following columns:

meta_<metaColumnName> - See the list of columns in [Evaluation of ONE Expressions].
new_<columnName> - Columns of the configured entity, including eng_active.
old_<columnName> - Columns of the configured entity, including eng_active.

TraversingPlanPublisher

Extends the event plan publisher. The traversing plan publisher (TraversingEventAdapter in the XML configuration) ensures that all related records defined by the model are present in the plan. See Traversing plan publisher.

Master entity-based roots can have both other masters as related entities (<childEntities>) and instance entities (<instance.name="">).

With the configured adapter, the publisher configuration looks as follows:

<publisher class="com.ataccama.nme.dqc.event.EventPlanPublisher">
    <planFileName>../engine/events/tp_party_master.comp</planFileName>
    <entities>
        <entity layer="master" masterView="masters" name="party"/>
        <entity layer="master" masterView="masters" name="address"/>
        <entity layer="master" masterView="masters" name="contact"/>
        <entity layer="master" masterView="masters" name="id_document"/>
        <entity layer="master" masterView="masters" name="consent"/>
        <entity layer="instance" name="party"/>
    </entities>
    <adapter class="com.ataccama.nme.engine.event.handler.publishers.TraversingEventAdapter">
        <root>
            <master name="party" view="masters">
                <childEntities>
                    <entity name="address" relationshipName="party" view="masters"/>
                    <entity name="contact" relationshipName="party_has_contact" view="masters"/>
                    <entity name="id_document" relationshipName="party" view="masters"/>
                    <entity name="consent" relationshipName="party" view="masters"/>
                </childEntities>
                <instance name="party"/>
            </master>
        </root>
    </adapter>
</publisher>

The Integration Input step can have the following columns:

meta_<metaColumnName> - See the list of columns in [Evaluation of ONE Expressions].
record_<columnName> - Columns of the configured entity with current (actual) record values.
old_<columnName> - Columns of the configured entity with old (previous) record values taken from the event.
meta_id (long) - MDM identifier of the record.
has_event (boolean) - The flag is set to true for records triggering the event, false for records preloaded into the data flow using model traversing.

Transformers

A transformer is an element that transforms an event into a string, that is, a message that will be distributed by a publisher.

Simple XML transformer

Transforms events to simple predefined XML. It doesn’t require nor provide any template configuration.

<transformer class="com.ataccama.nme.engine.event.handler.publishers.transformers.SimpleXmlTransformer">
  <indent>true</indent>
  <includeOldValues>true</includeOldValues>
</transformer>

indent - Optional, if true (default) XML is pretty-printed (indented using \t).
includeOldValues - Optional, if true (default) XML contains old values of attributes.

SimpleXmlTransformer produces the following XML:

<event>
  <metadata>
    <id>1001</id>
    <event_type>UPDATE</event_type>
    <entity>party</entity>
    ...
  </metadata>
  <attributes>
    <source_id>306</source_id>
    <src_name>John Smith</src_name>
    ...
  </attributes>
  <oldAttributes>
    <source_id>306</source_id>
    <src_name>John Smith Jr.</src_name>
    ...
  </oldAttributes>
</event>

Expression template transformer

A transformer based on a template.

<transformer class="com.ataccama.nme.engine.event.handler.publishers.transformers.ExpressionTemplateTransformer">
  <entity name="party" layer="master" masterView="MasterView" />
  <template>Some text with ${'ONE expressions'} inside it.</template>
</transformer>

entity - Optional; declares the entity that flows into this transformer (and if there’s an incoming event from a different entity, an exception is thrown). If omitted, all entities are accepted, but no data columns are available.
template - The intended text with the nested ONE expressions.
begin - Optional; can change the default begin mark of nested ONE expressions.
end - Optional; can change the default end mark of nested ONE expressions.

Multi transformer

Multi transformer can join several transformers, each handling one entity, to a single transformer that can handle all of them. This is the preferred way of dealing with transforming several entities where data columns contents are necessary.

<transformer class="com.ataccama.nme.engine.event.handler.publishers.transformers.MultiTransformer">
  <transformers>
    <transformer class="first.transformer.Class">
      ...
    </transformer>
    <transformer class="second.transformer.Class">
      ...
    </transformer>
    ...
  </transformers>
 </transformer>

Templates

A template is an attribute type. It is a string type that allows using nested ONE expressions, enabling you to employ the data quality engine tools in your configuration. Expressions are denoted by the ${ … } notation by default.

<template>
  <entity name="party" layer="master" masterView="MasterView" />
  <template>This is a common string and ${'this will be evaluated as ONE expression'}</template>
</template>

entity -Specifies the entity this template applies to. This allows you to use all the entity specific data columns in the template’s expressions.
template - The text template itself, with nested ONE expressions (see [Evaluation of ONE Expressions]).

Since expressions are part of a string, they have to be of STRING type. This includes converting any columns of non-string type to string if necessary (by toString() ONE function).

Storage requirements

EventHandlerAsync stores events in persistent storage to deliver at-least-once semantics. Such approach requires disk space (this should be taken into account for disk sizing) that can be computed as follows: required_disk_space = event_size x event_count.

Evaluation of ONE expressions

There are two types of ONE expressions in event handling (streaming or asynchronous): general and entity-specific.

General: Allow access to event metadata. These are available through dot-source meta.

The following columns are available.

name type content

name	type	content
`id`	LONG	Internal record ID.
`event_type`	STRING	Type of event (`INSERT`, `UPDATE`, `DELETE`).
`entity`	STRING	Name of the entity the event originated from.
`layer`	STRING	The layer of the entity the event originated from (instance or master)
`master_view`	STRING	For master entities, name of the entity master view the event originated from. Null otherwise.
`origin`	STRING	For instance entities, the origin of the data. Null otherwise.
`source_system`	STRING	For instance entities, the source system of the data. Null otherwise.
`activation_date` `creation_date` `deactivation_date` `deletion_date` `last_update_date` `last_source_update_date`	DAY	The date the record was activated, created, deactivated, deleted, last updated, and last updated from source, respectively.
`activation_tid` `creation_tid` `deactivation_tid` `deletion_tid` `last_update_tid` `last_source_update_tid`	LONG	ID of the logical transaction that activated, created, deactivated, deleted, last updated, and last updated from source the record, respectively.

id

LONG

Internal record ID.

event_type

STRING

Type of event (INSERT, UPDATE, DELETE).

entity

STRING

Name of the entity the event originated from.

layer

STRING

The layer of the entity the event originated from (instance or master)

master_view

STRING

For master entities, name of the entity master view the event originated from. Null otherwise.

origin

STRING

For instance entities, the origin of the data. Null otherwise.

source_system

STRING

For instance entities, the source system of the data. Null otherwise.

activation_date
creation_date
deactivation_date
deletion_date
last_update_date
last_source_update_date

DAY

The date the record was activated, created, deactivated, deleted, last updated, and last updated from source, respectively.

activation_tid
creation_tid
deactivation_tid
deletion_tid
last_update_tid
last_source_update_tid

LONG

ID of the logical transaction that activated, created, deactivated, deleted, last updated, and last updated from source the record, respectively.

Entity-specific - Allow access to all metadata, like general ONE expression. In addition, because they are entity specific, such expressions allow access to all data columns of the record on which the change occured, both new and old values. These are available through dot-sources new and old.

The internal column eng_active is also available through these dot-sources.

Was this page useful?