之前在论坛中有查看到帖子  http://www.taskctl.com/forum/detail_103.html，

        http://www.taskctl.com/forum/detail_137.html 中均只提到了事件可以用来解决跨流程依赖但是却没有详细描述这两个配套的作业类型该如何使用以及注意事项。

        在这里我先汇总一下taskctl中有哪些是用来解决作业间依赖的，

            1、同一流程中作业的串并关系，串行的作业间就已经体现了依赖，因为流程正常模式启动后总是从开始节点向结束节点方向运行，串行的作业有已经存在先后或者依赖了，这也是taskctl最最基础的点。

            2、同一流程中，强制依赖 lean 。这个属性用于在串并时可以绘图比较复杂时使用，是调度依赖体系的一个补充 https://mp.weixin.qq.com/s/KTar-0wDsfNIGCs7zZq6Ow 

            3、同一调度服务器上，不同流程中的跨流程依赖，这个时候有几种方式可选，我这里就接受两种比较常见的，其实逻辑上都是一致，在一个作业A运行完成后做某一个动作T，在另一边依赖这个A的B作业前新增一个判断T这个动作的作业N，这个动作可以是由操作系统和调度同时完成的；也可以仅仅是在调度中本身完成的，发送事件和接受事件就是调度中本身完成的实现。

                方法a : 在作业A后，调用操作系统可执行程序如 touch 命令创建标志文件的作业T，标志文件最好带有变量等时间戳，然后在B作业前新增判断文件是否存在的作业N。

流程一中大概是这样

     <XXX>
        <name>A</name>
        <progname>XXX</progname>
      </XXX>
      <exe>
        <name>touch_flag1</name>
        <jobdesc>创建标志文件</jobdesc>
        <progname>touch</progname>
        <para>$TASKCTLDIR/tmp/xxxx_$(data).flag</para>  ----路径是情况，主要和判断时一致
      </exe>

      <filewatch>
        <name>check_flag</name>
        <para>$TASKCTLDIR/tmp/xxxx_$(data).flag</para>
        <jobdesc>标志文件是否存在判断</jobdesc>
      </filewatch>
      <XXX>
        <name>B</name>
        <progname>XXX</progname>
      </XXX>

                 方法b : 在作业A后，执行调度自带作业类型发送事件作业，事件名称最好带有变量等时间戳，然后在B作业前新增接受事件作业，检测是否对应事件。

流程一中大概是这样

     <XXX>
        <name>A</name>
        <progname>XXX</progname>
      </XXX>
     <sendevent>
       <name>sendevent</name>
       <para>enentbufflow_$(data)</para> 
     </sendevent>

      <recvevent>
          <name>recvevent1</name>
          <para>enentbufflow_$(data)</para> -- 要能正确接受到需和发送的事件一致，如果带有变量需留意两个流程中变量是否一致
          <jobdesc>自定义事件接收节点组件</jobdesc>
      </recvevent>
      <XXX>
        <name>B</name>
        <progname>XXX</progname>
      </XXX>

        可以看到上述两种方法使用逻辑均是一致的，都是在不改造自身业务逻辑和程序的情况下，在调度中新增两个作业，而不是在A/B作业上新增更多属性来表达跨流程依赖(有的用户觉得那样可能更好但是没有更加深入分析，如果用属性那么两个流程的耦合性就变得很高，当只想调试一边或者频率不太一致时，或者流程谁先随后执行到A/B作业时调度都有可能存在很多问题）。

        当然上述各有优缺点，方法a 开始时比较容易理解，也方便查询，因为可以看到文件，但需要由用户自己维护标志文件所在目录权限及文件的读写清除等，而且启动调度服务端都不会影响，可以创建一次，多个地方检测文件是否存在；在多次创建和多次检测同一文件是否存在这种情况，检测了存在还可能需要主动清除，不然判断不准确

        方法b开始比较难理解， 不要用户操心事件的权限、存放、清除等只要事件名称匹配且一致，同样可以是单发送多接受，但是同一事件同一次发送，只能被同一接受作业接受一次；当多次发送同一事件时，而没有任何作业接受也至多存在一次，这个地方比较复杂，需要用户自己多多体验。同时因为是存在消息队列中，对用户不可见，不能查询到当前调度中已经发送了那些作业，重启调度服务有影响、会清除这些消息队列 。

        4、不在同一个调度服务器上，或者说依赖的部分不是由调度完成，而是外围完成，完成后希望触发调度后续流程。就是 http://www.taskctl.com/forum/detail_103.html