业务问题：每天一次，我们想从数据库中读取多行（具有特定条件），遍历这些行并向该行中的电子邮件发送一封电子邮件，然后更新该行，说明该电子邮件已发送（以防止每天或每天多次向该人发送电子邮件）。
我们所有的数据库、服务器、wep 应用程序等都在使用 windows azure。看到我们有应用程序服务，我们开始考虑创建一个逻辑应用程序的想法来研究这个问题。
简单逻辑应用流程：重复（每天一次）=> SqlConnector（StoredProcedure 或 select 语句）=> Foreach 行（emailapi（row.email）=> SqlConnector（更新行））
并发症：
逻辑应用需要从我们的一个 sql 数据库中读取。所以我们通过创建一个 sql 连接器来解决这个问题，从该连接器我们可以公开存储过程、表等。sql 连接器的主要问题是我们要调用的存储过程只是根据其中涉及 sql 函数，并且 sql 连接器无法生成逻辑应用读取 select 语句返回的行所需的元数据。sql 连接器只能为 out 参数或返回值生成元数据，我们无法通过它们返回多行。
下一个想法和第二个复杂之处是，由于我们意识到我们无法调用此存储过程并取回行，因此我们尝试使用 select 语句通过 sql 连接器获取我们的行。这种方法的问题是我们的 where 子句中必须有一个 sql 函数，这是不支持的。
忽略并发症：
假设我们可以从数据库中读取这些特定的行，然后我们想要遍历这些行，这些行应该可以通过逻辑应用程序中的“重复”操作获得，并发送一封电子邮件。我们选择使用我们自己的自定义 API 发送电子邮件（Azure 不为我们的电子邮件服务 SendWithUs 提供托管 API）。电子邮件工作完全正常，我们能够从我们的 azure 逻辑应用程序查看和调用我们的 api 端点。我们对这个发送电子邮件的 api 端点的担忧是它不是最安全的。
我的问题/s：我们能否完成我们尝试使用 sql 连接器完成的任务，还是应该寻找替代方案？
替代方法：将我们想要做的所有事情放在提供电子邮件端点的自定义 api 应用程序中。这将需要连接到数据库，调用存储过程，循环存储过程的结果以发送电子邮件，然后更新已发送电子邮件的数据库记录。此时我们的逻辑应用程序将只有一个重复触发器和一个完成所有工作的 api 调用。但是，此 api 端点需要尽可能安全，同时仍可从逻辑应用程序访问。
