ding...........

为啥不基于现有的开源工作流引擎做呢？现有的开源工作流引擎不符合要求？至少能重用一部分吧？

可能中国的software developer太廉价了.
自己写一个也不用花多少钱.

主要是现有的无法满足商业化需求

你好，可以向你请教请教Ofbiz方面的东西，关于工作流的。多谢哦。
我的qq是：126548294，msn是shuimoairen@hotmail.com

好

轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用数据的定义和完整性维护、完善的异常处理以及长事务控制等功能。
我们之所以采用“轻量级”这一特征来刻画工作流引擎主要出于如下考虑：
1）许多现有的工作流产品都在不同程度上提供了对外部工具的集成功能，部分产品还提供了基于表单的应用逻辑的定制和开发环境。但是，外部工具的多样性和复杂性决定了对外部工具的集成难以做到无缝；而工作流产品内建的开发工具除了与流行的开发工具不兼容外，其开发功能往往都比较简单。因此，对于简单的应用（例如公文流转、订单的审批等），这些产品是合适的。但是，如果是开发关键业务的应用系统（特别是行业应用系统），现有工作流产品所能提供的开发功能是远远不够的。
2）许多针对DBMS的开发工具提供了极强的应用开发手段，但是这些开发工具往往不具备对工作流的机制的支持，而现有的工作流产品由于其出发点不同，很难与其他开发环境有机地融合在一起。因此开发人员往往苦于找不到一套合适的工作流支撑系统来开发具有工作流特征应用。
3）具有工作流特征的应用的形态千变万化，要想在工作流系统中对不同的应用（包括应用数据）进行统一的表示往往不遂人意。利用这种所谓灵活的工作流系统开发出来的应用在实际运作过程中反而表现不灵活。因此，另外一种相反趋势是，应用的逻辑仍旧由专用的应用开发工具去完成，工作流引擎只管理相关的控制数据，对应用数据只提供必要的关联手段将其与控制数据联结在一起。
4）目前已经有许多中间件产品（各种应用服务器、TP等）提供了对应用事务包括长事务的控制能力，对事务控制有特殊需求的应用系统可以使用这些产品。
――摘自《基于关系结构的轻量级工作流引擎》

ding
希望这个话题能继续深入讨论下去……

用过osworkflow吗，你可以试试，它用java GUI设计工作流，生成xml后在做相关处理。自己定义的代码很少。值得推荐。


http://www.opensymphony.com/osworkflow/

这是它的ＧＵＩ 工具
http://www.opensymphony.com/osworkflow/designer/designer.jnlp

gongyj,你们用的是windchill吧~~~上家公司也用这个,可惜当时我水平太差了,错过了研究的好机会,真该把windchill刻录一套的~~~~:(


鼓弄工作流已经一年多了（呵呵，不敢说是研究^_^） 没有使用的过workflow的相关工具和组件，纯粹属于在实践中摸索。在开发的初期，对应性能方面的要求远低于对功能上的要求，所以就采用了简单的jsp 、applet 附加 javabeans的模式 。

对于工作流，相关理论确实较为贫乏，但自己做得相关项目以及和客户交流研究讨论的各类业务流程比较多，所以实际业务体会还是有的，我们粗陋的工作流母体也就在这样的情况下诞生和逐渐成长的。

在业务流程中，着重体现是：第一，工作流的流向，即环节之间的顺序； 第二，环节中处理的人员选择；第三，工作流中每一环节的动作。

工作流的流向。这个问题粗看很简单，无非是环节之间的顺序嘛，诸如“环节一”的下一环节 为“环节二”和“环节三”。但实际业务运转中，却会存在更为复杂的情况，诸如在正常情况下，“环节二”是“环节一”的下一环节，但在环节二的人员都处于无效状态（诸如出差）的时候，“环节三”成了“环节一”的下一环节；或者是定义的审批流程中，环节一是填写报销单，环节二是提交科室领导审批，环节三是提交主任审批，对应一般职员，是环节一到环节二，再到环节三，而如何自身是科室领导，就可以从环节一直接跳转到环节三。

工作流环节的人员选择。在工作流中处理的业务，在定下流向之后，就是要解决提交的人员对象了。每个环节可能对应的相关处理人员各自不同，需要根据处理的步骤的特定情况去定义，静态的，可以按照具体的人员，具体的部门和相关职位去定义；同时会根据业务的需要，定义动态的对应关系，这个就需要引入相关的选择机制，诸如相对角色，一份文件初始审批领导，在第一次确定了其审批领导身份后，所以的相关审批程序，都会提交到他的手上，而不是其他不知情的领导。

每一环节的动作。这里我说的环节动作是宏观的概念，具体还可以划分为环节中用户的行为，以及后台工作流引擎需要完成的动作。其实个人认为一个工作流引擎优秀与否，最重要就体现在这个方面，因为一般流程的流转、通知等机制很容易设计现象，且从业务层剥离成为稳定独立模块的难度较小，但对应每一环节的动作事件的处理实现方式，却是很难抉择的。过于细化，可以很好的实现系统的功能，但危害到工作流引擎的独立灵活性，但如果做得过于独立，又难以实现某些具体的业务功能。 在业务工作流中，每个环节一般分为表格的浏览操作，但表格的浏览操作一般都与业务某些具体指标有关，诸如某些统计数据的修改，公文的正式成文等等。我现在采取的方式，外加环节操作定义表和环节动作定义表，分别设置环节中台帐用户需要的调用的操作和后台工作流引擎需要执行的动作，具体就是环节对应页面浏览的表格以及相关数据格式定义在一张表中，同时某些环节触发的特定动作，定义在另外一张表格，由后台程序监管并执行。

以前是个人从实际业务出发设计的做法和思路，肯定有不少错漏，希望和大家多多交流。^_^

同时感觉理论的东西确实很重要，只要正确的理论才能指引正确的方向，但具体到现实，我们最好还是要作出真正可以要发挥作用的产品，所以不能拘泥与先进理论的讨论而忽略实践 ^_^ 个人意见 ， 敬请指正

BTW 上面post的是俺第一次在这里的发文，心情有些激动 ：）

==人认为一个工作流引擎优秀与否，最重要就体现在这个方面，因为一般流程的流转、通知等机制很容易设计现象，且从业务层剥离成为稳定独立模块的难度较小，但对应每一环节的动作事件的处理实现方式，却是很难抉择的
================================================================

同意你的观点，我也有同感呀

上页
下页