如何用Azure Logic Apps集成ASP.NET自定义WebHook API并串联工作流？

1. 先搭好Logic Apps的触发入口 #

根据你的业务触发逻辑选对应的触发器：

• 若需要定时启动流程，选「Recurrence」触发器
• 若初始请求先到Logic Apps再流转到WebHook，用「When a HTTP request is received」触发器，提前定义好请求体的JSON Schema
• 若初始请求直接发送至你的WebHook，可将Logic Apps的触发点设为「When a message is received in a queue (Service Bus)」——监听WebHook发往Service Bus的消息

2. 调用自定义WebHook（触发后需先走此步骤时） #

在Logic Apps中添加「HTTP」动作，配置如下：

• 请求方法：与你的WebHook接收方法保持一致（如POST/GET）
• URI：填写WebAPI部署后的公网访问地址
• 请求头：若WebHook需要验证（如API Key、签名头），添加对应键值对
• 请求体：与本地测试WebHook时使用的请求体格式完全匹配

3. 衔接Service Bus与Azure Function的处理链 #

你的Azure Function已配置好监听Service Bus队列、处理消息并回写响应队列，此环节无需Logic Apps额外干预，只需确保：

• Function的Service Bus触发器配置正确（连接字符串、队列名称与实际资源匹配）
• 若需在Logic Apps中跟进处理状态，可添加「When a message is received in a queue (Service Bus)」动作，监听Function回写响应的队列，获取处理结果

4. 处理WebHook发回的确认信息 #

WebHook收到Function的响应后会发送确认，Logic Apps可按以下方式接收处理：

• 若确认以HTTP请求形式发送，用「When a HTTP request is received」触发器接收，后续可添加动作通知初始请求方、记录日志到存储服务等
• 若确认写入数据库/存储账户，Logic Apps添加读取动作（如「Get rows」「Get blob content」）获取并处理

5. 配置容错机制 #

给Logic Apps中的关键动作开启「Configure run after」设置：

• 针对调用WebHook的HTTP动作，配置失败时的重试策略（如指数退避），或触发邮件/Teams告警
• 针对Service Bus消息接收动作，设置处理失败时将消息转至死信队列，避免无效消息堆积

提前规避的关键问题 #

• 确保所有Azure资源网络互通：WebHook的防火墙需允许Logic Apps的IP访问，Service Bus的网络规则也要开放对应权限
• 调整超时时间：Logic Apps的HTTP动作默认超时1分钟，若WebHook处理耗时较长，需在动作设置中修改超时阈值
• 给Service Bus队列设置合理的消息过期时间，避免无效消息占用资源

内容的提问来源于stack exchange，提问作者Aryan