# 审批流程

为了说明 Nature 可以很好的避免编码，我们找了个最常用的业务情景，来挖掘一下 Nature 非编码方式实现复杂业务逻辑的潜力，这个场景就是审核。

我们将模拟下面的审核场景：

- 业务类型：请假、报销、借款

- 审核方式：多级审核、多人审核、代理审核，指定审核。







**meta 定义**

**用户信息**：姓名，联系方式；状态：在职|离职|删除。 **如何禁用用户：**将用户状态数据置为无效即可。如联系方式敏感，可使用单独的 Meta 并自行加密。

**组信息**：名称，职责描述；状态：有效|无效。**组之间的层级关系：**组名可以用[这样的形式进行体现：[一级组].[二级组].[三级组]...

**组中的用户**：para：[组]/[用户]；有伴生Meta：**如何找到用户所在的组**：Nature 只有一维索引，无法在原有数据上完成此类任务。需要借助反向的 Meta 定义才可以。这回增加存储以及维护难度。可通过伴生 Meta 来简化维护问题。

**负责人**：para：[组]/[用户]， 状态meta（负责人可以轮流做）, 有伴生Meta（逆向查找）：

**代理人**：负责人可以指定代理人行使审核权限，有私有状态。

**申请单**：模板类型; 状态： new|L1passed|L2passed|L3passed|L4passed|passed|reject,count 初始状态 new； para.num = 2 申请人

**请假申请**：模板：申请单，复用其状态

**报销申请**：模板：申请单

**借款申请**：模板：申请单

**审核凭据**：状态 meta，**注意**：本示例存储的是明文，实际情况需要依据使用者自身的情况进行加密存储。如可以使用自定义执行器对数据进行加密。在提取时进行解密。

**relation 定义**

下面的流程已最大程度减少编码为原则。涉及到编码的地方：发送审核信息，

**多级单人审核**：请假申请

**步骤-提交申请：**请假申请 -> 请假申请_S: Nature 会自动初始化状态，申请ID:外部指定，建议使用时间戳。

para:[uid]

content:json格式，含姓名，联系方式等。

**步骤-生成审核凭据：**这个审核凭据拥有通过或驳回的资格，这个资格是每个人特有的，不能混用。

生成的内容：

para:[uid]

content: 一个字符串，审批或驳回的验证码

解决uid问题：

解决验证码问题

定义，请假申请_S-> 审核凭据.：注意：不要建立关系 请假申请  -> M(审核凭据)，否则存在 请假申请_S 没有生成导致无法审核的情况发生。

filter_before：

context

instance-loader: 选项：

target:

type:content

value_from: para	// 从para中取值

value_path: [0]	// 取第0个 

append:true	// false: overwrite

executor:

scatter

条件：上游的 uid, 目标 meta 

内置executor:数据加载器

说明：Nature 会依据【请假申请_S】自动加载对应的 【请假申请】

filter_before:指定为谁生成审核凭据。如找负责人（可能有一主多副）、代理人等。方法：选定

**发起人指定审核人员审核**

执行器：para /[targetPersion]/[application] , value: 随机码。

filter_after：用于保障**审核凭据的安全性**，使用内置加密过滤器。

**步骤-发送给多人**：使用者可以使用自定义执行器来选择消息载体进行发送，如邮件，短信，钉钉，微信，qq等。

filter_before: 解密审核凭据

执行器：发送

**：**

**扩展说明**：如果是会审的话，可以发放给多个人，每个人可拥有独立的密钥。这需要附加额外的过滤器就可以了。

对审核凭据进行验证

注意：这里只生成一个随机的凭据。**建议**：使用自定义的执行器进行加密操作，以防止数据明文存储。如果这样在下面处理发送请求时需要用自定义的**过滤器**进行解密才能发送。

代理人的有效期：可以使用延迟触发改代理人状态

步骤-一级审核驳回

一级审核,:

条件：状态为 new,

filter_before: 

context_setter:

name: upper

部分审核：报销申请

提交申请，Nature 会自动初始化状态

多人会审：借款申请

提交申请，Nature 会自动初始化状态

流程审批：其中的难点我问发送消息（如微信、钉钉、邮件等）、用户信息加密（公私钥）不利于当做一个免代码示例

**其他说明**

**关系反向查找：**通过 from_key 进行查询。

**验证码的安全性**：此处只是演示性的，真实情况下可在自定义转换器里对验证码进行加密。在使用时解密。

**如何查找部门领导**：可以通过找上级组的组长来实现。

**需要解决的问题**

审批进度查询，显示当前由谁去审批，（可以考虑 GUI 插件）

外部数据输入性验证：如审核通过或驳回信息的输入信息，要求对验证码进行验证。

**需要模拟的场景：**

指定审核代理人，（可指定代理的业务）

多人只的部分审核通过即可。

**Meta**

**Relation 定义**

**请假**

提交审核 -> 审批单状态（同意）

审批单状态 -> (para=请假)(state=同意)  -> 审批单状态 (完成)

notify : 通过申请人找到用户所在的组，通过组找到组的owner

**请假**

审批单/报销 -> 审批单状态（提交）

审批单状态 -> (para=报销) : notify -> Null

提交审核 -> 审批单状态（同意）

审批单状态 -> (para=报销)(state=同意)  -> 审批单状态 (完成)

要点：

数据之间的从属关系需要两条数据，这是Nature工作机制的问题。

**各种形式的审批单**

 用 para 进行区别。之所以不使用 context 是因为不方便检索。

**审核的形式**：

可以指定特定人员审核、可以自己选择审批人。可以依据申请人自动计算审批人，可以指定代理人，可以取消代理人

部门领导审核

跨部门领导审核

会签：所有人都得同意

只要有一个人同意就可以。

驳回，可驳回到任意一点

超时检测

[老板让我开发一个简单的工作流引擎](https://www.cnblogs.com/duck-and-duck/p/14436373.html)