jxTMS设计思想之业务规则

jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台，详见：jxTMS简介。本文是讲述jxTMS平台中合规性检查部分是如何设计的，整个系列请访问：jxTMS设计思想

大家都知道，管理有四个领域：领导、计划、组织、控制。管理软件的重心首先就是控制。而控制在管理信息系统来说主要是：

• 确定风险点的风险因素

• 落实监控信息的采集与传播

• 发现差距，风险就表现为采集到的监控信息和标准状态的偏差

• 根据组织规定产生纠偏动作

• 监督纠偏动作的执行情况

上述的组织控制过程，是一个人机相互配合的过程，软件系统主要是信息采集、对比、发现问题后提示、监督纠偏动作执行等。

由于是一个人机配合的过程，而就jxTMS来说，代表机器来配合组织方管理制度落地的是开发人员，而jxTMS的核心理念是低成本定制，这个低成本很大程度上取决于低成本的开发人员。那么，低成本的开发人员如何能准确领会组织方的管理人员的思路与意图，使得管理系统能准确配合控制过程的落地呢？！

笔者思来想去，认为关键还是能提供一种工具可以让业务人员直接表达差距发现和纠偏动作，开发人员只需要对业务人员的直接表达用此工具加以修整以符合工具的要求。这就是业务规则。即用业务人员可以理解的规则性文本来描述风险检测条件以及检测成功后的纠偏动作。

那大家可能就会很容易理解了：就是中文表示的产生式嘛！对的，简单、直观、高效，和流程一样，属于定义在capa函数的doc中的辅助部件，可以随意修改，随时通过热机刷新加载后生效。

理解了业务规则，自然就能理解业务规则主要包括两部分：

• 在指定检查点，对当前业务状态执行检查

• 对检查出的风险点，加以标记等各种警示，目前一般采用高亮显示以便于所有查看者都会迅速看到问题点

业务状态检查

业务状态的检查，就是一个条件比较，所以关键是能获取到哪些业务信息。经过整理，目前jxTMS向业务规则开放了如下的数据领域：

• 功能点的输入

• 现场数据，功能点的输入只是本次用户的输入，而如果是流程的话，则现场数据中包括了之前所有环节各用户的全部输入的叠加

• 上下文中的局部数据，可查询当前用户的信息、当前用户所在组织的信息、当前用户的主角色、所在部门等信息

• 规则表中的临时数据【用于不同规则间交换数据】

• 数据对象的属性、标记等数据

• 组织的授权信息，如销售折扣等

检查后动作

业务规则就是对当前的业务状态进行检查，以发现风险点，然后就发现的风险采取行动。这些行动主要包括：

• 阻止用户操作，这主要是通过掷出一个异常，当然，有点太过粗暴

• 停止继续检查

• 弹窗警告

• 设置功能点的输出

• 设置当前界面中某个控件的属性，如将某个输入控件，用红框框起来

• 对数据对象做标记、设置属性等

• 设置规则表中的临时数据【用于后继规则使用】

示例

一个比较复杂的例子，是对销售订单中各产品的销售折扣进行检查，如果销售提交的订单中某产品的销售折扣低于其权限，则将相应的售价标红【用一个红框框起来】。

要实现此项检查，需要：

• 根据产品编码，获取该产品的分类号

• 根据产品分类号，获取销售对于该类产品的销售权限

• 如果该权限值大于销售所给出的实际折扣，则标红，否则标蓝

该业务规则表，还有一条业务规则，我们先看下整个业务规则表：

# 销售订单的合规性检查的规则
@myModule.rule('checkOrder')
def rule_checkOrder():
    '''
	/* 折扣超权限则标红以提示审批人员注意 */
with sfApproveSalesOrderD1t2 如果 col.itemDiscount > 0 且 auth.byCreator.discount = getStoreClassByCode( col.itemCode ) > col.itemDiscount
    则 colAttr.itemDiscount.boder = '3px solid red' 否则 colAttr.itemDiscount.boder = '2px solid blue' ;

/* 是否需总经理审批 */
如果 field.Discount < 30 则 info.needCEO = true 否则 info.needCEO = false;
    '''
    pass

checkOrder业务规则表，包括两条，第一条非常复杂，我们详细说明一下：

#对现场数据中的销售明细表进行逐行检查
with sfApproveSalesOrderD1t2

该检查有两个条件组成，一个是折扣一定大于0，因为有些项是赠送，没有费用，那折扣肯定也是0；另一个条件是：

auth.byCreator.discount = getStoreClassByCode( col.itemCode ) > col.itemDiscount

getStoreClassByCode是调用此函数将itemCode列中的产品编码查出其产品分类号，然后将这个产品分类号，赋值给auth.byCreator.discount，其实就是查询组织授权中创建这个订单的销售的该产品分类号所对应的折扣。然后和itemDiscount列中的数值进行比较。

如果比较结果是大于，即销售折扣打的比权限深，也就是越权了，则将itemDiscount列的值用3个像素的红框框起来，否则用2个像素的蓝框框起来。

大家看了这条规则是否感觉太复杂了，别说业务人员了，开发人员看起来都吃力啊，是的，因为这条规则要做的事太多了。

而一般的业务规则就是第二条规则，这就简单多了，就是看一下总折扣，如果总折扣低于30%那需总经理审批，否则就不需要。然后在总经理审批的节点check函数中检查流程数据对象的Info中的needCEO值就可以决定该销售订单是否需总经理进行审批了。

所以呢，如果我们在生成订单时，就逐行将销售的销售权限先查询出来放到一个列中，那第一条规则就会非常简单了，形如：

with sfApproveSalesOrderD1t2 如果 col.itemAuthDiscount > col.itemDiscount 
    则 colAttr.itemDiscount.boder = '红';

即我们增加一列：itemAuthDiscount用来保存本行产品的销售授权折扣，那整个检测条件就会简化为一个条件、一个动作了【列属性的boder可以用红、橙、绿、蓝的缩写】。

但是，前一种虽然复杂，但其表达的语义都是这一条规则统一完成的，而后一种虽然简单，但其语义是切分成两个部分来完成的，那就存在错漏的可能，不利于检查语义的完整、检查结果的准确与可靠。

所以，大家要根据自己的情况来选择业务规则的编写。当然，就示例来说，显然是简写版本较好。

checkOrder业务规则表编写好后，在需要执行检查的业务逻辑中调用restrict函数即可将其用于业务状态检查。本示例是在销售启动销售订单审批流程的第一个环节的业务逻辑处理的最后：

#业务合规性检查
self.restrict(db,ctx,'checkOrder')

目前jxTMS已经开放个人注册试用，欢迎大家注册试用：

注册到jxTMS

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本功能：

jxTMS的HelloWorld