# 触发器与事件源

Source: https://openflow.run/zh-cn/docs/concepts/triggers/
Language: zh-CN
Product version: 0.1.0-beta.77

选择运行入口，并了解自动执行需要哪些配置。

每次运行都从一个触发器开始。工作流可以有多个入口，但一次运行不会同时启动所有入口。

## 入口类型

| 触发器 | 启动来源 |
| --- | --- |
| 开始 | 显式调用，传入声明的工作流输入。 |
| Webhook | 已接受的 HTTP 请求。 |
| 定时触发 | 到达某个计划时间。 |
| 工作流错误 | 所选上游工作流中符合条件的生产运行失败。 |
| 应用事件 | 从应用目录选择的具体事件，例如 Gmail 收到新邮件或 Slack 提及。 |

草稿测试可以模拟触发器。生产环境自动执行要求工作流已成功发布并启用。

定时触发器在工作日 UTC 09:00 启动生产运行，返回固定的报告消息。

**输入**
Cron：0 9 * * 1-5；时区：UTC。

**预期结果**
{"message":"Daily report is ready"}

**运行前准备**
在运行了调度器的部署环境中，发布并启用工作流。

[下载工作流](https://openflow.run/docs/examples/daily-schedule.openflow.json)

## 应用触发器定义

“触发器”页签将内置入口和应用事件分开展示。先选择应用，再从部署端目录选择具体事件；所选定义提供配置字段和输出。详见[应用触发器](https://openflow.run/zh-cn/docs/nodes/integration/index.md)。事件配置在运行创建前就已确定，不能读取新运行内部才会产生的输出。

需要为所选入口配置账号连接、事件源、回调验证和应用权限。已保存的执行图通过校验，并不能证明这些外部条件已经满足。

## 共享事件源

部分应用事件使用应用、工作区或账号级的共享事件源。每个匹配的工作流各自接收事件，并按当前发布版本和权限接受检查。禁用其中一个工作流，不会删除其他工作流的订阅。

Connector 后端负责应用协议检查；Open Flow 负责接收运行和持久化投递进度。收到回调，不等于已成功创建运行。

## 事件标识

同一事件的稳定标识，可以防止已接收事件的重试再创建一次普通运行。新的业务事件仍可启动新的运行。调度、去重和生命周期协调由部署端负责。

## 资料来源

*   [docs/architecture.md](https://github.com/oomol-lab/open-flow/blob/e25a738d170322734572a0b8a1323cb00b9d355a/docs/architecture.md#event-sources)
*   [docs/architecture.md](https://github.com/oomol-lab/open-flow/blob/e25a738d170322734572a0b8a1323cb00b9d355a/docs/architecture.md#publication-and-trigger)
*   [docs/control/trigger-permissions.md](https://github.com/oomol-lab/open-flow/blob/e25a738d170322734572a0b8a1323cb00b9d355a/docs/control/trigger-permissions.md)