Setting up Triggers from SDK Templates

How do I set up the trigger?

  • All you need to do is call the template function of your SDK as demonstrated here. This will instantiate a trigger node and an API node to monitor the data source.
    • If you’re using a webhook template, it will also instantiate a webhook API node that will dump new data to your endpoint.

How do I check the data the trigger currently has without waiting for the trigger to fire?

  • The SDKs support a state function that will return the current data associated with the trigger (assuming the trigger is authenticated correctly, is active, and is successfully retrieving data from the source).
  • You should call this function on the trigger that is instantiated by the template function. For most DryMerge templates, the trigger ID will look something like DryMerge/airtable/new-row{{template.identifier}}.trigger where template.identifier is the identifier you used when instantiating the template. This is most often a tenant id.
    • If using a prebuilt webhook, the trigger ID will fit the same format as above. For example, DryMerge/airtable/new-row-webhook{{template.identifier}}.template will have a corresponding trigger called DryMerge/airtable/new-row{{template.identifier}}.trigger.
  • You can manually force a trigger to sync (and thus update its state) by calling the SDKs sync function on the trigger. This is useful at instantiation of the trigger if you want your users to instantly get data from the source.
  • You can also manually monitor the data source without updating trigger state by calling the trigger’s associated check node directly. This looks something like DryMerge/airtable/monitor-table{{template.identifier}}.api. You can hit this node by using the SDKs run function or by using the CLI. There is no defined naming convention for the monitor nodes, so we recommend simply using the state function or sync function instead.
    • If you want this functionality, feel free to reach out to us and we can get you the appropriate node names.
    • Alternatively, you can use the dry pull CLI command on your trigger node to manually pull the YAML configuration for the trigger. This will include the monitor node name.

How does setting up an RPC trigger from a template differ from a webhook trigger?

  • There are very few differences in creating the trigger via template SDK call. You will still need to provide an identifier. The only difference is that the RPC templates typically take a proxy_id parameter, where this is a DryID (formatted as a string) corresponding to the queue that your client will be listening to.
  • The client will need to be initialized with its proxy parameter equal to the proxy_id you provide when instantiating the template.
  • You will need to use the client.route function to pair off a function name with a handler function. The function name (if instantiating from a template) is simply the namespace of the template, the name of the template, plus your tenant ID (blank) if using in a single-tenant architecture.
  • You will need to run client.start to start listening to the queue. You’ll need to make it non-blocking by delegating it to a different thread depending on your architecture.