策略控制

触发器

触发器操作

1. 添加

a.  s1保存webUI请求添加触发器数据，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的添加触发器命令通知；
c.  task根据触发器类型（条件或时间）发送job任务给lts，任务类型等于添加；

2. 修改

a.  s1保存webUI请求修改触发器数据，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的修改触发器命令通知；
c.  task根据触发器类型（条件或时间）发送job任务给lts，任务类型等于更新；   

3. 删除

a.  s1接收到webUI请求删除触发器，执行更新触发器删除标识，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的删除触发器命令通知；
c.  task根据触发器类型（条件或时间）发送job任务给lts，任务类型等于删除；
d.  task删除数据库中的触发器数据；

4. 使能开启

a.  s1接收到webUI请求触发器使能开启命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的使能开启触发器命令通知；
c.  task根据触发器类型（条件或时间）发送job任务给lts，任务类型等于添加；
d.  task更新触发器使能开启和触发器操作记录结果；

5. 使能关闭

a.  s1接收到webUI请求触发器使能关闭命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的使能关闭触发器命令通知；
c.  根据触发器类型（条件或时间）发送job任务给lts，任务类型等于删除；
d.  更新触发器使能开启和触发器操作记录结果；

触发器触发

1. 时间类型

a.  lts-tasktracker每隔1秒发送请求给lts-jobtracker获取任务；
b.  lts-jobtracker接收到获取任务请求，执行查找job执行时间小于当前时间的数据，返回给lts-tasktracker;
c.  lts-jobtracker 接收的任务交给task处理；

2. 条件类型

a.  lts-jobtracker 把条件数据加载到内存中；
b.  lts-jobtracker 订阅传感器实时数据（iot通过RMQ通知实时数据）；
c.  lts-jobtracker 接收到实时数据时，判断对应传感器是否满足触发条件；
d.  接收实时数据时条件检查，如果是普通条件（数值高于x，数值低于x，开关开启，开关关闭，数据在x1与x2之间，数据小于x1或大于x2，传感器断开）满足，则检查这个条件对应任务的其他条件是否满足，计算出job对应的所有条件结果等于true，则推送任务给lts-tasktracker;
e.  接收实时数据时条件检查，如果是时间条件类型（超过X值M分钟，小于X值超过M分钟，等于X值超过M分钟）满足，则开始执行计时；
f.  lts-jobtracker每隔30秒检查条件情况，条件满足，则检查这个条件对应job的其他条件是否满足，计算出job的所有条件结果等于true，则推送任务给lts-tasktracker;
g.  job接收到处理完成的反馈后，修改job的所有条件为待复位状态；

触发器执行

1. 传感器控制类型

a.  task接收lts-tasktracker转给的job,判断执行触发器动作等于传感器控制类型；
b.  插入触发器记录并通知UI触发器状态为触发中；
c.  发送传感器控制命令给iot;
d.  更新触发器状态，更新触发记录结果，并通知UI触发器状态；

2. 告警类型

a.  task接收lts-tasktracker转给的job,判断执行触发器动作等于告警类型；
b.  插入触发器记录并通知UI触发器状态为触发中；
c.  插入告警消息并发送告警消息给UI；
d.  更新触发器状态，更新触发记录结果，并通知UI触发器状态；

3. 短信类型

a.  task接收lts-tasktracker转给的job,判断执行触发器动作等于短信类型；
b.  插入触发器记录并通知UI触发器状态为触发中；
c.  插入短信消息并调用阿里接口发送短信给用户；
d.  更新触发器状态，更新触发记录结果，并通知UI触发器状态；

4. 短信和告警类型

a.  task接收lts-tasktracker转给的job,判断执行触发器动作等于短信和告警类型；
b.  插入触发器记录并通知UI触发器状态为触发中；
c.  插入告警消息并发送告警消息给UI；
d.  插入短信消息并调用阿里接口发送短信给用户；
e.  更新触发器状态，更新触发记录结果，并通知UI触发器状态；

流程控制：

流程控制操作

1. 添加

a.  s1保存webUI请求添加流程控制数据，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的添加流程控制命令通知；
c.  task发送定时job任务到lts，任务类型等于添加；

2. 修改

a.  s1保存webUI请求添加流程控制数据，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的添加流程控制命令通知；
c.  task发送定时job任务到lts，任务类型等于更新；

3. 删除

a.  s1接收到webUI请求删除流程控制，执行更新流程控制删除标识，再通过RMQ通知task;
b.  task从RMQ中接收s1发送的删除流程控制命令通知；
c.  task发送及时job任务到lts，任务类型等于删除；
d.  task删除数据库中的流程控制相关数据；

4. 使能开启

a.  s1接收到webUI请求流程控制使能开启命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的使能开启流程控制命令通知；
c.  task发送定时job任务到lts，任务类型等于添加；
d.  task更新流程控制使能开启和流程控制操作记录结果；
e.  通知UI命令执行成功；

5. 使能关闭

a.  s1接收到webUI请求流程控制使能关闭命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的使能关闭流程控制命令通知；
c.  task发送及时job任务到lts，任务类型等于删除；
d.  删除流程执行记录；
e.  更新流程控制使能开启和流程控制操作记录结果；
f.  通知UI命令执行成功；   

6. 暂停

a.  s1接收到webUI请求流程控制暂停命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的暂停流程控制命令通知；
c.  task通知正在执行的流程，执行暂停；
d.  关闭当前执行的动作，有关键节点，先关闭关键节点；
e.  更新执行记录，流程控制和当前执行动作组状态等于暂停；
f.  发送及时任务到lts,任务类型删除；
g.  更新流程控制操作记录结果；
h.  通知UI命令执行成功；

7. 继续

a.  s1接收到webUI请求流程控制继续命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的继续流程控制命令通知；
c.  发送及时任务到lts,任务类型添加；
d.  更新执行记录，流程控制和当前执行动作组状态等于执行中；
e.  更新流程控制操作记录结果；
f.  通知UI命令执行成功；

8. 恢复

a.  s1接收到webUI请求流程控制继续命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的继续流程控制命令通知；
c.  删除流程原来的job信息；
d.  发送新及时job到lts,任务类型添加；
e.  更新执行记录，流程控制和当前执行动作组状态等于执行中；
f.  更新流程控制操作记录结果；
g.  通知UI命令执行成功；   

9. 停止

a.  s1接收到webUI请求流程控制停止命令，通过RMQ通知task;
b.  task从RMQ中接收s1发送的停止流程控制命令通知；
c.  task通知正在执行的流程，执行停止；
d.  删除流程对应job   信息；
e.  关闭当前执行的动作，有关键节点，先关闭关键节点；
f.  更新执行记录，流程控制和当前执行动作组状态等于停止；
g.  更新流程控制操作记录结果；
h.  通知UI命令执行成功；   

流程控制触发

a.  lts-tasktracker每隔1秒发送请求给lts-jobtracker获取任务；
b.  lts-jobtracker接收到获取任务请求，执行查找执行时间小于当前时间的数据，返回给lts-tasktracker;
c.  lts-jobtracker 接收的任务转给task处理；

流程控制执行

1. 流程正常执行

a.  task接收lts-tasktracker转给的job,判断执行等于流程控制正常执行类型；
b.  注册为流程观察者，当流程执行暂停，停止时会被通知；
c.  task判断执行流程的动作组是不是第一组；如果执行动作组是第一组，则执行d：
d.  执行插入流程执行记录和更新流程控制状态为执行中；
e.  通知UI流程控制状态；
f.  发送动作组执行命令给iot执行；
g.  判断动作组是否执行成功（只要执行命令失败数量小于执行命令数量，就是成功的，如果失败，则停止执行后续步骤，更新流程状态为失败，并通知UI；如果是成功，但是有失败的，则通知UI）
h.  判断是否有关键节点，有，则发送关键节点执行命令给iot;
i.  判断关键节点是执行失败，如果失败，则停止后续步骤，更新流程状态为失败，并通知UI；
j.  动作组和关键节点执行成功后，生成关闭执行动作的job发送给lts,job执行时间等于执行动作执行完成以后；
k.  如果c判断出执行动作不是第一组，则不是执行h，但是在执行f之前，会检查是否有关键节点，并且关键节点是否打开，如果有关键节点，并且未打开，则不会执行f，直接修改流程状态为失败；
注意：在执行每个步骤之前会检查是否接受到暂停，停止的通知，如果被告知流程已经暂停或停止，则不会执行后续步骤；

2. 流程动作结束执行

a.  task接收lts-tasktracker转给的job,判断执行等于流程控制结束执行类型；
b.  task判断执行流程的动作组是不是最后一组；如果执行动作组是最后一组，则执行c：
c.  判断是否有关键节点，有关键节点，则关闭关键节点；
e.  如果b判断结果不是最后一组，则执行f；
f.  发送关闭动作组命令给iot;
g.  检查关闭动作组命令是否执行成功（所有命令都执行成功），则继续执行后续步骤，如果执行失败，则修改流程状态为失败，停止执行后续步骤；
h.  通知UI流程执行进度；
i.  生成下次执行job发送给lts,生成job时会判断是不是最后一组，如果是最后一组，则先更新流程状态为执行完成，再生成的是下一个子流程执行的job，如果不是最后一组，则生成的是下一个动作组执行的job;

3. 流程动作继续执行

a.  task接收lts-tasktracker转给的job,判断是不是流程控制继续执行类型；
b.  注册为流程观察者，当流程执行暂停，停止时会被通知；
c.  task判断执行流程的动作组是不是第一组；如果执行动作组是第一组，则执行插入流程执行记录和更新流程控制状态为执行中;    
d.  通知UI流程控制状态；
e.  发送动作组执行命令给iot执行；
f.  判断动作组是否执行成功（只要执行命令失败数量小于执行命令数量，就是成功的，如果失败，则停止执行后续步骤，更新流程状态为失败，并通知UI；如果是成功，但是有失败的，则通知UI）
h.  判断是否有关键节点，有，则发送关键节点执行命令给iot,如果无关键节点，则跳过g，执行i;
g.  判断关键节点是执行失败，如果失败，则停止后续步骤，更新流程状态为失败，并通知UI；
i.  如果动作组和关键节点都执行成功后，则生成关闭动作组job发送给lts;

4. 流程恢复执行

a.  task接收lts-tasktracker转的job,判断是不是流程控制继续执行类型；
b.  注册为流程观察者，当流程执行暂停，停止时会被通知；
c.  判断流程失败类型：
d.  如果失败类型等于执行动作失败，则
d1. 判断动作组是不是第一组，是第一组，则插入流程执行记录和更新流程状态为执行中；
d2. 通知UI流程控制状态；
d3. 发送动作组执行命令给iot；
d4. 判断动作组是否执行成功（只要执行命令失败数量小于执行命令数量，就是成功的，如果失败，则停止执行后续步骤，更新流程状态为失败，并通知UI；如果是成功，但是有失败的，则通知UI）
d5. 判断是否有关键节点，有，则发送关键节点执行命令给iot，如果无关键节点，则跳过d6,执行d7;
d6. 判断关键节点是执行失败，如果失败，则停止后续步骤，更新流程状态为失败，并通知UI；
d7. 动作组和关键节点执行成功后，生成关闭执行动作的job发送给lts,job执行时间等于执行动作执行完成以后；
e.  如果c的失败类型等于关闭动作失败，则：
e1. 发送关闭动作命令给iot;
e2. 检查关闭命令是否执行成功，成功则继续执行，否则为停止后续步骤；
e3. 判断动作组是不是最后一组，如果是最后一组，则生成下个子流程的job发送给lts;
e4. 如果e3不是最后一组，则，判断是否有关键节点，有关键节点，则打开关键节点，再生成下一个动作组job发送给lts，无关键节点，则直接生成下一个动作组job发送给lts;
f.  如果c的失败类型等于打开关键节点失败，则执行 d1,d2,d3,d4,d5,d6,d7步骤；
g.  如果c的失败类型等于关闭关键节点失败，，则：
g1. 执行关闭关键节点命令，
g2. 更新流程执行状态为执行完成，并通知UI；
g3. 判断是否有下一个子流程，有子流程，则生成下个子流程的执行job发送给lts；
h.  如果c的失败类型等于关键节点未打开，则执行 d1,d2,d3,d4,d5,d6,d7步骤；