業務規則
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-騰訊雲市場