XXL-JOB真的要凉了？出现了一个王炸级别的分布式任务调度与计算框架？( 六 ) _XXL-JOB

导入任务节点任务为之前创建的任务，可用工作流形式串联起来执行。

文章插图
编辑节点信息点击需要编辑的节点，在右侧会弹出一个编辑框，如下图所示

文章插图

任务名称：当前节点引用的任务名称，点击可编辑（支持输入名称进行模糊搜索）
节点名称：节点的名称，无实际业务用途，在能明确表示节点背后的业务逻辑的情况下请尽量精简字段
节点参数：节点的参数配置，当这个信息不为空的时候使用这个参数覆盖当前节点所引用的任务所配置的参数信息
是否启用：未启用的节点将会直接跳过
失败跳过：当这个节点执行失败的时候不会打断整个工作流的执行

特殊节点说明判断节点

文章插图
判断节点不允许失败跳过以及禁用，节点参数中存储的是 Groovy 代码（执行 Groovy 代码时会将当前工作流上下文作为 context 变量注入到代码执行的上下文中），其执行结果仅能返回 "true" 或者 "false"，同时判断节点仅有且必须有两条“输出”路径。会根据该代码的执行结果决定下游需要执行的节点。这里处理的原则是，仅 cancel 那些只能通过被 disable 掉的边可达的节点
举个两个栗子，灰色代表相应的边或者节点被 disable 或 cancel，菱形代表判断节点，假定执行结果为 true

文章插图
case 3 以及 case 4 中的节点 3 都会被 cancel，因为它只能通过节点 1 -> 节点 3 的边可达（该边的属性为 false），但对于节点 5 而言，在 case 4 中因为判断节点 2 的执行结果为 true ，那么其可以通过节点 2 -> 节点 5 的边可达，所以不会被 disable。
备注：如果需要根据上游节点的执行结果决定下游节点，可以将上游节点的执行结果注入上下文中，再在判断节点中做相应的判断。
工作流嵌套节点

文章插图
该节点代表对某个工作流的引用，节点的 jobId 属性存储的是工作流 id ，其他属性和普通的任务节点一致。不允许出现循环引用以及多级嵌套的情况，即嵌套节点中指向的工作流一定是一个不含嵌套节点的工作流。
执行到该节点时，如果该节点处于启用状态，那么将启动该节点所引用工作流的一个新实例，待该实例执行完成后再同步更新该节点的状态。
注意，创建子工作流时，会透传当前的上下文作为工作流的实例参数，在子工作流执行完成时会合并子工作流的上下文至父工作流的上下文中。
重试子工作流不会联动重试父工作流，但失败的子工作流会随着父工作流的重试而原地重试（不会生成新的实例）