我的知识库

网通的sms平台项目版本已经提交，负责的产品模块开发，趁着今天的空闲时间来给它总结下。

面向电信运营商的管理系统，主要分CP/SP和OP两大子系统，其实两者之间主要区别主要是权限分配的不同，简单一点理解：SP/OP操作员或运营商操作员提交产品开通申请，修改申请，产品暂停申请，恢复暂停申请或产品注销申请。运营商管理员查看申请信息，接着由管理员(包括不同角色)对相应的申请进行审批，整改，配置和测试等工作步骤，工作成功走完后，产品即生效，中间任一工作流步骤失败则直接通知申请者申请驳回(整改步骤初外，其可以给申请者一次修改申请信息的机会)。

关键字  工作流引擎  业务表分析与设计

 

工作流引擎，从开始的理论理解，现在，通过对每一步的数据跟踪后，现对其有了一个比较清晰的认识。其实所谓的工作流引擎，我们可以把它理解为一套组件，其包括：业务逻辑代码，xml配置文件和数据库表支持。业务逻辑代码将终端相关数据记录到引擎表，同时控制工作流中的每一个步骤的准确定位并解析xml文件数据并将其注册到工作流引擎表中。

工作流相关字段介绍

工作流流程状态workflowlife
0-未启动，
1-审核中，
2-配置中，
3-测试中，
4-整改中，
5-割接中

工作流状态，workflow
0-未启动，
1-申请，
2-修改，
3-暂停，
4-恢复，
5-预注销，
6-注销

产品状态，status
0-申请
1-正常
11-申请待生效
2-暂停
5-预注销
6-注销

工作流引擎配置文件 product_create.wkfw(产品申请流程...)

注：以上配置文件中的<script>结点中的流程由c进行解析并控制流程的

 
引擎表类图描绘：
   
   


引擎表的设计如下：

wkfw_reg表存放的是具体每个工作流状态(workflow)下的信息，用wkfw_id唯一标识,wkfw_name为相应配置文件名称,SHOW_NAME,GROUP_NAME,STR0_NAME -- STR9_NAME,STR0_SHOW_NAME -STR9_SHOW_NAME字段从配置文件结点属性解析而得.

wkfw_action_reg表存放的是在每个工作流流程状态(workflowlife)下的信息，用action_id和wkfw_id共同约束记录,action_id和action_name字段从配置文件中的结点action的两个属性id和name解析而得,ACTION_STR0_NAME -- ACTION_STR9_NAME,ACTION_STR0_SHOW_NAME -- ACTION_STR9_SHOW_NAME为扩展字段.

wkfw_session表存放的是当工作流开启到结束的过程当中，每个工作流流程状态(wkfw_id约束)涉及到的业务信息(str0-str9字段),工作流开始和结束时间以及此工作流下一步骤的状态字段(next_action_id和next_action_sid)的值定位。

业务信息形如： cp/sp序号cpindex 、cp/sp编号cpid、cp/sp名称cpcnshortname、业务能力类型名srvtypeshortname()、业务序号serviceindex、业务编号serviceid、业务名称servicename、产品序号productindex、产品编号productid、产品名称productname.

wkfw_session_history表存放的是wkfw_session中的历史信息，因为当工作流走完后，产品在引擎表wkfw_session注册的信息就会注销，但会在此history表中留下历史记录作为以后的历史工单(工作流)查询.

wkfw_action表存放的是每个工作流状态(workflow)下的各个工作流流程(workflowlife)步骤的记录的集合，并用wkfw_id和action_id来实现具体的工作流状态(workflow)下的工作流流程状态(workflowlife)的唯一性确定.同时，wkfw_action中的action_id和action_sid状态值和wkfw_session中的next_action_id，next_action_sid对应.即,next_action_id和next_action_sid对应wkfw_action中工作流步骤处理中待处理(审核,配置,测试)状态的action_id和action_sid值.

wkfw_action_history表存放的是wkfw_action中的历史信息，因为当工作流走完后，产品在引擎表wkfw_action注册的信息就会注销，但会在此history表中留下历史记录作为以后的历史工单(工作流)查询.

注:
   wkfw_reg和wkfw_action_reg表中的数据是在系统启动时由引擎程序一次性解析所有的*.wkfw文件并将其中的节点值全部注册到此两表中.

   action_id的初值为1，解析*.wkfw文件时和其文件中的action_id匹配并执行配置文件相应的代码段，同时将此步骤对应的action_id值注册到wkfw_action表中,下一个工作流步骤的action_id从引擎表中查询出来跟*.wkfw配置文件中的action_id匹配...

 

业务表设计(短信产品)：

product buf表

   buf表可以理解为临时表，主要是在对产品的修改(此产品已经走完工作流)申请后，进入工作流的下一步审核时，要是审核没有通过，则产品表中的数据无法还原到初始状态。所以，这里是这样实现的：在产品修改申请提交后，将修改后的数据insert先存到buf表中，待修改的申请成功走完工作流的每一个步骤后，在最后一步时，再将buf的数据insert到产品表中，此时修改的数据才真正在产品表中生效!

product workflowhist表

   产品工作流历史表和产品表相比较，就是在前面多了workflowindex,actionindex,actionsid,wkfwsid字段，用来标记其工作流每个步骤的历史记录，这里主要是在"产品审核"时有"跟踪产品流程"需要查询每个阶段的产品相关详细信息的需求.

   同时，对于指令的工作流历史表，也是需要的，因为在"跟踪产品流程"时，点击详细的时候也需要把每个工作流阶段的指令信息分别显示出来.(因为在审核和配置步骤都可以对指令的信息进行修改)

   产品查询的详细信息页面中的workflow,workflowlife,status值，是根据product表中的workflow,workflowlife,status值读取资源文件中对应的name值来显示，而在产品审核信息一览页面中的产品状态信息则是联合查询引擎表中wkfw_session,wkfw_action_wkfw_reg和wkfw_action_reg表得到的.

 

 

还有一些地方有待进一步分析，继续补充中...