|
流程规则实现
在整个流程的处理中，还涉及到规则的处理和实现，而对于规则可以理解为两种。
其一是简单的判断规则，比如报销单金额超过1万需要流转到总经理审核；还有一种是负责规则判断，比如需要进行详细预算完整性检查，通过和不通过需要流转到不同分支。
结合传统流程引擎实现方式，对于简单规则可以走参数变量传递，而对于复杂规则，则可以考虑直接调用外部API接口服务来实现校验。
在这里只传递需要用作流程判断的数据项目信息参数到流程执行中，本身也减少资源负荷。对于Param信息的传递，一个思路是在流程实例启动后进行缓存，一个是在每一个流程活动节点执行的时候都重新传入。个人建议方式是在流程实例启动的时候进行缓存。
表单和组织权限模型集成
在前面已经谈到对象建模要和表单建模分离，即一个对象建模完成后，实际基于这个对象可以构建多个不同的表单模型，还是拿供应商举例。
一个供应商即使不挂接流程也可以拆分为供应商完整信息维护，供应商银行信息维护，供应商模糊查询，供应商资质信息查询，特定供应商信息查询等不同的表单功能，但是这些表单功能都对应同一个对象模型。表单设计完成后形成的是表单功能。一个表单设计完成后，可以挂接到具体的功能菜单上，同时也可以和某个具体的操作按钮或事件绑定。简单来说就是表单本身可能是存在入口参数的。
一个供应商查询功能表单，查询结果是列表，可以点列表里面的详细信息链接，这个时候应该调整到特定供应商查看界面，那么供应商ID就是重要的传入参数。
可以看到整体权限控制思路仍然是基于角色+资源的访问授权。
一个表单挂接到菜单资源，菜单可以授权给用户组或角色。同样，对应表单设计中的数据项或数据分组也可以定义为需要细粒度控制的资源对象，在资源定义完成后讲资源对象授权到具体的用户组或角色，包括表单中的按钮等都可以采用该思路进行。
即在表单建模完成后，我们需要对建模完成的表单抽象资源对象，资源对象可以是一个独立的数据项，也可以是数据分组或者按钮操作。同时再将资源对象和角色或用户进行绑定。
数据项权限默认设置
一个数据项权限配置最好是既支持默认可见，也支持默认不可见。比如采购订单金额只对采购总结可见，那么这个数据项目默认值则是全不可见，同时将金额定义为资源，授权给采购总监角色。
静态权限和动态权限重叠
当静态权限和动态权限重叠时候如何处理？一般来说应该是以动态权限为主，比如静态权限设置是没有权限，但是动态权限计算后可操作或可维护，那么该用户在动态流程执行中对相关信息就具备动态权限控制。流程处理完后权限即消失。
表单和规则引擎
对于低代码开发平台来讲，实际上我个人并不建议引入比较重的规则引擎，要明白如果真的业务规则很复杂，用规则引擎同样需要写大量的脚本代码才能够实现，而且这个脚本代码本身后续更加难以维护。
规则引擎出来这么多年，实际现在很少看到很成熟的在企业信息化领域的应用场景。
（编辑：漯河站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
