jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台，详见：jxTMS简介。本文是讲述jxTMS平台中流程部分是如何设计的，整个系列请访问：jxTMS设计思想
上篇文章说到过：要尽可能的让一个人就完成流程的所有开发工作以及要尽可能的简单。
但大家数一下本系列文章，讲流程的这已经是第四篇文章了，而之前最多的也就是数据库访问的才两篇。所以流程自身本就是非常复杂的。反映到流程的处理逻辑上同样是比较复杂：
1、一个流程一定要绑定到一个数据对象上，否则前面讲的现场数据、快照、追溯就全都成了空中楼阁
2、前面讲了，jxTMS中的简易流程都是或入或出的，那么就需要根据用户的选择来确定待执行的下一个流程节点，而为了提高流程的适用性，所以用户选择以及用户操作就是非常灵活而多样的，有同意、有带返回点的拒绝、有不带返回点的拒绝、有指定返回点的要求补充说明以及对应的提交补充说明
3、在确定了下一个节点后，要确定将相应的节点任务分发到哪个具体的成员
4、在某用户打开流程详情查看界面时，要用保存的现场数据来对流程界面执行数据装定，以便于其查看流程的详情
5、同时，还要确定该用户是否有正在执行中的节点任务，如果有则取消该子界面的遮罩以便于该用户的操作
6、用户执行完本节点的任务后，要记录流程的流转信息、执行信息以便于后续计算任务分发时使用，同时还要保存现场数据作为快照、要记录数据变动、要记录流程日志等等留痕动作
7、此时还需要将分发给用户执行的节点任务标记为已完成，否则该用户以后还可随时修改流程的现场数据，这就会导致严重的漏洞
这些工作全部由jxTMS完成，就大大减轻了用户的流程处理的复杂度与工作量，可以将精力集中在流程各环节具体的业务处理逻辑方面。
也就是说，jxTMS已经把所有能通用的流程处理全部统一处理掉了，开发者只需要集中注意力在各流程节点自身的业务逻辑方面即可。
大家再看一下，用户的业务处理应该放到哪里呢？应该是5、6之间吧？是的，但不完全如此。
在2、3点之间，是否应该有一个确定该节点是否需执行的判断呢？！即在一个节点准备投入运行前，是否可以根据业务状态、业务需要、业务策略、业务规则等来判断该节点是否需要执行呢？！
典型的，如报销审批，如果我们的审批流程坚持下去，相关作业日益规范，流程的追溯、审计的威力为所有员工所深知，那就完全可以实现按额度预算化报销，即通过月、季度等周期性授予额度，部门、项目实施预算管理，则在额度内、预算内的报销就只需被授予者同意就可以了。这就会极大的解放高层管理人员的精力，使得其来推动更多工作的流程化、规范化，通过计划、组织、控制的精细化来提高运营效率。更好的来领导整个团队高士气的、高效率的工作。
所以呢，同样的审批流程，我们通过逐步在每个节点前判断是否超额度、超预算等，就可以逐步增加对额度管理、对预算管理的支持了。
因此，jxTMS的流程实现中，对每个流程投入分发前，都会请求一个该节点是否需执行的条件判断函数，来决定是否将该节点分发给用户执行，还是直接确认跳过。
如果大家是从本系列开始就仔细看过的话，可能就有一个疑惑：jxTMS的一个设计理念就是尽可能的定义而不要编程。那为什么这里却采用的是执行用户自己编写的函数而不采用jxTMS已经用的很熟练的规则表呢？
这主要是由于笔者对节点是否执行的条件检测实际用的还是太少，而规则表的能力毕竟是有限的，笔者不是很清楚规则表的语义支持能力是否能完全满足流程节点是否执行的条件检测的需要。
所以，在当前的jxTMS中还是采用了编程的手段，这可以确保能力方面不会有任何的问题，等有了足够的经验，确信规则表的语义表达能力也足以满足流程节点是否执行的需要后，再来升级就是了。
流程节点执行与否的检测函数是一个用request修饰后的用户自定义capa的成员函数。其修饰以及函数签名是：
@myModule.request(flowName, nodeName, 'check')
def funcname(self, db, ctx, currentJO, active):
......
即将该函数绑定到名为【flowName】的流程的【nodeName】节点，当jxTMS的流程引擎在某节点执行完毕，需要顺序处理下一个节点时，将调用下一个节点的check函数，将与本流程实例相关联的数据对象和动作也作为参数一同传递给这个check函数。
如果check函数返回True，则流程引擎将生成下一个节点的任务，并将其分发给相应的执行人员；如果check函数返回False，则直接以accept【即确认】动作自动完成下一个节点。
如果下一个节点未绑定自己的check函数，则默认返回True。
当确定将流程节点任务分发给某成员执行后，jxTMS将创建一个任务实例，然后将相关信息记录，生成一个viewA的入口，然后将这个入口指派给执行者。该执行者就可以在【任务管理->我的任务】中看到该入口，点击该入口即可执行该流程任务。
当该执行者在本环节所对应的界面中输入相关信息然后点击【确认】、【拒绝】等按钮后，jxTMS就会调用本节点的用户自定义函数来实现业务处理逻辑。和check函数类似，该处理函数是本节点的dual函数：
@myModule.request(flowName, nodeName, 'dual')
def funcname(self, db, ctx, currentJO, active):
......
其中的currentJO就是本流程实例的数据对象；其中的active就是用户操作：
accept:同意，流程顺序推进到下一节点
reject:拒绝，流程返回第一个节点【默认的起始节点start节点后的第一个节点】后指定的之前某个执行过的节点
replenish:补充说明，流程返回到之前指定的某个节点请求做出补充说明
目前jxTMS已经开放个人注册试用，欢迎大家注册试用：
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：
下面的系列文章讲述了jxTMS的一些基本功能：