AppMaster应用程序后台的任务调度器，如同后台的经典案例一样，创造了重复的场景。例如，当你需要在一个时间表上做一个特定的动作。这种任务的经典案例是清理服务器上的临时文件、每周备份、根据给定的算法生成报告等。
让我们考虑一个在AppMaster应用程序后台使用任务调度器的例子。假设你想建立一个进程，每天早上9点向用户发送天气信息到他的手机号码。
因此，该任务被分为几个逻辑阶段。
- 安装和配置发送手机信息的模块
- 创建和配置一个外部请求API进程
- 在应用程序后端设置一个调度器
1.安装和配置发送移动信息的模块。Nexmo模块允许你在AppMaster应用程序中整合向选定号码发送短信的能力。
- API密钥- 可以在你的Nexmo账户中获得的API密钥（https://dashboard.nexmo.com/settings）。
- API Secret- 与API密钥一起使用的私人密钥，用于识别用户。你也可以在你的Nexmo账户中得到它（https://dashboard.nexmo.com/settings）。
- 来自号码- 在你的Nexmo账户中注册时指定的号码。
以下业务流程会随着模块的安装自动安装。
- Nexmo.Send SMS- 允许你通过Nexmo模块向指定号码发送信息。
Nexmo.Send SMS - 允许你通过Nexmo模块向指定的号码发送信息。
- Phone [电话] - 将要发送信息的电话号码。
- 内容[字符串] - 文本信息。
2.免费的OpenWeather API网络资源将被用作天气数据源（https://openweathermap.org/api）。第一步是创建一个外部请求API模板。API请求模板呈现在外部API请求标签的业务流程部分。要创建一个新的模板，点击创建API请求。
请求类型。GET
请求地址: https://api.openweathermap.org/data/2.5/weather
查询参数。
- Lat [字符串] - 纬度
- Lon [字符串] - 经度
- Appid [字符串] - OpenWeather API密钥
作为这项任务的一部分，我们只对响应主体中的几个字段感兴趣（https://openweathermap.org/api/one-call-3）。
- Temp [float] - 温度
- Temp_min [float] - 最小温度
- Temp_max [float] - 最大温度
- Pressure [float] - 压力
- Humidity [float] - 湿度
3.在设置任务调度器之前，你需要创建一个业务流程，它将通过API接收天气信息。该业务流程看起来如下。
- 制作天气查询模型 - 创建一个虚拟的请求参数模型。Lon, lat - 所需地点的坐标，appid - OpenWeather服务的API密钥。
- API请求。Weather - 负责与OpenWeather API交互的业务流程
- 扩展天气。Body Model Out - 为了部署Body响应模型而需要的。
- 扩展天气。Body Model Out_main - 扩展请求-响应Body的主体模型，以便获得温度（temp）。
- To String - 将temp字段的值转换为字符串类型。
- Nexmo:发送短信--向指定的电话号码（Phone）发送一条含有温度（Content）信息的信息。
在 "日程安排 "标签的业务流程部分设置一个日程安排程序。
计划表选项卡中的调度器设置因其类型不同而不同。
让我们来详细考虑一下它们中的每一个
1.每日 - 允许配置每日时间表
- 时间 - 定义调度器启动所选BP的UTC+0的时间。
- 一周的天数 - 定义调度器一周工作的天数。
- 自动启动 - 如果设置为 "真"，如果前一个BP没有完成，新的BP将不会启动。默认值。False（假）。
- 自动重试 - 如果进程被中断/没有成功启动，则自动重新启动。
重试失败的项目处理 - 重新启动进程的尝试次数。
每次重试前的等待 - 每次拍摄前的延迟时间，以重新启动进程。
- 强制退出 - 如果在几秒钟内没有完成，就强制终止进程。默认情况下为真。完成前的秒数为3秒，默认为3秒。
2.月度 - 月度计划表
- 时间 - 定义调度器启动所选BP的UTC+0的时间。
- 一周的天数 - 由两个设置组成。
重复频率。
- 每第一次
- 每二天
- 每三个
- 每四次
- 这一天
星期--定义一周中的一天
- 月 - 确定月份
- 自动启动 - 如果设置为 "真"，新的PSU将不会被启动，除非很快完成。默认值。False（假）。
- 自动重试 - 如果进程被中断/未启动，则自动重启该进程
重试处理失败的项目 - 进程重新启动的次数。
每次重试前的等待 - 每次尝试重新启动进程前的延迟时间。
- 强制退出 - 如果一个进程在几秒钟内没有完成，则终止该进程。默认情况下为真。完成前的秒数为3秒，默认为3秒。
3.Periodically - 允许你灵活地配置调度器的频率
- 每一次--能够设置每N秒/分钟/小时/天的重复性。默认：每1小时一次。
- 自动启动 - 如果设置为True，如果前一个BP没有完成，新的BP将不会启动。默认值。假的。
- 自动重试--如果进程被中断/没有成功启动，则自动重启该进程
重试失败的项目处理 - 重新启动进程的尝试次数。
每次重试前的等待 - 每次尝试重启进程前的延迟时间。
- 强制退出 - 如果在几秒钟内没有完成，就强制终止进程。默认情况下为真。完成前的秒数为3秒，默认为3秒。
4.启动应用程序后--单次任务计划器
- Delay - 定义了应用程序启动和启动之间的延迟。默认情况下 - 0秒
- 自动重试--如果进程被中断/没有成功启动，则自动重启该进程
重试失败的项目处理 - 重新启动进程的尝试次数。
每次重试前的等待 - 每次尝试重启进程前的延迟时间。
- 强制退出 - 如果在几秒钟内没有完成，就强制终止进程。默认情况下为真。完成前的秒数为3秒，默认为3秒。
5.在完成应用之前--每次应用结束时运行调度器
- 自动重试--如果进程被中断/没有成功启动，则自动重启该进程
重试失败的项目处理 - 重新启动进程的尝试次数。
每次重试前的等待 - 每次尝试重启进程前的延迟时间。
- 强制退出 - 如果在几秒钟内没有完成，则强制终止该进程。默认情况下为真。完成前的秒数，默认为3秒。
在调度器设置的Params选项卡中，当BP被调度器启动时，也可以向BP输入传递参数。
在我们的例子中，调度器的设置是这样的。
- 消息将在每天上午9点（UTC+0）发送
- 如果进程没有立即启动，自动尝试重启进程3次，两次尝试之间有10分钟的延迟。
- 如果一个进程在三秒钟内没有完成，则强行终止该进程。
我们的应用程序生活和工作在后台，所以为了让它工作，只要发布它就可以了。
