language-spec.md

TriggerMesh Integration Language Specification

The TriggerMesh Integration Language is a configuration language based on the HCL syntax which purpose is to offer a user-friendly interface for describing TriggerMesh Bridges.

Contents

1. Configuration Files
2. Attributes and Blocks
3. Blocks Labels
4. Component Identifiers
5. Block References
6. Global Configurations
7. Component Categories
   • channel
   • router
   • transformer
   • source
   • target

Configuration Files

A Bridge Description File contains the description of a single Bridge.

The description of a Bridge can only span a single Bridge Description File.

We suggest using the two extensions .brg.hcl with Bridge Description Files for the following reasons:

• The .brg part allows IDEs to understand that the file describes a TriggerMesh Bridge and enable, if supported, optional language-specific integrations, such as autocompletion and live validation.
• The .hcl part allows text editors and IDEs to fall back to a generic syntax highlighting for HCL files, since HCL is a widely supported file format.

Attributes and Blocks

The language does not support any top-level attribute.

The following block type must appear at most once in a configuration file. It contains configurations which pertain to an entire Bridge. Details are presented in the Global Configurations section.

• bridge

The following block types can appear in a configuration file in any order and number of occurrences. Each of them represents a different component category. Details are presented in the Component Categories section.

• channel
• router
• transformer
• source
• target

Block Labels

Labels that appear in top-level blocks must be valid HCL identifiers, and can therefore be written either as quoted literal strings or naked identifiers.

• Both "foo_bar" and foo_bar are acceptable labels (valid HCL identifiers, quoted and unquoted are equivalent)
• Neither foo/bar nor 00foo_bar are acceptable labels (invalid HCL identifiers)

Component Identifiers

Labels that represent component identifiers must be unique in a given component category.

• There can be both a channel and a router blocks with the same foo identifier.
• There cannot be two channel blocks with the same foo identifier.

Block References

Certain types of blocks can contain to and/or reply_to attributes which are references to other blocks. Whether those attributes are present at the root of a block or nested inside sub-blocks, their value must be a variable expression composed of a component identifier separated from a block type by an attribute access operator.

• channel.my_channel is a syntactically valid block reference.

Global Configurations

bridge <BRIDGE IDENTIFIER> {
    delivery {
      retries = <integer> // optional
      dead_letter_sink = <block reference> // optional
    }
}

A bridge block has exactly one label, which represents its identifier. This identifier is used to set the Bridge's components apart from other resources in the destination environment.

A delivery block may be set inside a bridge block. Its attributes control global aspects of message deliveries:

• retries: the minimum number of retries a sender should attempt when sending an event.
• dead_letter_sink: component where events that fail to get delivered are moved to.

Component Categories

Unless otherwise specified, each documented top-level attribute is required.

channel

channel <CHANNEL TYPE> <CHANNEL IDENTIFIER> {
    # component-type-specific configuration
}

router

router <ROUTER TYPE> <ROUTER IDENTIFIER> {
    # component-type-specific configuration
}

transformer

transformer <TRANSFORMER TYPE> <TRANSFORMER IDENTIFIER> {
    # component-type-specific configuration
}

source

source <SOURCE TYPE> <SOURCE IDENTIFIER> {
    to = <block reference>

    # component-type-specific configuration
}

target

target <TARGET TYPE> <TARGET IDENTIFIER> {
    reply_to = <block reference> // optional

    # component-type-specific configuration
}