ConsumeSlackConversation 2025.5.31.15¶
捆绑包¶
com.snowflake.openflow.runtime | runtime-slack-processors-nar
描述¶
从应用程序可用的 Slack 对话中检索消息。根据“回复监控频率”提取新对话。引入的消息采用 JSON 格式编写。有关如何配置此处理器并使其能够从 Slack 检索消息的更多信息，请参阅“用法/其他详细信息”。
输入要求¶
FORBIDDEN
支持敏感的动态属性¶
false
属性¶
属性 |
描述 |
|---|---|
访问令牌 |
用于认证/授权 NiFi 发送的 Slack 请求的 OAuth 访问令牌。这可以是用户令牌或机器人令牌。根据所使用的会话类型，必须授予以下范围之一：channels:history、groups:history、im:history 或 mpim:history scope。 |
批处理大小 |
通过向 Slack 发出的单个请求可以检索的最大消息数量。整个响应都会被解析到内存中，在设置此值时务必考虑到这一点。 |
回复监控频率 |
在使用一个给定频道中的所有消息后，该处理器将定期轮询时间戳介于现在和 <Reply Monitor Window> 属性指定时间之间的所有“对话串消息”（即回复）。此属性决定轮询这些消息的频率。将此值设置为较短的持续时间可能会更快地获取对消息的回复，从而降低延迟。但这也会消耗额外的资源，并可能触发速率限制。这也决定了检查新添加频道的频率。 |
回复监控窗口 |
在使用一个给定频道中的所有消息后，该处理器将定期轮询其时间戳介于现在和过去这段时间之间的所有“对话串消息”（即回复），以检查是否有任何新回复。将此值设置为更大的值可能会消耗额外的资源，并可能导致速率限制。但如果用户回复在此时间窗口之外启动的旧对话串，则可能无法获取回复。 |
解析用户名 |
指定是否应将用户 IDs 解析为用户名。默认情况下，Slack 消息提供发送消息的用户的 ID，例如 U0123456789，但不会提供用户名，例如 NiFiUser。用户名可能已解析，但可能需要对 Slack API 进行额外调用，并需要将所用令牌授予 users:read 范围。如果设置为 true，则将使用“尽力而为”的策略解析用户名：如果无法获取用户名，则会跳过该用户名。另请注意，获取用户名后，系统会填充消息的 <username> 字段，还会更新 <text> 字段，因此会输出任何提及的内容，例如“Hi @user”，而非“Hi <@U1234567>”。 |
状态管理¶
范围 |
描述 |
|---|---|
CLUSTER |
维护 Slack 通道 IDs 与为该频道检索的最后一条消息的时间戳之间的映射。这允许处理器仅检索自上次运行处理器以来发布的消息。此状态会存储在集群中，因此，如果主节点发生变化，新节点将从上一个节点中断的地方继续。 |
关系¶
名称 |
描述 |
|---|---|
success |
成功接收的 Slack 消息将路由到此关系 |
写入属性¶
名称 |
描述 |
|---|---|
slack.channel.id |
从中检索消息的 Slack 通道的 ID |
slack.message.count |
FlowFile 中包含的 slack 消息的数量 |
mime.type |
设置为 application/json，因为输出将始终采用 JSON 格式 |