Azure Function触发器对接及搭配ADF使用相关问题咨询

问题1：HTTP Trigger对接XML API的可行性 #

• 你的认知不正确，HTTP Trigger本身仅负责处理HTTP协议的请求与响应，和接口返回的数据格式（XML/JSON/二进制等）没有绑定限制，完全支持对接XML API。
• 你调用第三方XML API时，只需要在HTTP请求头设置正确的Accept、Content-Type（如果需要传XML参数），拿到响应后直接解析XML格式的报文即可，不需要额外修改HTTP Trigger的基础配置。

问题2：Timer Trigger搭配ADF的中间数据存储与旧数据清理 #

• Timer Trigger本身不会默认存储你拉取的业务中间数据，中间数据的存储位置完全由你自己的业务代码控制：你可以选择存到Function App绑定的存储账号的Blob/Table里，也可以存在其他你有权限的存储服务中。
• 如果是你主动存在绑定的存储账号中，ADF可以通过配置对应存储的连接器直接拉取数据。
• 旧数据清空可以用两种方案实现：1. 每次Timer Trigger执行拉取逻辑前，先通过Azure Storage SDK调用对应Blob/Table的删除接口，删除上一次的旧数据；2. 给存储的Blob设置生命周期管理规则，自动清理超过指定时间的旧文件。

问题3：业务逻辑编写位置与Program.cs的调用关系 #

• 拉取数据的业务逻辑可以直接写在Function类的Run方法内，也可以封装到其他独立类文件里再调用，这两种写法都符合规范。
• 你完全可以在Run方法中调用同解决方案下ListVendors.cs里的对应方法，只需要确保方法的访问权限是可访问的即可，没有额外限制。
• 对于隔离进程模型（Isolated Worker Model）的Azure Function，Program.cs的Main方法是整个应用的入口，会先执行Main方法里的配置注册逻辑，完成应用初始化后才会开始监听触发事件、执行对应Function的Run方法；如果是进程内模型（In-Process Model），默认没有Program.cs和Main方法，你如果手动加了的话不会被默认调用，执行入口是Function的Run方法。

问题4：Function解决方案的执行流程 #

• 执行优先级由你使用的Function运行模型决定：
  • 如果你用的是隔离进程模型：优先执行Program.cs的Main方法，完成主机启动、服务注册、触发器绑定等初始化操作之后，才会在对应触发器被触发时执行Function的Run方法。
  • 如果你用的是进程内模型：主机由Azure Function运行时直接启动，默认不会执行你自定义的Main方法，触发器触发时直接调用对应Function的Run方法。
• 整体执行流程：运行时启动→初始化宿主环境→加载所有触发器配置→等待触发器被触发→触发后匹配对应Function的Run方法执行。

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