CCFast 驰骋低代码BPM-积木菜单设计思想
CCFast 驰骋低代码 BPM:积木菜单设计思想
一、概述:为什么从“菜单”出发做低代码
1.CCFast驰骋低代码 BPM是一款开源的低代码开发与流程平台,面向企业信息化与业务流程数字化场景。
2. 本文章阐述:驰骋低代码 BPM 的整体体验与交付结构,根植于一套清晰、可扩展的菜单体系。
3. 其核心理念可以概括为:以菜单体系为骨架的低代码开发与运行平台——不是零散堆页面,而是用“可被授权、可被复用、可被组合”的菜单单元搭建系统。
4.底座能力运行在组织结构管理与系统权限体系之上:权限按系统、模块、菜单等粒度,并结合人员、角色、部门等进行划分与控制,积木菜单始终在可控、可审计的边界内被使用。
5. 在产品语境中,菜单体系也常被称为「工具箱」,每一条菜单就像一个「工具」:解决系统建设过程中不同场景的问题,需要用不同的菜单形态去对症处理。
6.类比:维修一辆车时,拆装需要扳手等各类工具;路试与诊断需要测试仪器。不同阶段、不同工种,取用不同工具才能完成高质量交付。
7.类比到信息系统:会做查询、会做左树右表、会做大屏、会做实体台账、会做单据闭环、会做工程进度、会做任务协作……这些能力在工程中常常同时存在,但并非同一种页面形态能解决所有问题。
8.工程化视角:在一个成熟系统里,系统由不同类型的菜单组合而成。菜单类型越齐备、每种类型下的配置抽象越稳健,平台的表达力就越强。
二、积木菜单的定义:模板化解决“一类问题”
1. 菜单可以理解为页面模板——它不是一次性的静态页面,而是面向一类稳定问题域的运行时载体;每个模板都对应一类典型应用场景。
2. 举例:
- 流程类菜单:承载“立项—审批—办理—归档”的可编排协作;
- 实体类菜单:承载“台账式主数据”的增删改查与业务关联;
- 大屏类菜单:承载“沉浸式、可读性极强的数据展现与态势感知”;
- 视图类菜单:承载“基于数据源的列表、检索、层级组织、图形化时间表征”等分析型诉求。
3. 平台能力的乘数:模板越丰富、每个模板的关键配置项越“抽象得刚刚好”(既不捆死开发者,又不会把复杂度甩给业务用户),CCFast 的整体能力半径就越大。
4. 当前主流的模板版图(与产品能力与路线图对应,具体以交付版本为准):流程类、单据类、实体类、活动类、工程类、大屏类、OA 类、视图类、高代码类。
三、对标产品界面:积木菜单分组导读
在驰骋低代码的「新建积木菜单」工作台中(`GPN_Menu`),能力与向导按分组组织,可作为读者理解本平台“菜单家谱”的快速索引:
| 分组 | 名称(摘要) | 读者可记住的一句话 |
|:-----|:-------------|:-------------------|
| A | 流程 | 以流程模板为维度发起、办理、追踪业务 |
| B | 单据 | “有事发生”的记录型表单,常与审核结合 |
| C | 实体 | “有编号与名称的事物”台账,承载主数据语义 |
| U | 字典管理 | 低频变更的键值与树形基础数据入口 |
| P | 工程 | 项目、里程碑、进度与任务的工程化视图 |
| W | 活动(持续演进) | 面向特定人群的限时采集与外联表单 |
| E | 大屏列表(含数据源列表等入口) | 蓝色/白色风格的数据大屏与统计分析场景 |
| J | 视图 | 用数据源拼装列表、查询、左树右表、多维报表 |
| D | 高代码 | 以 TS 全栈范式与页面模式解析支撑深度定制 |
| G | 页面引用 | 自定义 URL、Tab 容器等“最后一公里接入” |
| F | 工具视图 | 实体/单据/流程从表视图等拼装型能力 |
| H | OA 应用 | 信息发布、日程日历、记事、知识库、工作日志等办公常用能力 |
下文按“业务可读性优先”的顺序展开模板类型,穿插与分组相关的落地说明。
四、流程类积木
-应用场景:公文、请假、订单、巡检与物联网业务流程等一切以“流转与协同”为中心的场合。
-能力要点:在此类菜单上以某一个流程模板为维度完成发起、待办办理与全过程追踪,让业务从个人操作升级为组织级协作。
-引擎底座:驰骋采用CCFlow / JFlow作为工作流引擎,长期在大量项目中沉淀,适配国产环境与复杂组织模型,侧重稳定可用与工程可维护。
-与产品向导的呼应:向导中提供极简/专业建模路径、表单绑定策略、导入与“引入流程组件”等选项,满足不同交付节奏与存量资产复用需求。
流程设计器:
五、实体类积木
5.1 实体是什么
- 通常具备编号、名称等主键语义字段的业务表单(或数据结构),围绕“某个事物本体”进行管理,描述对象的属性集合,语义上更接近说明书/台账:这是谁、有哪些属性、处于什么状态。
-典型示例:资产、学生、车辆等主数据的集中维护。
5.2 实体与流程的三种常见关系(重要概念)
为方便业务规划,可把“实体驱动的流程语义”归纳为三类表述(以下为产品语义抽象,命名以项目实施为准):
1.多次业务流程
- 在同一个实体上可以多次并行或先后发起互不“锁死”业务流程;流程生命周期结束时,不改变实体的核心业务属性。
-示例:车辆加油、洗车、年检提醒类流程——车还是那台车。
2.宿主流程(强约束语义)
- 流程一旦启动后在运行中与结束后,可能对实体属性造成不可逆或强一致的业务影响;在流程占用实体生命周期的时段内,通常不应再对同一实体启动另一套同类宿主流程。
- 典型诉求:同一业务对象在某个阶段只能被一个“主轴流程”治理。
3.批量发起流程
- 选择多条实体记录,将它们作为起始集合进入流程起始节点或其从表结构,从而实现规模化办理。
-示例:车辆批量报废、批量异动类业务。
补充:修改流程(批量治理):在既定流程上对一批存量数据进行校正、调整或补办,常与数据治理场景结合——强调“以一个流程上下文处理一批数据的统一语义”。
六、单据类积木
-形态特征:报销单、出库单、出门单等“一单一事”,往往具备单号、标题,记录时间、地点、人物、事由等要素,语义上更接近叙事文:当时在什么场景下发生了什么。
-审核诉求:出库、请假等业务天然需要签收、核准与回溯。
-审核两种常见模式:
-简易审核:以更轻的路径完成单据侧的审批链路(适配简单组织与低风险场景)。
-流程审核:让单据挂载在标准流程模板之下,以获得更强的过程治理、权责分离与可追溯性。
-与产品向导的呼应:支持表单创建与模板导入、以及与既有单据资产的“组件化引入”,利于资产沉淀与并行交付。
七、字典管理
-用途:管理系统中相对稳定的基础数据——键值对与层级结构,常用于下拉框数据源、编码体系与分类口径统一。
-典型内容:商品类别、省份、职位、大类/小类等。
-两类结构:
-编号–名称型平面字典;
-编号–名称–父节点编号的树形字典。
-与产品向导的呼应:提供字典表创建、树结构字典创建,以及“把既有字典维护页面挂接到菜单”的引入能力。
八、大屏类积木
-价值主张:以更友好、更直观的方式呈现关键指标与态势,把注意力引导到最需要被看见的异常与机会。
-常见区分:蓝色科技风大屏、浅色信息窗/白色风格大屏等——面向指挥室与管理驾驶舱等不同阅读环境。
-与产品向导的呼应:工作台提供大屏绑定与创建向导,并常与可视化设计器侧的工程列表联通;分组内也常一并提供数据源列表、通用列表组件等统计分析入口。
九、工程类积木
-场景:项目管理、甘特视图、任务跟踪、里程碑管理等以“计划—执行—纠偏—复盘”为主线的工作。
-说明:驰骋提供工程侧的引擎能力与模板向导;更细的参数建模与行业方案可在具体交付文档或版本说明中展开。
十、活动类积木
-定位:在一定时间窗口内,对特定范围用户采集信息的工具;强调外联可达、表单清晰、收口可控。
-典型场景:调查问卷、外部订单、信息采集样表、面向外部身份的登记活动等。
-与产品向导的呼应:工作台已提供表单活动、试卷测评、业务流程型活动等向导项,并按用户类型、采集频次等维度做基础治理配置(能力与界面以当期版本为准)。
-活动细分类型:可依行业方案扩展——例如信息采集、评测测评、限时申报、外链订单等;“活动”本质是在时间、人群与主题三者约束之下的采集与协办机制。
十一、视图类积木
-定位:面向“看得清、筛得准、钻得下去”的场景,围绕数据源配置:列表、查询、左树右表、以及结合甘特语义的时间维展示等。
-与产品向导的呼应:提供不分页视图、分页视图、左树右表、二维/三维交叉报表等向导入口,并按数据源方式进行选型。
十二、高代码类积木
-定位:在需要突破标准向导边界时,以TS 全栈范式承接深度定制;“基于多种页面模式的解析,像写结构化文档一样组织页面”。(产品拷贝中概括为“十三种页面模式”的工程抽象。)
-与产品向导的呼应:工作台提供 Entity、GPN、TreeEns、GL、Tabs、多维报表等诸多高代码拼装入口,并提供 AI 工具链辅助由提示词或界面稿生成骨架代码包的落地路径——强调可读、可预览、可下载、可接续开发。
-与读者的一句话:积木负责80% 的标准能效,高代码承接20% 的关键差异,两者共享同一菜单与权限底座。
十三、OA 应用与其它组装能力
13.1 OA 应用
-定位:高频办公动作的“标准件”合集,开箱即可挂入菜单并被授权——例如信息发布、日程/日历、记事本、知识库、工作日志、自定义消息提醒、网盘等。
13.2 页面引用(分组 G)
面向存量系统与外部页面的桥接:自定义 URL 菜单、Tab 容器等页面级组装能力。
13.3 工具视图(分组 F)
- 聚焦“从表单主从结构出发的视图拼装”:实体从表视图、单据从表视图、流程从表视图等,让明细数据以受控视图进入工作台。
十四、结语:用对的工具做对的事
积木菜单不是要替代专业开发,而是用可复制、可治理、可分权的工程语言,让企业软件从作坊式拼接走向系统化装配。当组织在底座之上把“谁在什么模块能打开哪把工具”说清楚,开发与业务才能在同一套语义下对话——这也正是驰骋低代码 BPM 坚持用菜单体系做产品骨架的根本原因。
