Skip to content

触发器

每张图的开头有且只有一个触发器节点。触发器本身不运行任何逻辑,它只决定图的其余部分何时获得一次新运行。

快速概览

  1. 把一个触发器节点拖到画布上;它是第一个节点,没有输入连接口。
  2. 如果它有字段,就配置它(一个计划的节奏,一个要监视的文件夹)。
  3. 激活自动化,让它开始监听那个触发器。
  4. 或者跳过这一切,随时按 Test 运行这张图一次,与触发器无关。

详细参考

手动

Manual start 没有字段。它正是构建器的 Test 按钮所用的方式:发布当前草稿,然后立即排入一次运行。

定时

Scheduled 按你设定的节奏触发。

字段选项
FrequencyInterval、Daily、Weekly 或 Cron
Every (minutes)仅在 Interval 模式下使用
Cron expression仅在 Cron 模式下使用;一个标准的 5 字段表达式(分 时 日 月 周),例如 0 9 * * 1-5 表示工作日的 09:00
Timezone仅在 Cron 模式下使用;一个 IANA 名称,如 Europe/Istanbul。留空时,表达式将按服务器自身的时钟匹配

一个激活的定时自动化会在后台按周期性循环被检查;你不需要一直开着应用。Interval、Daily 和 Weekly 模式相对于自动化自身上一次触发的时间来触发。Cron 模式会保留一个滚动的“下次到期”指针,遇到漏掉的一分钟(一次部署、一次重启、一次缓慢的检查)时,会在察觉的那一刻立即补触发一次,而不是悄悄丢掉那一次;对同一个漏掉的窗口,它绝不触发两遍。

传入 webhook

Incoming webhook 为每个自动化提供一个唯一的入站 URL,即 /api/workflow/hook/<automation id>,用 GETPOST 请求调用它时就会启动一次运行。它只在自动化状态为 Active 时才触发。

构建器目前不会为你显示或复制这个 URL;该节点自己的检查器里只有 HMAC 密钥字段。要用它,你(或团队里的开发者)需要拿到自动化的 id,这个 id 可以从构建器打开时应用已经发出的网络请求里读到,再由你自己把它和固定的 /api/workflow/hook/ 路径拼起来。

设计与工作区事件

这些会在应用里别处发生某事时触发。目前 Design updated 已接线,每当一个设计被保存时自动触发。其余的现在都可以配置;随着这些界面逐步建成,会有更多应用自身的动作接入它们。

节点触发时机
Design created新建了一个设计
Design updated保存了一个设计
Design shared分享或发布了一个设计
Design downloaded下载了一个设计
Part tagged给某个部件添加了标签(可选按单个标签过滤)
Brand applied给某个设计应用了品牌套件
Asset uploaded有文件被添加到媒体库
AI generation done一次 AI 生成完成
New work in folder有项目被添加到你选择的文件夹

事件桥

任意触发器类型还能通过一次限定在你工作区内、经过认证的通用 API 调用来启动:一个 triggerType 加一个可选的载荷。上面的设计更新钩子在底层就是这样触发的,它同样开放给你自己的集成以相同方式调用。

多个自动化,同一种触发器类型

不止一个激活的自动化可以使用同一种触发器类型。例如,一个设计被保存,就能同时启动你工作区里所有激活的“Design updated”自动化,各自独立运行、各有各的历史。

如何使用

操作演示:一个工作日清晨的 cron 计划

  1. 把一个 Scheduled 触发器拖到一张空图上;它必须是这张图唯一的触发器。
  2. 把 Frequency 设为 Cron
  3. 在 cron 表达式字段里输入 0 9 * * 1-5(09:00,周一到周五)。
  4. 把 Timezone 设为你自己的,例如 Europe/Istanbul,这样 09:00 指的是你本地的清晨,而非服务器的时钟。
  5. 在它之后至少加一个动作节点(光有触发器无法通过 Validate),然后 ValidateActivate
  6. 首次激活会武装该计划的下一次触发,而不是立即触发;从此以后,它每个匹配的清晨都会触发,无需你再动它。

操作演示:一个经签名验证的 webhook

  1. 拖入一个 Incoming webhook 触发器,在它的 HMAC 密钥里填一长串随机字符串,并把副本存到安全的地方;此后没有办法再显示一个忘记了的密钥,只能用一个新的覆盖它。
  2. 在它之后至少加一个动作,Validate,然后 Activate;只有当自动化状态为 Active 时,那个入站 URL 才接受调用。
  3. 找到自动化的 id(见上文),把 URL /api/workflow/hook/<id> 交给发送方系统,并说明要用你的密钥对原始 JSON 请求体签名,作为 X-Signature: sha256=<hex hmac> 发送。
  4. 如果发送方系统有“发送测试事件”功能,就用它;否则手动发送一个请求,去 Activity 视图查看是否有新运行,而不是干等一个真实事件。

操作演示:从你自己的代码触发一个触发器

  1. 任意触发器类型都能通过这个通用事件桥启动:一次经过认证的 POST/api/workflow/events,请求体形如 { "triggerType": "trigger.asset_uploaded", "payload": { "assetId": "..." } }
  2. 这正是应用自身的 Design updated 钩子在内部所用的路径,所以它是一条经过验证的方式,用来接上一个内置编辑器尚未自动触发的事件。
  3. 一次调用会触发你工作区里所有触发器与该类型匹配的 ACTIVE 自动化,每个都获得自己独立的运行,并以你的载荷作为起始上下文。

疑难排查

  • 我触发器对应的事件发生了,却没有运行启动。 目前只有 Design updated 接线为由应用自身自动触发。其余的设计与工作区事件触发器一旦被触发就完全可用,但除了你自己通过上面事件桥做的集成之外,应用里还没有任何东西去调用它们。在等待接线的同时,用 Test 运行这张图,与触发器无关。
  • 自动化是 Active,但一个 webhook 调用返回 404。 确认状态真的是 Active,而非 Paused 或 Draft,因为只有 Active 的自动化才会解析它的 webhook URL,并再次核对 URL 里的 id 完全正确。
  • 一个 webhook 调用返回 401。 该触发器配置了 HMAC 密钥,而调用的签名要么没发送,要么不匹配。签名是基于确切的原始请求体计算的,所以在签名前重新格式化或重新序列化 JSON 会破坏校验,哪怕内容看起来一模一样。
  • 事件触发了,运行却不是每次都启动。 检查自动化 Settings 里的 Debounce 窗口,以及触发器节点自身的 debounce 字段(在事件触发器上);任一个都会悄悄丢掉一次落在前一次之后冷却期内的触发。
  • 一个定时自动化在某些时段安静下来。 检查 Settings 里的 Quiet hours;一个本会在那个窗口内(按自动化自己的时区)触发的触发器会被推迟,而不是丢弃或排队,所以窗口结束后它不会追溯触发。
  • 两个自动化共用一种触发器类型,却只有一个运行了。 如果只有一个是 Active,或另一个在触发器节点上自己的标签/文件夹过滤没匹配到这个特定事件,那这是预期之内的。

提示

每张图一个触发器

校验会标记出没有触发器或多于一个触发器的图;请精确保留一个。

Webhook 仅在激活时触发

对一个 Paused 或 Draft 自动化的传入 webhook 调用会被忽略。请先激活它。

相关