Axway Gateway: Managing Events

Managing events on Gateway

This topic introduces Events, Decision Rules and Rule Tables in Gateway.

About Event Management on Gateway

Basic example

Types of triggering event and conditions

Types of triggered processes

Rule Table exits

About Event Management on Gateway

You can configure Gateway to execute tasks triggered by different types of event and platform conditions. To do this, you create Decision Rule and Rule Table objects.

Decision Rule objects

In a Decision Rule object, you define one or more events that you want to trigger a specific action. You also specify the action that is carried out when the event occurs. You can create as many Decision Rules as you require. You place Decision Rules in Rule Tables.

There are four categories of Decision Rules and Rule Tables, as described in Types of triggering event and conditions.

Rule Table objects

A Rule Table object is an ordered list that contains one or more Decision Rules. For each Decision Rule that it contains, the Rule Table displays the following parameters:

  • Order
  • Decision Rule name
  • Action to be executed
  • Condition parameters

You arrange Decision Rules in a Rule Table in the order of preferred execution priority. When Gateway handles a transfer event or condition and evaluates the table, it evaluates the table entries from top to bottom in the order of priority. It selects the first Decision Rule that presents a complete conditional match.

Additionally, in a Rule Table object you can:

  • Define a default execution type for the Table. If no Decision Rule matches the Transfer parameters, Gateway applies the default execution type.
  • For Transfers, restrict processing to a limited set of Transfers, depending on the following conditions:
    • Transfer type: TRANS, MSG ...
    • Transfer mode: Responder, Initiator...
    • Transfer direction: IN, OUT...
    • Transfer state: ENDED, ACKED...
  • Set the log level to No Log, Short or Full.

There are four categories of Decision Rules and corresponding Rule Tables, as described in Types of triggering event and conditions.

You can define more than one Rule Table. You can define multiple Rule Tables in the same category or combine one or more Rule Tables of different categories.

Basic example

As a basic example, you can link the reception event of an FTP transfer from a specified site (Site A in the illustration below) to a forwarding process that redirects the file to a designated server (Site B in the illustration below).

You define the triggering conditions and resulting processing for the transfer in a Decision Rule that you create and place in a Rule Table.

Types of triggering event and conditions

You can link many different types of events and conditions to execution processes. Gateway separates these event and condition types into four categories, each with its own set of Decision Rules and Rule Tables. The four different categories are described in the following table.

Category

Use

Example

Transfer Change State

Trigger a specified action using one or more transfer attribute values as the triggering criteria.

Create a Decision Rule specifying:

  • Transfer Direction: Incoming
  • Transfer Type: FTP
  • Originating Site: SiteA

To this condition, link an action forwarding the file to a specified server using an outgoing transfer definition model.

When Gateway detects an incoming FTP transfer originating from SiteA, it initiates the Transfer Request.

For a detailed example of routing using Transfer State Change Decision Rules and Rule Tables, refer to Usage example: Routing.

Directory Scanning

Trigger a specified action using the detection of a specific file or file type in a directory of the Gateway host machine as the triggering criteria.

Create a Decision Rule specifying as a condition that a file named example.txt is present in the directory C:\xfb_poll\*.

To this condition, link an action sending the file to a specified monitor via a Transfer Request.

When Gateway detects the specified file in the specified directory, it initiates the Transfer Request.

For a detailed example of a Transfer triggered by the presence of a file in a specified folder, refer to Usage example: Directory Scanning.

Scheduling

Trigger a specified action at a specific time.

Note   There is an application architecture issue that affects all time zones when adjusting for DST one hour back: the scheduled events do not run at all during the 1-hour period between the clocks being moved back and the time from which the clocks were originally moved back. (For example: in Brazil, after the time changes from 00:00 to 23:00, between 23:00 and 00:00 - 1-hour period- no scheduled events will run). After this 1-hour period, the events will resume running without requiring any intervention.

Create a Decision Rule specifying that the file todays_log is archived every day at 12 a.m.

For a detailed example of the scheduling of a repeated task, refer to Usage example: Scheduling.

XMS

Trigger a process linking an Axway Messaging transfer to a transfer via Gateway.

Link an Axway Messaging connector to an XMS-type Decision Rule.

When Gateway detects a transfer over the connector it applies the appropriate Model to the transfer.

Refer to: Axway Messaging connector.

In the main window of the GUI, each of the categories is represented by a separate node containing a specific set of menus and windows.

Types of triggered processes

Decision Rules and Rule Tables link the triggering events to Gateway actions. There is a wide variety of actions that Gateway can execute. For example, when triggered by a Decision Rule, Gateway can:

  • Execute a batch file or Perl script
  • Caution   Please note that care should be taken when writing event scripts, as there are some security risks involved if the custom code is not properly reviewed and security best practices are not followed. Please see the Security Guide > Security best practices > Identified threats and possible mitigations section for additional information.
  • Deposit a Transfer Request
  • Purge a Mailbox or archive a Log file
  • Apply a Model for a message transfer to an Axway Messaging server (XMS category only)
  • ...

Rule Table exits

Gateway automatically associates three categories of Rule Table with the following exit functions that are called during processing.

Rule Table category

Associated exit

Transfer Change State

exitmisc.c

Directory Scanning

exitfs.c

Scheduling

exittemp.c

Gateway triggers these exits immediately before it scans the corresponding table for matching.

You can modify these Rule Table related exit functions and then locally recompile the functions in order to integrate the modifications into Gateway. This enables you to add additional control over whether or not Gateway analyzes a specific Rule Table. Alternatively you may choose to modify exits in order to apply reusable user variables to Transfer Models or to triggering conditions, or to apply alternate handling processes via APIs.

Related topics

Overview: Event management

Transfer states in Gateway

Working with Rule Tables and Decision Rules

Creating an Axway Messaging connector

Defining Decision Rule conditions

Working with Decision Rules (command line)

Working with Rule Tables (command line)

Decision Rules and Rule Tables: Parameters List

Command syntax for Scheduling Event Models (date syntax)

Usage example: Routing

Usage example: Directory Scanning

Usage example: Scheduling

User exits and Rule Tables

 

Links to documentation set for Axway Gateway 6.17.3:

Related Links