适用范围:Azure 逻辑应用(消耗型 + 标准型)

Azure 逻辑应用有助于创建并按计划运行自动化重复性工作流。 创建使用内置重复触发器或滑动窗口触发器(计划类型的触发器)启动的逻辑应用工作流,以后可以立即运行或者按重复间隔运行任务。 可以调用 Azure 内部和外部的服务(例如 HTTP 或 HTTPS 终结点)、将消息发送到 Azure 存储和 Azure 服务总线等 Azure 服务,或者将文件上传到文件共享。 使用重复触发器,还可以设置复杂的计划,以及运行任务的详细重复周期。 若要详细了解内置计划触发器和操作,请参阅 计划触发器 计划操作

无需为每个计划的作业单独创建逻辑应用,也无需占用 每个区域和订阅的工作流限制配额 ,即可计划和运行重复性工作负荷。 可以使用 Azure 快速入门模板:逻辑应用作业计划程序 创建的逻辑应用模式。

Azure 逻辑应用作业计划程序模板会创建一个调用 TimerJob 逻辑应用的 CreateTimerJob 逻辑应用。 然后,你可以通过发出 HTTP 请求并传递一个计划作为请求的输入,以 API 的形式调用 CreateTimerJob 逻辑应用。 每次调用 CreateTimerJob 逻辑应用时,都会调用 TimerJob 逻辑应用,这会创建一个根据指定计划持续运行的、或者一直运行到达到指定限制的新 TimerJob 实例。 这样,便可以运行任意数目的 TimerJob 实例,而无需担心工作流限制,因为实例不是单独的逻辑应用工作流定义或资源。

此列表显示了可以使用计划内置触发器运行的一些示例任务:

  • 获取内部数据,例如每天运行某个 SQL 存储过程。

  • 获取外部数据,例如每隔 15 分钟从 NOAA 提取天气报告。

  • 发送报告数据,例如通过电子邮件发送过去一周内超过特定金额的所有订单的摘要。

  • 处理数据,例如在每个工作日的非高峰时间压缩当日的已上传图像。

  • 清除数据,例如删除超过三个月的所有推文。

  • 存档数据,例如在未来 9 个月的每天凌晨 1:00 将发票推送到备份服务。

    在下一操作运行之前,还可以使用计划内置操作来暂停工作流,例如:

  • 等到工作日通过电子邮件发送状态更新。

  • 在恢复和检索结果前,延迟工作流直到 HTTP 调用有时间完成。

    本文介绍计划内置触发器和操作的功能。

    计划触发器

    可以使用 重复触发器 滑动窗口触发器 (不与任何特定服务或系统关联)来启动逻辑应用工作流。 这些触发器基于指定的重复周期来启动并运行工作流,你可以在该周期中选择时间间隔和频率(例如,秒数、分钟数、小时数、天数、周数或月数)。 你还可以设置开始日期和时间以及时区。 每当一个触发器激发时,Azure 逻辑应用服务将为你的逻辑应用创建并运行一个新的工作流实例。

    下面是这些触发器之间的差异:

  • 重复周期 :根据指定的计划按固定的时间间隔运行工作流。 如果触发器错过了定期触发(例如,由于中断或禁用工作流而错过),则定期触发器不会处理错过的定期触发,但会根据下一个计划的时间间隔重启定期触发。

    如果选择“天”作为频率,则可以指定该日期的小时,以及该小时的分钟,例如,每日 2:30。 如果选择“周”作为频率,则还可以选择星期几,例如“星期三”和“星期六”。 你还可以为定期计划指定开始日期和时间以及时区。 有关时区格式设置的详细信息,请参阅 添加重复触发器

    如果使用“天”、“周”或“月”频率并指定将来的日期和时间,请确保提前设置重复周期:

  • 天:至少提前 24 小时设置每日重复周期。

  • 周:至少提前 7 天设置每周重复周期。

  • 月:至少提前一个月设置每月重复周期。

    否则,工作流可能会跳过第一个重复周期。

    如果某个定期触发未指定具体的 开始日期和时间 ,则在保存或部署逻辑应用时,会立即运行第一次定期触发,而不管触发器的定期设置如何。 若要避免此行为,请提供你希望运行第一次定期触发的开始日期和时间。

    如果某个定期触发未指定任何其他高级计划选项(例如具体时间)来运行将来的定期触发,则这些将来的定期触发会以上一次运行时间为基础。 因此,这些定期触发的开始时间可能会因存储调用期间的延迟等因素而发生偏移。 为了确保工作流不会错过重复周期(特别是在频率为几天或更长时间一次的情况下),请尝试以下选项:

  • 提供定期触发的开始日期和时间,以及运行后续定期触发的具体时间,这可以通过“在这些小时”和“在这些分钟”属性来进行,仅适用于“天”和“周”频率。

  • 使用 滑动窗口触发器 ,而不是使用重复触发器。

    有关详细信息,请参阅 使用重复触发器创建、计划和运行重复性任务与工作流

  • 滑动窗口 :按定期时间间隔运行工作流来处理连续区块中的数据。 如果触发器错过了定期触发(例如,由于中断或禁用工作流而错过),则滑动窗口触发器会返回并处理错过的定期触发。

    可以指定开始日期和时间以及时区,并可以指定一个持续时间来延迟工作流中的每个重复周期。 此触发器不支持高级计划,例如,一天中的特定小时,一小时中的特定分钟,以及一星期中的特定几天。 有关详细信息,请参阅 使用滑动窗口触发器创建、计划和运行重复性任务与工作流

    在逻辑应用工作流中指定任何操作后,可以使用“延迟”和“延迟到”操作来使工作流等到下一个操作运行为止。

  • 延迟 :按指定的时间单位数(例如秒数、分钟数、小时数、天数、周数或月数)等待运行下一操作。 有关详细信息,请参阅 延迟工作流中的下一操作

  • 延迟截止时间 :在指定的日期和时间之前等待运行下一操作。 有关详细信息,请参阅 延迟工作流中的下一操作

    开始日期和时间的模式

    下面这些模式将演示如何使用开始日期和时间控制重复计划,以及 Azure 逻辑应用如何运行这些重复计划:

    不按计划循环 按计划重复(仅适用于重复触发器) 开始时间在过去 重复 触发器:基于指定的开始时间计算运行时间,并丢弃过去的运行时间。

    在下一个将来运行时间运行第一个工作负荷。

    基于上次运行时间运行将来的工作负荷。

    滑动窗口 触发器:基于指定的开始时间计算运行时间,并遵循过去的运行时间。

    基于指定的开始时间运行将来的工作负载。

    有关详细说明,请参阅此表格后面的示例。

    基于从开始时间计算的计划,在不早于开始时间的时间运行第一个工作负荷。

    基于指定的计划运行将来的工作负荷。

    注意: 如果针对计划指定了定期模式,但没有为该计划指定小时或分钟数,则 Azure 逻辑应用会分别使用小时或分钟来计算将来的运行时间(从首次运行时间算起)。

    开始时间在现在或将来 在指定的开始时间运行第一个工作负荷。

    重复触发器:基于上次运行时间运行将来的工作负载。

    滑动窗口触发器:基于指定的开始时间运行未来的工作负载。

    基于从开始时间计算的计划,在不早于开始时间的时间运行第一个工作负荷。

    基于指定的计划运行将来的工作负荷。 如果使用“天”、“周”或“月”频率并指定将来的日期和时间,请确保提前设置重复周期:

    - 天 :至少提前 24 小时设置每日重复周期。

    - 周 :至少提前 7 天设置每周重复周期。

    - :至少提前一个月设置内每月重复周期。

    否则,工作流可能会跳过第一个重复周期。

    注意: 如果针对计划指定了定期模式,但没有为该计划指定小时或分钟数,则 Azure 逻辑应用会分别使用小时或分钟来计算将来的运行时间(从首次运行时间算起)。

    指定了过去开始时间和重复周期但未指定计划的示例

    假设当前日期和时间是 2017 年 9 月 8 日下午 1:00。 将开始日期和时间指定为已过去的 2017 年 9 月 7 日下午 2:00,重复周期为每隔两天运行一次。

    2017-09- 07 T14:00:00Z
    (2017-09- 07 下午 2:00) 2017-09- 08 T13:00:00Z
    (2017-09- 08 下午 1:00)

    对于重复周期触发器,Azure 逻辑应用引擎会基于开始时间计算运行时间,丢弃过去的运行时间,为首次运行使用下一个将来开始时间,并基于上次运行时间计算将来的运行。

    下面是此重复周期的大致形式:

    首次运行时间 将来的运行时间

    因此,不管在过去的多长期限内指定了开始时间(例如,2017-09- 05 下午 2:00,或 2017-09- 01 下午 2:00),首次运行始终使用下一个将来的开始时间。

    对于滑动窗口触发器,逻辑应用引擎会基于开始时间计算运行时间,遵循过去的运行时间,为首次运行使用该开始时间,并基于该开始时间计算将来的运行。

    下面是此重复周期的大致形式:

    首次运行时间 将来的运行时间

    因此,不管在过去的多长期限内指定了开始时间(例如,2017-09- 05 下午 2:00,或 2017-09- 01 下午 2:00),首次运行始终使用指定的开始时间。

    定期触发行为

    定期内置触发器(例如 定期触发器 )在 Azure 逻辑应用运行时上本机运行。 这些触发器不同于需要先创建连接的基于连接的定期托管连接器触发器,例如 Office 365 Outlook 托管连接器触发器。

    对于这两种类型的触发器,如果定期触发未指定具体的开始日期和时间,则在保存或部署逻辑应用资源时,会立即运行第一次定期触发,而不管触发器的定期设置如何。 若要避免此行为,请提供你希望运行第一次定期触发的开始日期和时间。

    内置触发器的定期触发

    定期内置触发器遵循所设置的计划,包括指定的任何时区。 但如果某个定期触发未指定任何其他高级计划选项(例如具体时间)来运行将来的定期触发,则将来的定期触发会遵照上一次的触发器执行。 因此,这些定期触发的开始时间可能会因存储调用期间的延迟等因素而发生偏移。

    有关详细信息,请查看以下文档:

  • 触发夏令时和标准时间的定期执行
  • 排查定期触发问题
  • 基于连接的触发器的定期触发

    对于基于连接的定期触发器(如 Office 365 Outlook),计划不是控制执行的唯一驱动因素。 时区只能确定最初开始时间。 后续运行取决于定期计划、上一次触发器执行以及其他可能导致运行时间发生偏差或产生意外行为的因素,例如:

  • 触发器是否访问具有更多数据的服务器(触发器会立即尝试获取这些数据)。
  • 触发器引发的任何故障或重试。
  • 调用存储期间的延迟。
  • 夏令时 (DST) 开始和结束时,未维护指定的计划。
  • 可能影响下次运行时的出现时间的其他因素。
  • 有关详细信息,请查看以下文档:

  • 触发夏令时和标准时间的定期执行
  • 在夏令时和标准时间触发定期移动和偏移
  • 排查定期触发问题
  • 触发夏令时和标准时间的定期执行

    计划作业时,Azure 逻辑应用会将要处理的消息放入队列中,并指定该消息何时变得可用,具体取决于运行上次作业的 UTC 时间和计划运行下次作业的 UTC 时间。 如果为重复周期指定了开始时间,请确保选择时区,以便逻辑应用工作流在指定的开始时间运行。 指定时区后,逻辑应用的 UTC 时间也会有所调整。应对季节性时间变化。 定期触发器遵循你设置的计划,包括你指定的任何时区。

    如果未选择时区,夏令时 (DST) 事件可能会影响触发器何时运行。 例如,开始时间将在 DST 开始时向前移动 1 小时,在 DST 结束时向后移动 1 小时。

    在夏令时和标准时间触发定期移动和偏移

    对于基于连接的定期触发器,定期计划并不是控制执行的唯一驱动因素。 时区只能确定最初开始时间。 后续运行取决于定期计划、上一次触发器执行以及其他可能导致运行时间发生偏差或产生意外行为的因素,例如:

  • 在夏令时 (DST) 开始和结束时未能维护指定的计划。
  • 可能影响下次运行时的出现时间的其他因素。
  • 调用存储期间的延迟。
  • 触发器是否访问具有更多数据的服务器(触发器会立即尝试获取这些数据)。
  • 触发器引发的任何故障或重试。
  • 若要确保重复周期时间在 DST 生效时不会变化,请手动调整重复周期。 这样,你的工作流就会继续按预期的或指定的开始时间运行。 否则,开始时间将在 DST 开始时向前移动 1 小时,在 DST 结束时向后移动 1 小时。

    在凌晨 2:00 - 凌晨 3:00 之间开始的触发器可能会出现问题,因为 DST 更改在凌晨 2:00 发生,这可能会导致开始时间无效或不明确。 如果在同一不明确间隔内有多个逻辑应用,可能会出现重叠。 出于此原因,可能需要避免开始时间在凌晨 2:00 - 凌晨 3:00 之间。

    例如,假设你有两个每日运行的逻辑应用。 一个逻辑应用在本地时间凌晨 1:30 运行,另一个在一小时后于本地时间凌晨 2:30 运行。 DST 开始和结束时,这些应用的开始时间会发生什么变化?

  • 时间向前移动一小时时,触发器是否会全部运行?

  • 时间向后移动一小时时,触发器是否会运行两次?

    如果这些逻辑应用使用 UTC-6:00 中部时间(美国和加拿大)区域,则此模拟将显示 2019 UTC 时间随 DST 的更改而变动的情况,即在必要时向前或向后移动一小时,以便应用仍以预期的本地时间运行,而不会跳过或重复运行。

  • 2019/03/10:DST 开始于凌晨 2:00,将时间向前移动一小时

    为了在 DST 开始后进行补偿,UTC 时间将向后移动一个小时,以便逻辑应用仍以同一本地时间运行:

  • 逻辑应用 #1

    时间(本地) 时间(UTC) 凌晨 3:30:00* 凌晨 8:30:00 DST 已生效,因此本地时间向前移动一小时,因为 UTC-6:00 时区更改为了 UTC-5:00。 有关详细信息,请参阅 在凌晨 2:00 - 凌晨 3:00 之间开始的触发器 。 2019/03/11 凌晨 2:30:00 凌晨 7:30:00 在 DST 生效后,UTC 将向后移动一小时。

    为了确保工作流在你指定的开始时间运行并且不会错过定期触发(特别是在频率为几天或更长时间一次的情况下),请尝试以下解决方案:

  • DST 生效时,请手动调整重复周期,使工作流继续按预期时间运行。 否则,开始时间将在 DST 开始时向前移动 1 小时,在 DST 结束时向后移动 1 小时。 有关详细信息和示例,请查看 夏令时和标准时间重复

  • 若要使用“定期”触发器,请指定时区、开始日期和时间。 此外,还应在属性“在这些小时”和“在这些分钟”中(仅适用于“天”和“周”频率)指定运行后续定期触发的具体时间 。 但是,当时间发生调整时,有时 Windows 可能仍会导致问题。

  • 请考虑使用 滑动窗口触发器 而不是定期触发器,以避免错过定期触发 。

    仅运行一次

    如果你将来只想运行逻辑应用一次,可以使用“计划程序:运行一次作业”模板。 创建新的逻辑应用后但在打开工作流设计器之前,请从“模板”部分下的“类别”列表中选择“计划”,然后选择以下模板:

    或者,可以使用“收到 HTTP 请求时 - 请求”触发器启动逻辑应用,并将开始时间作为触发器的参数传递。 对于第一个操作,请使用“延迟截止时间 - 计划”操作,并提供开始运行下一操作的时间。

    每月的最后一天运行一次

    若要在每月的最后一天运行一次定期触发器,必须使用代码视图(而不是设计器)在工作流的基础 JSON 定义中编辑触发器。 但是,可以使用以下示例:

    "triggers": {
        "Recurrence": {
            "recurrence": {
                "frequency": "Month",
                "interval": 1,
                "schedule": {
                    "monthDays": [-1]
            "type": "Recurrence"
    

    示例重复周期

    下面是可为支持上述选项的触发器设置的各种示例重复周期:

    在这些日期 在这些小时 在这些分钟 此计划不会在指定的开始日期和时间之前启动。 将来的重复计划每隔一小时从“00”分钟标记开始运行,这是 Azure 逻辑应用基于开始时间计算的结果。

    如果频率为“周”或“月”,则此计划只会分别在每周的一个星期日期或每月的一个日期运行。

    重复
    滑动窗口 每天每隔一小时运行(没有开始日期和时间) {不可用} 此计划立即启动,并根据上次运行时间计算将来的重复周期。

    如果频率为“周”或“月”,则此计划只会分别在每周的一个星期日期或每月的一个日期运行。

    重复
    滑动窗口 每天每隔一小时运行(有开始日期和时间) startDateTstartTimeZ {不可用} 此计划不会在指定的开始日期和时间之前启动,将根据上次运行时间计算将来的重复周期。

    如果频率为“周”或“月”,则此计划只会分别在每周的一个星期日期或每月的一个日期运行。

    重复
    滑动窗口 每隔一小时在整点过后的第 15 分钟运行(有开始日期和时间) startDateT00:15:00Z {不可用} 此计划不会在指定的开始日期和时间之前启动。 将来的重复计划按“15”分钟标记(逻辑应用基于开始时间计算的)运行,即凌晨 00:15、1:15、2:15 等。 每隔一小时在整点过后的第 15 分钟运行(没有开始日期和时间) {不可用} 0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23 此计划在 00:15 AM、1:15 AM、2:15 AM 等有规律的时间运行。 此外,此计划相当于频率为“小时”且开始时间为“15”分钟。 每隔 15 分钟在指定的分钟数(无开始日期和时间)运行。 {不可用} 0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23 0、15、30、45 此计划在下一个指定的 15 分钟标记之前不会启动。 每天上午 8 点加上保存逻辑应用时的分钟标记运行 {不可用} 如果没有开始日期和时间,此计划将基于你保存逻辑应用(PUT 操作)的时间运行。 每天上午 8:00 运行(有开始日期和时间) startDateT08:00:00Z {不可用} 此计划不会在指定的开始日期和时间之前启动。 将来每天上午 8:00 运行。 每日上午 8:00 运行(无开始日期和时间) {不可用} 此计划每天上午 8:00 运行。 每天上午 8:00 和下午 4:00 运行 {不可用} 8, 16 每天上午 8:30、上午 8:45、下午 4:30 和下午 4:45 运行 {不可用} 8, 16 30, 45 在每个星期六下午 5:00 运行(没有开始日期和时间) “星期六” 此计划在每个星期六的 5:00 PM 运行。 在每个星期六下午 5:00 运行(有开始日期和时间) startDateT17:00:00Z “星期六” 此计划不会在指定的开始日期和时间(在本例中为 2017 年 9 月 9 日 5:00 PM)之前启动。 将来的定期计划在每个星期六的 5:00 PM 运行。 每周二、周四下午 5 点加上保存逻辑应用时的分钟标记运行 “星期二”、“星期四” 在工作时间每隔一小时运行。 选择除星期六和星期日以外的所有星期日期。 选择所需的日期小时。 选择所需的任何小时分钟。 例如,如果工作时间为上午 8:00 到下午 5:00,则选择“8、9、10、11、12、13、14、15、16、17”作为该天中的小时,并加上“0”作为该小时的分钟。 在周末每隔一个星期日期运行一次 “星期六”、“星期日” 选择所需的日期小时。 选择适当的任何小时分钟。 此计划根据指定的计划在每个星期六和星期日运行。 仅每两周在星期一每隔 15 分钟运行 “星期一” 0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23 0、15、30、45 此计划按每个 15 分钟标记每隔两周在星期一运行。 startDateTstartTimeZ {不可用} {不可用} {不可用} 此计划不会在指定的开始日期和时间之前启动,将基于开始日期和时间计算将来的重复周期。 如果未指定开始日期和时间,则此计划使用创建日期和时间。 在每个月每隔一小时运行一天 {参阅备注} {不可用} 0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23 {参阅备注} 如果未指定开始日期和时间,则此计划使用创建日期和时间。 若要控制定期计划的分钟,请指定小时分钟和开始时间,或使用创建时间。 例如,如果开始时间或创建时间为 8:25 AM,则此计划在 8:25 AM、9:25 AM、10:25 AM 等有规律的时间运行。
  • 使用“定期”触发器创建、计划和运行重复任务和工作流
  • 使用滑动窗口触发器创建、计划和运行重复性任务与工作流
  • 使用延迟操作暂停工作流
  •