Before you Begin

Before you begin:

1. Feature summary

The Trigger Service has been rewritten and restructured for the most recent 4.1.3 version to allow for a number of improvements including the following new features:

  • Individual triggers may be created without restarting the container.
  • Once created, triggers can be enabled/activated or disabled/deactivated without restarting the container.
  • The parameters which define the trigger can be edited individually, in real-time, without restarting the container.

Other Supported Features

  • Uses the Aggregator Framework to monitor XML data for matching trigger conditions
  • When a trigger condition matches, fires a customizable action: for example, sends email to an administrator.
  • Monitored services are managed through service group-based registration API, allowing use of many of the same clients that can be used in the Index Service.

Deprecated Features

  • Not applicable

2. Tested platforms

Tested Platforms for MDS4 Trigger Service

  • Linux on i386

Tested containers for MDS4 Trigger Service:

  • Java WS Core container

3. Backward compatibility summary

The Trigger Service is a new component for GT 4.1.3 and so has no compatibility statement.

4. Technology dependencies

The Trigger Service depends on the following GT components:

The Trigger Service depends on the following 3rd party software:

  • None

5. Security considerations

The security considerations for the Aggregator Framework also apply to the Trigger Service:

By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.