Pin filters

This page is for explaination of filters logic

For every pin can be used filters that will check dataflow for primary or secondary features.

General

For usage of filters need to specify them right below pin like in next example:

- name: out_data
  connection-type: mq
  attributes: ["data_out", "parsed", "publish"]
  filters:
    - metadata:
      - field-name: session_alias
        expected-value: some_session
        operation: EQUAL

Block filters: can contain two types of blocks: message and metadata.

• Metadata block can filter all messages by their metadata. It's can be timestamp or any another field like session_alias or property from map.
• Message block can filter messages by their content.

Each of those blocks can contain multiple blocks of filters. As example:

  filters:
    - metadata:
      - field-name: session_alias
        expected-value: fix-client
        operation: NOT_EQUAL
      - field-name: session_alias
        expected-value: fix-client2
        operation: EQUAL

Multiple filters supports only for infra 1.7.0 and highter

Тew format filter works according to logical operator "disjunction" (OR).

Operations

Field operation can take values: EQUAL, NOT_EQUAL, EMPTY, NOT_EMPTY, WILDCARD

• EQUAL / NOT_EQUAL - compares the two given fields based on the data/content
• EMPTY / NOT_EMPTY- checks if the fields content is empty or not
• WILDCARD - is a series of characters that are matched against incoming fields content

Wildcard example:

- name: to_codec_test
      connection-type: mq
      attributes:
        - to_codec
        - raw
        - publish
      filters:
        - metadata:
          - field-name: session_alias
            expected-value: test*
            operation: WILDCARD

For incoming messages with aliases: test1, test2, test3, test4, alias1, alias2 - will match: test1, test2, test3, test4

Please note that WILDCARD can be used only in common 3.31.0 and highter