基于Cordys平台上的待办任务优化改造方案

一、当前现状
  系统属于两段式事务管理，典型的异步系统，在应用系统业务事务提交时，同时启动BPM产品的流程操作，由于系统没有采用MQ，这样，对两段事务处理采用数据库触发器的模型，在BPM产品的流程操作完成后（数据库表更新状态），触发并更新任务表数据。
  但是，此方案在实际应用中存在如下缺陷：
 1、BPM产品的流程操作回退后，触发器可能已经触发过了（流程启动不成功，后台原因是数据回滚了），任务数据无法回退；
 2、多个关键Cordys核心表建触发器，并且在触发器中操作业务级数据，容易在业务繁忙时，数据库临时锁时间过长而锁住数据库。

  上述缺陷，对系统的影响如下：
  1、系统在瞬间高峰时刻，容易产生丢文、或文件送不出去的现象；
  2、由于触发器的影响，易出现系统变慢，甚至操作超时的问题。

二、改造方案设计
  1、改造目标

• 去掉触发器，增加消息管理机制；
• 增加流程异常处理，解决两段事务不一致的问题
• 提高系统性能

  2、改造思路

• 数据处理采用存储过程，减少数据传输的性能消耗；
• 建两个独立服务，一个服务是获取Cordys BPM流转状态，存入数据中，另一个是通过存储过程处理任务与CordysBPM流程状态的；
• 对于Cordys BPM流程流转状态，最次方案是使用触发器，是当前触发器的缩略版，去掉所有的业务方面处理；
• 消息管理就是消息（任务）监控服务，可以作为Cordys的定时服务存在，或者是JVM上循环服务，间隔10～60s；
• 消息处理采用批量处理模式，降低对系统的消耗。

  3、设计概述
   一个完整的业务包括：参与者保存业务数据并产生待办任务，启动或启动流程活动，存在两段式异步事务处理，在没有消息中间件的情况下，需要把相关消息数据，以及数据处理，需要借助数据库来完成。最终形成任务管理服务、流程消息监控服务，与门户接口的消息处理服务暂不考虑。
   

   ⑴、业务处理时序图如下：

     ⑵、消息管理的监控活动图如下：

  ⑶、消息管理部署架构

  数据库端按单独存储过程方式处理数据；

•  应用服务器端分别部署处理器，解决单点问题，实际上只有一个数据库端服务在处理数据；
•   数据库端消息队列管理，通过“select forupdate”方式数据库行锁，过滤脏数据；
•   任务状态有：待办、在办、办结、中间状态。

   ⑷、设计产生的服务
   任务管理（监控）服务：用于处理任务状态（待办、在办、办结、中间状态），并提取任务相关的业务数据、流程消息数据到任务服务中；最好也能兼顾门户接口。
   流程流转消息监控服务：用于监控流程流转消息状态（启动、环境处理状态完成或回退），依赖于CordysBPM服务，属于客户化服务。
   任务（消息）处理存储过程：用于处理任务消息，依赖数据库并行处理待处理消息，并提取业务数据、流程信息到任务对象中（表），并清理流程流转消息状态数据。
   流转状态处理存储过程：用于通过数据库获取流转状态信息，更新用户化数据。

   ⑸、消息数据库设计
   为了解决并行处理阻塞的问题，一个消息按状态产生记录（原理与Cordys消息处理方式相似），也就是说一个消息对象，在处理过程中，有多条记录。
   消息管理通过两个表来管理：message、message_track，二者为一对多的关系。
   ☉消息处理记录表定义：


   ☉消息处理记录举例：


   ☉数据处理流程：


    其中，待处理消息表中的数据，可能存在超时的脏数据，需要在服务中每次进行检查，并清理掉，在清理过程中，把相关数据存储到异常日志中。
   ☉数据实体设计（数据表）
   任务表（在用）、任务消息表、待处理消息表、异常消息表。

   ⑹、查询功能设计
   ☉任务消息查询
   ☉待处理消息查询
   ☉异常消息查询
   ☉流转状态查询

三、待办、办结任务管理
  1、待办任务数据提供给门户和办公网主页，处理后清除；
    待办任务数据属于业务级数据，与具体业务数据存在冗余（本次改造，应该减少冗余，专注于任务管理），当进行待办处理时，首先删除此待办数据，并移到任务消息表中，表象为待办任务消失（任何人也看不到），相当于为中间状态，等待消息处理。
  2、办结流程时，相关数据移到办结库中，留作查询使用；
   3、查询功能，设计有在办流程的定义。

四、风险及问题
  1、对数据库将产生压力，理论上应该不会超过触发器，但是，没有相关证据；
  2、增加了状态和中间数据表，需要严格控制、管理，把漏洞降低到最低。

五、后记
  通过此方案，可以提炼基于数据库的消息管理模型，并产品化。

初稿完成时间为：2012年4月12日上午。