如何封装存在WSDL缺陷的慢SOAP服务以供Logic Apps使用？

1. ASP.NET Web应用直接托管的超时判定问题 #

如果你采用同步请求等待SOAP调用返回的模式，必然会触发Azure的超时报错。Azure App Service前端负载均衡的默认硬超时限制为230秒，该限制无法通过应用配置修改，哪怕你在web.config中调整了ASP.NET请求超时、WCF客户端超时参数，超过230秒后负载均衡会直接断开连接返回超时错误，完全无法支撑最长120分钟的调用需求。

2. 返回200响应后后台线程存活的可靠性问题 #

不建议依赖ASP.NET请求结束后的后台线程执行长时任务。ASP.NET的请求生命周期结束后，关联的线程会被回收至线程池，同时Azure App Service默认会在无活跃请求、达到内存阈值、定期滚动更新时回收应用进程，你启动的后台线程随时会被中断，大概率无法完整跑完2-3小时的SOAP调用，数据一致性也无法保障。

3. 最适配的Azure托管方案 #

最适合你场景的托管方案是 Durable Functions（运行在弹性Premium计划/专用App Service计划下），理由如下：

• 天然支持异步HTTP 202模式，接收到Logic Apps的调用请求后会立刻返回带轮询地址的202响应，Logic Apps原生支持自动轮询该地址直到任务完成，无需你自行实现异步状态管理、轮询接口逻辑
• 弹性Premium计划/专用App Service计划下的Durable Functions可将单活动函数的最长执行时间配置到6小时，完全覆盖你120分钟的SOAP调用需求
• 内置状态持久化机制，哪怕遇到应用进程滚动更新，也会自动重试中断的任务，调用结果会自动存储供Logic Apps拉取
• 可以直接复用你现有的WCF客户端逻辑、消息检查器代码，几乎无额外改造量

可选备选方案：

• 开启Always On的Azure App Service 持续WebJobs：同样支持最长无限制的长时运行，但需要你自行实现异步请求状态存储、轮询接口，适配Logic Apps的异步调用规范
• Azure容器应用：支持任意时长的长时间运行任务，灵活性最高，但需要你自行封装异步HTTP逻辑、管理任务状态，运维成本相对更高

配置注意事项 #

• 调整WCF客户端的sendTimeout、receiveTimeout参数为大于3小时，避免WCF层面主动断开连接
• 调整WCF绑定的maxReceivedMessageSize、ASP.NET的maxAllowedContentLength参数到大于20MB，避免大载荷被拦截
• Durable Functions配置中修改functionTimeout参数到3小时以上，适配你的调用时长

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