介绍
企业的发展越来越快，企业内部需要使用到的企业级应用也越来越多。有些需求和流程与流程编程相关。每当遇到这种需求都会去找流程编排相关的框架，毕竟没必要为了做了一个应用来造个轮子。使用建木来作为底层流程编排是一个不错的选择。
如何做
- 在建木平台上创建流程，获得流程的webhook地址
- 使用自己的平台来触发建木流程
- 在建木第一个节点回调到自己的系统，感知到流程已经开始执行
- 流程其他节点执行业务逻辑
- 建木流程最后一个节点回到自己系统，感知到流程执行结束
示例
用建木在多台机器上执行脚本
- 编写一个流程执行shell脚本，DSL如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
| name: 远程执行shell脚本
trigger:
type: webhook
param:
- name: task_id
type: STRING
exp: $.body.json.id
- name: task_record_id
type: STRING
exp: $.body.json.taskExecRecordDetailId
- name: shell_script
type: STRING
exp: $.body.json.script
- name: ssh_ip
type: STRING
exp: $.body.json.sshIp
- name: ssh_port
type: NUMBER
exp: $.body.json.sshPort
- name: ssh_user
type: STRING
exp: $.body.json.sshUser
- name: ssh_private_key_name
type: STRING
exp: $.body.json.sshKeySecretName
global:
tag: ${trigger.tag}
concurrent: true
param:
callback_url: http://10.11.12.13
pipeline:
startx:
type: local/autoops_callback:1.0.1
param:
callback_url: ${global.callback_url}
callback_api: /api/v1/task_exec/start/${trigger.task_id}/${trigger.task_record_id}
callback_params_env: '{"recordId":"JM_INSTANCE_ID"，"triggerId":"JM_TRIGGER_ID"，"projectId":"JM_PROJECT_ID"}'
callback_type: start
get_uuid:
type: local/get_uuid:1.0.0
scp_shell_script:
type: "scp_resource:1.3.0"
param:
ssh_private_key: "((${trigger.ssh_private_key_name}))"
ssh_ip: "${trigger.ssh_ip}"
ssh_port: "${trigger.ssh_port}"
ssh_user: "${trigger.ssh_user}"
remote_file: "/tmp/${get_uuid.uuid}.sh"
file_content: "${trigger.shell_script}"
remote_execution:
type: local/remote_execution:1.0.0
param:
ssh_private_key: "((${trigger.ssh_private_key_name}))"
ssh_ip: "${trigger.ssh_ip}"
ssh_port: (${trigger.ssh_port})
ssh_user: "${trigger.ssh_user}"
execution_cmd: "sh /tmp/${get_uuid.uuid}.sh"
clear_remote_file:
type: ssh_cmd:1.0.2
param:
ssh_private_key: "((${trigger.ssh_private_key_name}))"
ssh_ip: "${trigger.ssh_ip}"
ssh_port: "${trigger.ssh_port}"
ssh_user: "${trigger.ssh_user}"
ssh_cmd: "rm -f /tmp/${get_uuid.uuid}.sh"
finish:
type: local/autoops_callback:1.0.1
param:
callback_url: ${global.callback_url}
callback_api: /api/v1/task_exec/finish/${trigger.task_id}/${trigger.task_record_id}
callback_params_files: '{"log":"${remote_execution.log_path}"}'
callback_type: finish
work_status: (${remote_execution.inner.execution_status} == "EXECUTION_SUCCEEDED")
status_true_flag: "SUCCEEDED"
|
- 在自己系统触发建木执行
在自己系统看到建木执行状态
使用到的接口
| 接口 |
说明 |
| POST /webhook/** |
触发项目，执行流程 |
| GET /view/workflow_instance/{triggerId} |
根据triggerId查询流程实例 |
| PUT /workflow_instances/stop/{instanceId} |
流程终止接口 |
注意事项
正常情况下，在第一个节点回调平台传回triggerId instanceId等数据，平台感觉到流程开始执行。在最后一个节点回调平台，平感知到流程执行完毕。但是这中间只要有一个节点执行不成功，就会导致平台无法感知流程状态。为此需要使用定时任务去查询流程状态来补偿状态信息。如果查询出流程已经失败，是否需要终止流程、重试节点等操作，需要根据业务自行处理。这里会有一个问题，就是第一个节点也执行失败，那定时也是白费，因为没法获取本次执行的triggerId导致流程无法控制。目前最新版本已经支持在webhook触发时返回triggerId了。
