工作流设计和开发小谈

2008-08-07
工作流设计和开发小谈
关键字: 工作流 java ext

工作流设计和开发小谈
Author：yongtree
         现在每天都很累，写作的热情并没有像夏天的火热一样燃烧起来。OA的工作流已经算完成了三分之二了吧，还有传阅和自动路由将在随后的几天和未来的版本升级中逐渐的完善，一直想总结一下，总是被其他事情占据着。今天困的实在不行了，正准备拥抱睡美人的时候，鬼使神差的又看了一下javaeye，看到了一封请教工作流的邮件，本着对朋友负责的态度，让我顺带的写了这个工作流开发的总结。
        

引用

您好！最近看到了您发的帖子 http://www.iteye.com/topic/211321。我最近也新分配了个web OA的项目。但是我对工作流的东西完全不懂，看了你的帖子后发现您的工作与我将要做的有些相似。因而有些问题想请教下您，希望您有空的话能够帮忙解答下，十分感谢！（因为我对工作流还没很清楚的概念，因此下面问的这几个问题本身可能会有些误区，如果有的话，希望您能够纠正下我认识上的错误。 ^_^ ）
1. 自定义的表单如何与后台数据库相关连的呢？是一个表单对应于数据库中的一个表还是其它的方法？
2. 在流程的流转过程中，不同的节点对应着不同的动作，如“发布”、“核对”、“审批”等。这些不同的动作也是放在了自定义表单之中的吗（比如说表单中有三个按钮分别对应这三个动作）？如果不是的话，那么如何保证在不同的节点时有不同的动作呢？
3. 比如说我新发布了一个“请假”的流程后，那么，对于具有“申请假期”权限的用户而言，在web页面中肯定得新添加一个“申请假期”的菜单，通过点击此菜单来进入“申请假期”的页面，否则的话用户无法对这个新的流程进行操作。这一点是要如何实现呢？即后台新建的流程如何为用户的页面添加相应的菜单项？ 

         上面便是朋友在邮件中的一些问题，自己其实也没有太多的经验可以分享，通过工作流的开发和设计，来谈一下自己对工作流的认识吧，希望能给朋友一点帮助。
         我们KOA中工作流部分可以说是我进入公司以来，或者说是毕业以来，真正倾注自己心血的一个项目。刚毕业，就接受了这样一个严峻的考验，自己也非常的重视。在开发工作流之前，自己可以说是对工作流一无所知。前期主要是了解、调研工作流系统，通过研究我明白了工作流系统在企业系统中的作用和所处的地位，从技术的层面上，工作流系统应该独立于业务系统，以中间件的形式存在。调研了陕西协同和东方易维的工作流系统，自己进一步了解了工作流系统。对于工作流的功能、难点都有了初步的掌握，当然前面说的那两个都是国内有名的工作流平台产品，功能性和实用性都非常的强大，但是对于每个系统都要有自己侧重的地方，工作流的开发也应该遵循实际的需要来开发，否则便会走上大而不实的歧途。对于.net平台下的工作流，微软公司好像提供的强大的支持，但是在java领域内，多数还是以一些开源的工作流引擎为主，像osworkflow,jbpm,shark这些老牌的工作流引擎，仍然在java领域占有很重要的地位。虽然这些工作流引擎非常强大，有的还提供了图形设计器的功能，但是掌握起来还是有点难度，作为轻量级的工作流系统，完全也没必要使用这些庞大的工作流引擎，所以我们决定自己独立设计和实现工作流引擎。
         根据WFMC制定的标准，流程过程描述采用XPDL，简单的说就是采用XML来描述流程过程定义。作为轻量级的工作流实现，我们采用数据库和XML相结合的方式进行设计。XML主要用来描述流程的过程，而过程信息全部保存在数据库中，包括XML描述的过程也保存在数据库中。而且工作流中的运转也通过数据库的关系而实现，XML主要用在图形设计和展示是使用。本着作为中间件的思想架构系统，我采用工作流系统和OA系统没有进行强制的关联，两个系统之间的交互和数据交换采用系统间的接口进行实现。根据WFMC的规范，我设计的工作流引擎实现了五个接口的三个：流程定义接口，流程实例接口，组织机构及参与者接口，工作流没有自己的组织机构模型，通过提供的接口来调用业务系统组织机构的数据。通过JS和xml结合实现简单的图形化设计器，通过对fck在线编辑器的改造，结合数据库的数据存储，实现自定义表单功能。其实大家在设计工作流的时候最好能根据自己业务的需要，那些功能需要，那些功能不需要，那些功能应该砍掉，都应该有一个非常好的判断，并不是越大越好，因为对于你所服务的用户，让他们用的方便这才是最重要的。
         唠叨了这么多，针对朋友提的问题，开始简单的阐述我自己的看法。对于自定义表单，肯定需要有一个非常好的物理结构来进行支持，我们看到的表单只是表现形式上的表单，但是在数据的运作中，良好的数据库设计可以很好的实现我们想要的效果。对于自定义表单的结构我们当时想到了两种结构。第一种就是一个表单对应着数据库中的一个表，这对于我们来说最好理解，因为我们开发地绝大部分系统都是这样的结构，但是这对于自定义表单非常的不灵活，所谓自定义表单就是我们能自己随意的定制，而一个表单一个表的结构就非常的固定，需要我们在新建表单时要生成对应的数据表，这在系统的运行中是非常不合适的，如果不想改动程序而实现对表的查询、存储的难度非常大，所以这种方案我认为非常不好。第二种解决方案就是数据库结构尽可能灵活，所以我们把表单进行拆分成表单信息表，到字段信息表，表单实例表，表单字段数据表。通过多表之间的关联，达到灵活处理的目的，并且不受用户自定义表单的影响。第二个问题，我的观点是，工作流和表单也应该是具有一定独立性的，之间通过接口进行交互。表单的主要工作是实现业务数据的存储，而工作流的主要职责是流程的运转，所以动作应该在流程节点上，而不是在表单上。具体每个流程节点对应的表单的只读和隐藏字段的权限，我们只需要在流程设计的时候绑定表单字段和流程节点关联的权限即可。对于第三个问题，我采用的策略是，对于流程分类可以设置访问权限，对于流程可以设置发起者的权限和监管者的权限，对于各个节点可以设置参与者的权限。在有上下级的关系中，权限是具有可继承的，如果上一级你都没有权限，下一级即使没有设置权限，你也没有访问的权限。通过这样，我们就可以通过对用户权限的设置，在前台获取的用户有权限的数据。有些数据你没有权限，菜单上当然就不显示，只显示你有权限的菜单。
         不知道这样的解释，大家能不能清楚，由于自己水平有限，也无法深层次的去讲解，希望更多的人能参与进来讨论，让我们的思想因为你的参与而不断地升华。



（该文章作为百洋软件创作实验室官方发布文档，版权归作者本人所有，如有转载请注明出处，谢谢。百洋软件创作实验室官方网站正在积极筹建中，敬请关注）

评论

1 楼 yongtree 2008-08-12  

呵呵，我的文章被你转过来了，我感到非常荣幸啊。多谢支持