业务规则
jxTMS的核心理念之一就是：好的系统是定义出来的。
当然笔者不是反对编程，而是编程太过于专业化，同时具有动态性，这两者的结合就导致以编程为主要实现的系统和业务人员绝缘了。而业务系统能否发挥出充分的作用，其主要取决于系统能否贴合业务、贴合使用者的需求。显然，过于技术化的系统是由开发人员所主导的，所以业务人员的想法、认识想贯彻到业务系统中，太难。这样一来，想开发一个好的业务系统就需要一个非常了解业务的系统分析员，但这和jxTMS降低开发门槛来更大限度的普及业务线上作业的目标是相悖离的。
所以，jxTMS才这么推崇定义，凡能用文本定义的通通用文本定义，就是为了减少编程的色彩，以提升业务人员的参与度。
业务系统最核心的自然就是业务规则，所以jxTMS花了很大的气力来设计业务规则。简单说，业务规则就是一条条的如果…则…否则…，就是产生式的中文化。
业务规则就是用来对业务进行检查的，就是检查业务是否符合既定的规范，简称为合规性。所以其包括三个概念
-
条件，就是对采集到的现场数据和必要的组织数据进行检查，以试图发现违规的问题
-
检查点，就是在什么环节对数据进行合规性的检查
-
动作，检查到了不规范的问题如何处置，同时由于流程存在打回重做，所以有时还需要考虑原来不合规现在又合规了，是否需要撤销之前的处置
下面是demo中的销售订单的业务规则演示：
# 销售订单的合规性检查的规则，定义了一个名为checkOrder的业务规则表，其包括两条规则
@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' ;
/* 是否需总经理审批，当然用chech函数直接编程，但这种规则可以和用户的沟通较为顺畅，而且还业务管控规则集中在一起了 */
如果 field.Discount < 30 则 info.needCEO = true 否则 info.needCEO = false;
'''
pass
具体的规则语法请参考编程手册中的相关说明。
业务规则和简易流程一样，都是在修饰后的函数的doc中进行定义的，组织在加载该模块时统一进行加载。
条件检查
第一条规则开头的with sfApproveSalesOrderD1t2是说对sfApproveSalesOrderD1t2这个表【web文件中定义的销售订单中的产品明细表】逐行进行遍历。
其条件判断主要有两种：
-
值比较，就是用来对当前业务对象的现场数据判定其是否符合要求
-
性质判断，主要是用来当有了足够多业务知识与数据中，能在值比较的基础上，进一步的对业务性质做综合判断的，目前暂时不用
而上面演示中的值比较还是一种比较独特的值比较，auth.byCreator.discount = getStoreClassByCode( col.itemCode ) > col.itemDiscount是说根据本行的产品代码【col.itemCode】，调用getStoreClassByCode函数从组织数据集中将其翻译为产品类别，然后再调用组织的auth功能来获取发起审批的销售人员就该类产品的折扣权限，再用这个折扣权限和其实际给出的权限【col.itemDiscount】进行比较，如果过深则标红否则标蓝【主要是考虑打回修改后的修正】。
检查点
业务规则必须根据业务需要在必要的检查点执行才能起到应有的作用。
这个检查点必须满足两个条件：
-
有需要的现场数据，为了不在违规业务上浪费过多的处理成本，自然是越早发现违规越好，但也不能在现场数据都还没采集足够就进行检查，所以检查点的设置，是在业务规则所需的现场数据都采集到的那个业务环节进行检查，demo中是销售填写完申请之后就进行检查
-
该检查点不可被绕过，能被绕过的业务规则没有任何意义。所以演示中的业务规则就被放到销售生成订单时进行检查，只要你想发起订单审批，那在你填写完订单信息后就一定会被检查。所以，请牢记：
业务规则可以允许设置宽松的条件来增加弹性，但绝对不允许被绕过
demo中对业务规则的使用：
@myModule.event('sfApproveSalesOrder', 'saleApprove', 'dual')
def saleApprove_dual(self, db, ctx,ca,active):
if active=='accept':
业务数据处理等
#业务合规性检查
self.restrict(db,ctx,'checkOrder',self.currentAffair)
在用户发起订单审批申请时，先处理数据，然后对处理完毕的业务对象进行合规性检查。这里，我们是用restrict函数调用checkOrder规则表，对当前的订单对象进行了合规性检查，checkOrder中的两条规则先后被投入运行，两条规则互不影响，各做各的检查。
动作
业务规则本质上就是一个给业务人员理解、沟通的格式化的代码片段。
所以，理论上其可以执行非常多的动作，但目前我们主要是用来：
-
标记，如用红色的框将违规处醒目的标识出来，可以大大节省后继人员的处理时间
-
设置特殊的业务状态，如逾期、超限等等，然后在查询时将这个业务状态显示出来，这就是压力了
-
调整业务处理程序，但一般来说，我们建议尽量是以数据的形式来进行调整，所以最好是设置特殊的业务状态，如我们用的needCEO，然后配合其它基础设施来完成业务处理程序的调整
我们期望能让业务人员大幅度的参与业务系统的打造，业务规则就是一个很好的工具，但如果片面追求业务规则的强大，那最终就成了撇开python而自行打造一个编程语言了，所以我们要学会站在业务人员的角度来克制技术的过度运用。
总的来说，笔者认为业务规则的定位主要是用来识别业务违规以确保业务规范的运行。这是目前笔者所认为的jxTMS最有价值的功能：确保业务规范运行。一方面可以减少对业务的稽核成本，大幅度的提高作业效率和速度；另一方面则是可以将高管的精力从业务监控上解放出来，而这才就是直接大幅度提升企业竞争力的关键点。
也就是说，合规性检查+简明扼要的业务报表+少量的事后审计的业务监控模式，是我们近期的努力方向。
目前，jxTMS已经打包为云服务器镜像，开发者开箱即用：
jxTMS-腾讯云市场