If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Notification Handler Component

The Notification Handler component lets users schedule running a script or a workflow based on certain changes in Metadata Management Module (MMM). As such, the component is similar to the Scheduler Server Component, with the key difference being how schedules are initiated.

To add the component to the online server, the server configuration must contain the following definition:

This component requires Web Console Component and Workflow Component to be also present on the server. In the server configuration file, the Notification Handler component must be placed following the Workflow component.

<serverComponents>
    ...
    <component class="com.ataccama.adt.notification.NotificationHandlerServerComponent">
        <sources>
            <source>
                <path>../notifications/handlers</path>
                <id>S1</id>
            </source>
        </sources>
        <resourcesFolder>../notifications/resources</resourcesFolder>
        <resultPersister class="com.ataccama.adt.scheduler.persister.FileStateResultPersister"/>
        <!-- The following element is used if job execution states are stored in a DB persister.
        <resultPersister class="com.ataccama.adt.scheduler.persister.DbStateResultPersister">
            <dialectFile>../../db/modules/oracle</dialectFile>
            <dataSource>oracle</dataSource>
            <prefix>SCH_</prefix>
        </resultPersister>
        -->
    </component>
    ...
</serverComponents>

A corresponding configuration in the Server Configuration Editor in ONE Desktop:

Notification Handler component configuration

Property Value Required Description

Property	Value	Required	Description
Sources	N/A	No	Defines a set of sources used for reading the notification handlers. Each `source` has the following attributes: Id - Defines a name for the source. Jobs in the source with ID are accessible via the `<sourceId>:<handlerName>.noth` notation. One of the sources might not have a name: in such cases, it is processed as an implicit source, so no Id is required to access notification handlers from this folder. Path - Defines relative (to the server configuration file) or absolute path denoting the location where the notification handler files are stored. The component scans only the specified folder (no subfolders are processed) and processes files with the `*.noth` extension.
Resources Folder	N/A	Yes	Defines relative (to the server configuration file) or absolute location where the notification handler stores its supporting files such as the generator state-file and ID mapper. It is also where job execution state files are stored (if the filesystem persister is used).
Result Persister	N/A	Yes	Defines which backend should be used for storing the job execution states. Currently, there are two storage provider implementations: database persister and filesystem persister.

Sources

N/A

Defines a set of sources used for reading the notification handlers. Each source has the following attributes:

Id - Defines a name for the source. Jobs in the source with ID are accessible via the <sourceId>:<handlerName>.noth notation.

One of the sources might not have a name: in such cases, it is processed as an implicit source, so no Id is required to access notification handlers from this folder.
Path - Defines relative (to the server configuration file) or absolute path denoting the location where the notification handler files are stored. The component scans only the specified folder (no subfolders are processed) and processes files with the *.noth extension.

Resources Folder

N/A

Yes

Defines relative (to the server configuration file) or absolute location where the notification handler stores its supporting files such as the generator state-file and ID mapper. It is also where job execution state files are stored (if the filesystem persister is used).

Result Persister

N/A

Yes

Defines which backend should be used for storing the job execution states. Currently, there are two storage provider implementations: database persister and filesystem persister.

Filesystem persister

This backend stores execution information to a .sjr file.

Filesystem persister configuration sample

<component class="com.ataccama.adt.notification.NotificationHandlerServerComponent">
    ...
    <resultPersister class="com.ataccama.adt.scheduler.persister.FileStateResultPersister"/>
    ...
</component>

Database persister

This backend uses a generic core.persistence database infrastructure to store state information to the database. In order to use the database you must specify:

dialectFile - Database module descriptor file that describes the target database. Module files for the most commonly used databases are located at <ATACCAMA_HOME>/db/modules.
dataSource - Name of the connection to the database where logs will be stored. The connection definition must be present in the Runtime Configuration.
prefix - Prefix added to the names of database persistence tables. Default value: SCHDEF_.

Database persister configuration sample (from the previous example)

<component class="com.ataccama.adt.notification.NotificationHandlerServerComponent">
    ...
    <resultPersister class="com.ataccama.adt.scheduler.persister.DbStateResultPersister">
        <dialectFile>../../db/modules/oracle</dialectFile>
        <dataSource>oracle</dataSource>
        <prefix>SCH_</prefix>
    </resultPersister>
    ...
</component>

Was this page useful?