编辑 | 邵加佳
随着企业的信息化建设,审批流程已经成为企业运用最多的一种OA办公软件。相较于传统人工审批方式,OA审批管理软件的出现,在提供办公效率等方面对企业有着重要的意义。在开发审批中心之前公司使用的是钉钉审批,但是钉钉无法与公司内部系统打通,既无法满足公司内部系统对提取审批内容的诉求,又无法完美使用公司内部多种用户体系。为此亟需建立一个既能支持零代码搭建审批表单又能无缝对接公司内部业务的新审批系统。
因为要设计审批管理系统,我们分析了市面上使用较广泛的开源软件activiti。它是由Alfresco软件在2010年5月17日发布的业务流程管理框架,它是覆盖了业务流程管理、工作流等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。它实现了BPMN2.0规范,可以发布设计好的流程定义,并通过api进行流程调度。Activiti作为一个遵从Apache许可的工作流和业务流程管理开源平台,其核心是基于BPMN2.0流程引擎,强调流程服务的可嵌入性和可扩展性,同时更加强调面向业务人员。如下图所示,activiti提供了可视化流程配置,从图中可以看出activiti支持,流程条件节点设置,审批人设置。不过这些配置难与我司内部的用户组织等功能结合,二次开发的成本也较高。
考虑到即将设计的审批系统,一定要满足支持公司内部众多不同使用场景,以及能够提供一套供内部其他系统解析表单的功能。为了满足这些要求审批中心必须具备强大的可视化图形化功能,以及一套操作简单且灵活的表单关系映射功能。综合这些强需求,我们确定审批中心需要具备以下特点:
主要分为以下模块(见下图):
表单是最直面用户使用的模块,每个使用方都有各自专属的业务场景,因此提供一个适应多元化场景的表单配置能力至关重要。我们将组件作为表单的基本元素,这样就可以将页面设计的重点转移到组件上来了。为此,我们将组件图形化展示,同时配备大量可复用控件,通过一个统一的表单渲染引擎,拖拽组件自动生成可视化表单页面。
Q1:组件如何聚合?
A1:对于组件之间的聚合支持是通过为每个组件设置一个可聚合的组件类型来决定该组件可以与哪些组件聚合,例如:明细组件,我们允许该组件可以聚合所有非明细组件;非明细组件就不允许聚合其他组件。
Q2:如何支持局部页面动态显示隐藏?
A1:针对局部显示隐藏,将用户选择不同的单选框选项值作为局部刷新的触发事件,通过支持单选值关联任意多个组件,从而实现对指定组件的动态展示,如下图所示。
Q3:图形化组件最终是如何被解析的?
A3:每个图形化组件都对应一段专属的json格式数据,在组件拖拽过程中表单配置引擎会汇总生成一个结构化的json数据。
表单组件按照类型区分为控件库组件和自定义组件,如下图所示:
组件属性主要由全局业务属性和组件基本行为构成,如下图所示。
考虑到每个业务场景都需要不同的配置规则,借鉴activiti的图形化设计思路。我们希望也能有一个聚焦于图形设计的技术帮助实现审批流程的图形化实现。为此,我们调研了AntV G2 这种面向常规统计图表的,以数据驱动,具有高度的易用性和扩展性,用户无需关注各种繁琐的实现细节的信息可视化开源库。
AntV G2 具备如下特性:
通过可视化图形方式,让原本复杂的规则设计变成图形化,用户无须与开发产品等人员沟通是否可实现,而仅需要专注于自身的业务。
基于审批业务场景抽象出:发起模块、审批人配置模块、抄送人配置模块、条件分支模块 和 条件模块,最终生成B树结构性数据。在实际解析时,采用DFS算法遍历B树,获取满足条件的所有审批人和抄送人。
为了能满足公司内部所有人员使用,我们在审批人和抄送模块集成了多端用户模块,支持不同端用户共同参与同一个审批处理,同时针对多端用户提供不同过滤规则。
审批状态流转是所有审批系统的基础功能,同时也是最核心功能,所有非流转功能都是依附于审批状态流转。审批中心当前状态主要有:审批发起、审批同意、审批驳回、审批重新提交、审批复制。不同的审批状态会响应触发不同的附带功能,例如:消息通知推送、用户审批待办数量更新、审批自动化事件发送。
随着业务需求的不断发展,需求方希望可以仅通过搜索审批表单内容的方式获取到自己希望的审批记录。为此使用了elasticsearch帮助构建索引,实现复杂查询。
审批中心项目创建的初衷就是为了能够更好的服务于公司业务,为了实现这个目标就一定要设计一个更切合现有业务系统。为此我们从用户、表单组件、业务自动化和安全管控这4个角度,设计响应的对内外钩子,方便系统内外的衔接。
审批中心为了能支持多端用户使用,必须提供一个通用的接口规范,满足审批内部诸如转交之类的上层行为。为此按照最复杂CRM用户体系设计,包括:个人、组织、角色、岗位。
主体类型来源:审批流程和审批发起人配置中会严格要求设置主体类型。
设计统一wf_user_id保存用户id:多端用户体系有用户id存在冲突的可能,为此设计wf_user_id={platform_主体类型_userId}记录保存,避免造成数据查询异常。
刚开始审批中心并没有自定义回显组件,当时市场部门等需求方希望有一些组件能帮助回显商户主体之类的信息展示,例如:商户信息、门店信息等。最初是通过手动硬编码方式满足业务需求,随着业务需求的增长,手动维护方式会带来以下两种痛点:
为此,必须提供一个全新的设计理念帮助审批中心开发和产品脱离既需要这种硬编码又需要强了解第三方系统功能的恶性循环。自定义回显组件基本组成:权限管理、回显字段、请求配置、回显字段值格式转换,以下是自定义回显组件设计架构图。
Q1:如何避免顺序请求造成的网络耗时?
A1:一个回显组件往往需求同时展示多个回显信息,这时候就需要调用多个接口,如何减少顺序请求造成的网络耗时就成为组件回显信息查询的关键。因此自定义回显组件通过设置一个基础请求配置(即:用户输入字段关联的回显信息),该基础请求配置的返回值 & 用户输入值,应该要包含后续所有接口的请求入参,这样后续接口就可以通过并发请求,从而避免不必要的顺序请求耗时。
Q2:请求配置适配场景?
A2:例如:一个请求响应为{"info":{"status":1},"name":"商户名"},我们需要能够支持提取出key是name的具体值,并将name的值作为请求入参
Q3:参数格式转换适配场景?
A3:业务系统往往返回的参数并不一定能直接展示到页面之上,例如:枚举变量、时间变量。为此必须设计一个格式转换功能支持响应参数到页面展示之间的转换。
业务系统希望解读出用户填写的审批内容,为此审批中心必须提供一种映射机制,将配置的表单模版中每个组件id映射成业务系统能明白的key。因此设计了开发配置功能管理这种映射关系,见下图,
并在此基础上提供了同步和异步消息订阅这两种让业务系统获取审批事件的方式,见下图,
同步事件:提供用于业务系统同步校验等耗时较短行为的交互能力;
异步事件:基于kafka方式生产审批事件。
Q1:如何防止单系统kafka topic数量膨胀,造成性能下降?
A1:早期审批中心使用公司内部的数据总线提供统一的异步事件管理。数据总线利用kafka connector与数据表绑定,但是只能设置一个topic。各个业务系统通过group id订阅各自消息。在后期使用中发现,往往会有一些业务处理了与自己不相关的消息,这样就造成了不必要的数据干扰。针对这种现象,后期通过使用原生kafka方式,为了避免单个系统生产过多不同类型topic消息,设计了针对每个项目组设置一个topic,项目组内部通过group id订阅各自消息,这样就能既避免的topic数量的膨胀同时也实现了不同项目组数据的隔离。
信息安全对每个公司来说都是万分重要的,为此设计一个合理的数据隔离对审批中心来说至关重要。目前的审批中心主要围绕以下四点进行权限校验:
审批权限校验
每个审批都是有指定的审批人,用户一定不允许查看到不属于自己的审批。
组件信息查询权限校验
上述中的回显组件查询,因为需要查询到公司内部的商户、门店等敏感信息。因此必须要校验实际操作人的权限。实际使用过程中采用限流和权限校验等手动防止恶意盗窃公司敏感数据。
支持业务系统自定义同步校验
借助上述中审批自动化对接中的同步事件,主动调用外部提供的callback接口,将审批信息传递给各个外部系统,最终由外部系统自定义权限校验。
支持业务系统异步同步校验
借助上述中审批自动化对接中的异步事件,由外部系统接收审批kafka事件,主动调用审批中心提供的callback接口,变更审批状态和业务处理状态。
随着互联网的不断发展,企业OA审批管理软件也在不断发展。综合来看审批管理已经发展到表单和流程零代码配置化、无缝对接企业应用系统等特点。期间不断汇总来自众多团队的建议,不断完善功能优化和体验优化。在近3年的时间里审批中心已经与众多业务线完成对接,服务了200w+的审批。当前在组件权限安全和组件业务属性配置化仍然需要手动开发,组件自定义彻底实现零代码化是未来演进的方向。未来还将继续汇总公司内外的优化建议,共建一个业务需求契合度更高的审批中心产品。
姚旭东,来自增值业务开发部
微信扫一扫
关注该公众号