LogoLogo
6.0
  • Docs
  • Connector Configuration
  • Knowledge Base
  • Changelog
6.0
  • Introduction
  • Getting Started
    • Build and Publish an Integration
    • Build and Run an Automation
    • Build a Custom Connector
    • Embed into Your Application
    • Monitor & Troubleshoot
    • Access Appmixer REST API
    • Install and Update Connectors
    • Connector Configuration
    • Handle Flow Errors
    • Use App Events
    • End User Guide
  • API
    • Authentication
    • Flows
    • Apps
    • Accounts
    • User
    • Insights
    • Files
    • Data Stores
    • Connector Configuration
    • People Task
    • ACL
    • Charts
    • Config
    • Modifiers
    • Public Files
    • Unprocessed Messages
    • Variables
  • Building Connectors
    • Flow
    • Component
    • Basic Structure
    • Manifest
      • name
      • label
      • icon
      • description
      • auth
      • inPorts
      • outPorts
      • properties
      • quota
      • tick
      • private
      • webhook
      • state
      • author
      • marker
      • localization
      • firePatterns
    • Behaviour
    • Dependencies
    • Authentication
    • Quotas & Limits
    • Example: twilio.SendSMS
    • Example: Webhook Trigger
  • Appmixer UI SDK
    • Introduction
    • Installation
    • Quick Start
    • Constructor
    • API Module
    • UI & Widgets
      • Flow Manager
      • Designer
      • Insights Logs
      • Insights Chart Editor
      • Insights Dashboard
      • Accounts
      • Storage
      • People Tasks
      • Connectors
      • Integrations
      • Wizard
    • Custom API
  • Customizing Embedded UI
    • Custom Theme
    • Custom Strings
    • Custom Component Strings
  • Appmixer Backoffice
    • Getting Started
    • System Configuration
  • Appmixer CLI
    • Getting Started
    • OpenAPI Connector Generator
      • Getting started
      • Open API Extensions
      • Examples
  • Appmixer Self-Managed
    • Installation Docker Compose
    • Installation AWS ECS
    • Getting Started
    • Authentication Hub
    • Additional Configuration
    • Appmixer Architecture
    • Appmixer Deployment Models
  • Tutorials
    • Appmixer Virtual Users
    • Flows Metadata & Filtering
    • Access Control
    • Sharing Flows
    • People Tasks
    • Customizing modifiers
  • Connectors
    • Connector Configuration
    • Connector Request
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Building Connectors
  2. Manifest

firePatterns

PreviouslocalizationNextBehaviour

Last updated 1 year ago

Was this helpful?

Fire patterns is an advanced configuration of a component that allows you to define when your component is ready to fire (ready to process input messages). Fire patterns can make the engine to hold input messages on components input ports until the pattern matches and then send the messages to the component in bulk. Fire patterns are defined as an array or a matrix. An example of fire patterns may look like this:

{
    "firePatterns": ['*', 1]
}

The fire pattern above is interpreted as follows: The component processes messages only if the first input port has zero or more messages waiting in the queue and at least one message waiting in the second input port queue. Another example can be a fire pattern:

{
    "firePatterns": [1, 1]
}

In this case, the component only processes messages if there is at least one message on each of its two input ports. A good example for this pattern is the Sum component:

The Sum component expects messages on both of its input ports before it can produce a sum of its inputs.

The following table lists all the possible fire pattern symbols:

Symbol

Description

*

(Any) The input port must have zero or more messages in the queue.

1

(Exists) The input port must have at least one message in the queue.

0

(Empty) The input port must have no message in the queue.

A

(All) The input port must have at least one message from all the connected components in the queue. This is a synchronization pattern that lets you specify that the component must wait for all the connected components to send a message before it can start processing. A typical example is a "Multiple-to-Single" join component. This component must wait for all the LoadCSV components to send a message before it can produce an SQL-like join schema.

Note that you can also define a set of fire patterns for a component, for example:

{
    "firePatterns": [
        ['*', 1],
        [1, 0]
    ]
}

When more fire patterns are used, there must be at least one fire pattern that matches before the component fires.