Kiwi 是一个基于 Operaton 的 BPMN 工作流编排与管理平台。Operaton 可以理解为 Camunda 7 社区方向的延续，因此 Kiwi 面向的是那些仍然需要 BPMN 2.0、可视化建模、人工任务、服务任务和流程后台的团队。v1.1.0 的重点不只是多几个页面，而是围绕“组件生态”和“模板分发”做了一轮升级：可插拔流程组件、模板市场、管理后台、AI 助手，以及一个支付流程演示，组合起来让它更像一个可扩展的工作流产品底座。
这次升级的重心：流程资产要能复用
很多 BPMN 平台的第一阶段目标是“把流程画出来、跑起来”。这对单个项目够用，但一旦团队开始沉淀标准流程，就会遇到三个问题：
- 服务任务、审批节点、通知节点等能力反复配置，容易散落在各个流程里。
- 流程模板缺少统一分发入口，新人只能复制旧 BPMN 文件再改。
- 业务组件和流程模型绑定太死，后续升级组件时影响面难以判断。
Kiwi v1.1.0 把关注点放在组件生态和模板分发上，方向是对的。BPMN 平台真正的价值，不是让每个人都从空白画布开始拖节点，而是把企业里常见的“请假审批、支付确认、合同流转、工单派发”沉淀为可组合、可治理、可二次开发的资产。
基于 Operaton 的意义：继续吃 BPMN 生态红利
Kiwi 选择基于 Operaton，意味着它没有重新发明一套流程语义，而是站在 Camunda 7 风格的 BPMN 执行模型上。对工程团队来说，这有几个实际影响：
- BPMN 文件仍然是核心资产，可以进入 Git、做代码评审、配合 CI 部署。
- 服务任务、用户任务、网关、事件等概念比较标准，迁移和培训成本更可控。
- 后端可以围绕流程引擎 REST API、Java Delegate、External Task 或类似扩展点做集成。
需要注意的是，Kiwi 是一个平台层封装，不等于直接暴露所有 Operaton/Camunda 7 能力。落地前要确认你依赖的能力，例如历史数据查询、任务监听器、表单模型、外部任务、租户隔离、权限模型等，在 Kiwi 当前版本中是否已经被产品化支持。
插件化组件和模板市场适合解决什么问题
“组件”和“模板”听起来像 UI 词汇，但在 BPMN 平台里它们对应的是很硬的工程问题。
组件更像流程节点能力的封装。例如支付确认、短信通知、Webhook 回调、审批人解析、库存锁定、合同盖章。好的组件应该把以下内容收口：
- 节点在设计器里的展示和配置项。
- 运行时需要调用的后端服务或执行器。
- 输入输出变量约定。
- 错误处理、重试、超时、审计字段。
模板则是业务流程的封装。例如“订单支付后开通权益”“采购申请三级审批”“工单超时升级”。模板市场的价值在于让团队可以分发经过验证的流程骨架，而不是到处传 BPMN 文件。
v1.1.0 提到支付演示，这类 Demo 很适合作为组件生态的样板：支付流程天然包含发起支付、等待回调、状态确认、失败补偿、人工介入等节点，能检验 BPMN 平台是否真的适合编排业务状态机。
可以这样实践：用 BPMN 文件沉淀一个支付确认流程
下面示例不是 Kiwi 官方接口说明，而是一个可改造的最小实践：假设底层流程引擎兼容 Camunda 7/Operaton 风格 REST API，我们用一个 BPMN 文件描述“创建订单后等待支付回调，再完成流程”。你可以把这个思路迁移到 Kiwi 的设计器或部署链路里。
创建 payment-demo.bpmn：
<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:camunda="http://camunda.org/schema/1.0/bpmn"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
id="Definitions_payment_demo"
targetNamespace="https://example.com/payment-demo">
<bpmn:process id="payment_demo" name="Payment Demo" isExecutable="true">
<bpmn:startEvent id="StartEvent_OrderCreated" name="Order created">
<bpmn:outgoing>Flow_Start_CreatePayment</bpmn:outgoing>
</bpmn:startEvent>
<bpmn:serviceTask id="Task_CreatePayment" name="Create payment"
camunda:type="external"
camunda:topic="payment.create">
<bpmn:incoming>Flow_Start_CreatePayment</bpmn:incoming>
<bpmn:outgoing>Flow_Create_WaitCallback</bpmn:outgoing>
</bpmn:serviceTask>
<bpmn:intermediateCatchEvent id="Event_WaitPaymentCallback" name="Wait payment callback">
<bpmn:incoming>Flow_Create_WaitCallback</bpmn:incoming>
<bpmn:outgoing>Flow_Callback_CheckStatus</bpmn:outgoing>
<bpmn:messageEventDefinition messageRef="Message_PaymentCallback" />
</bpmn:intermediateCatchEvent>
<bpmn:exclusiveGateway id="Gateway_PaymentStatus" name="Payment successful?">
<bpmn:incoming>Flow_Callback_CheckStatus</bpmn:incoming>
<bpmn:outgoing>Flow_Success</bpmn:outgoing>
<bpmn:outgoing>Flow_Failed</bpmn:outgoing>
</bpmn:exclusiveGateway>
<bpmn:endEvent id="EndEvent_Paid" name="Paid">
<bpmn:incoming>Flow_Success</bpmn:incoming>
</bpmn:endEvent>
<bpmn:endEvent id="EndEvent_Failed" name="Payment failed">
<bpmn:incoming>Flow_Failed</bpmn:incoming>
</bpmn:endEvent>
<bpmn:sequenceFlow id="Flow_Start_CreatePayment" sourceRef="StartEvent_OrderCreated" targetRef="Task_CreatePayment" />
<bpmn:sequenceFlow id="Flow_Create_WaitCallback" sourceRef="Task_CreatePayment" targetRef="Event_WaitPaymentCallback" />
<bpmn:sequenceFlow id="Flow_Callback_CheckStatus" sourceRef="Event_WaitPaymentCallback" targetRef="Gateway_PaymentStatus" />
<bpmn:sequenceFlow id="Flow_Success" sourceRef="Gateway_PaymentStatus" targetRef="EndEvent_Paid">
<bpmn:conditionExpression xsi:type="bpmn:tFormalExpression" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">${paymentStatus == "SUCCESS"}</bpmn:conditionExpression>
</bpmn:sequenceFlow>
<bpmn:sequenceFlow id="Flow_Failed" sourceRef="Gateway_PaymentStatus" targetRef="EndEvent_Failed">
<bpmn:conditionExpression xsi:type="bpmn:tFormalExpression" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">${paymentStatus != "SUCCESS"}</bpmn:conditionExpression>
</bpmn:sequenceFlow>
</bpmn:process>
<bpmn:message id="Message_PaymentCallback" name="payment_callback" />
</bpmn:definitions>
如果你的环境暴露了兼容的部署 API，可以这样部署。运行前把 ENGINE_BASE_URL 改成你的流程引擎地址：
export ENGINE_BASE_URL="http://localhost:8080/engine-rest"
curl -X POST "$ENGINE_BASE_URL/deployment/create" \
-F "deployment-name=payment-demo" \
-F "enable-duplicate-filtering=true" \
-F "payment-demo.bpmn=@payment-demo.bpmn"
启动一个流程实例：
curl -X POST "$ENGINE_BASE_URL/process-definition/key/payment_demo/start" \
-H "Content-Type: application/json" \
-d '{
"businessKey": "ORDER-10001",
"variables": {
"orderId": { "value": "ORDER-10001", "type": "String" },
"amount": { "value": 9900, "type": "Integer" }
}
}'
支付系统回调后，可以通过消息关联推进流程。这里的 paymentStatus 会进入网关条件：
curl -X POST "$ENGINE_BASE_URL/message" \
-H "Content-Type: application/json" \
-d '{
"messageName": "payment_callback",
"businessKey": "ORDER-10001",
"processVariables": {
"paymentStatus": { "value": "SUCCESS", "type": "String" },
"paidAt": { "value": "2025-01-01T10:00:00Z", "type": "String" }
}
}'
这个例子的重点不是 API 细节，而是建模方式：支付动作可以做成组件，支付流程可以做成模板，模板再通过市场分发给不同业务线复用。
可以这样设计组件清单：把节点能力产品化
如果团队准备基于 Kiwi 做内部组件生态，可以先用一个简单的清单约束组件，而不是一上来就写复杂插件系统。下面是一个可改造的 components.yaml：
components:
- id: payment-create
name: Create Payment
category: payment
bpmnType: serviceTask
runtime:
mode: external-task
topic: payment.create
inputs:
- name: orderId
type: string
required: true
- name: amount
type: integer
required: true
outputs:
- name: paymentId
type: string
- name: paymentUrl
type: string
failurePolicy:
retries: 3
retryTimeout: PT30S
- id: notify-webhook
name: Send Webhook
category: integration
bpmnType: serviceTask
runtime:
mode: http
method: POST
inputs:
- name: url
type: string
required: true
- name: payload
type: object
required: true
这类清单可以帮助你在三个层面建立边界：设计器知道怎么渲染配置表单，运行时知道怎么调度执行器，模板市场知道模板依赖哪些组件版本。
落地建议：先做少量高价值模板
Kiwi v1.1.0 的方向适合两类团队：一类是已经有 BPMN 使用经验，希望在 Camunda 7/Operaton 生态上继续建设平台；另一类是有大量审批、工单、支付、合同、通知编排需求，希望减少重复开发。
采用时可以按这个清单推进：
- 先选 2 到 3 个高频流程做模板，不要一开始追求“大而全”的市场。
- 给每个组件定义输入、输出、错误码和重试策略，避免流程图漂亮但运行时不可控。
- 把 BPMN、组件清单和模板元数据放进 Git，至少保留评审和回滚能力。
- 对支付、合同、资金类流程增加审计日志和人工兜底节点。
- 验证 Kiwi 当前权限模型、租户隔离、历史数据、表单能力是否满足生产环境要求。
Kiwi v1.1.0 的价值在于把 BPMN 平台从“流程设计器”推向“流程资产平台”。真正上线时，技术团队要关注的不只是能不能画流程，而是组件能不能版本化、模板能不能治理、运行时失败能不能被定位和补偿。这些问题解决好，BPMN 才会从演示工具变成业务系统里的稳定骨架。