关于基于 delphi 工作流程引擎的讨论贴。。有个同事以前在神州数码，通过自己的理解把osworkflow java转为.ne
关于基于 delphi 工作流程引擎的讨论贴。。
有个同事以前在神州数码，通过自己的理解把osworkflow java转为.net，我有个想法能不能咋自己把osworkflow转为delphi版的。
有没有做过类似工作的朋友给点建议，delphi有没有线程的流程引擎？
[解决办法]
也不懂java and .net
等待各位老大出现，然后学习
[解决办法]
哦 原来如此
[解决办法]
个同事以前在神州数码，通过自己的理解把osworkflow java转为.net，我有个想法能不能咋自己把osworkflow转为delphi版的。
有没有做过类似工作的朋友给点建议，delphi有没有线程的流程引擎？
[解决办法]
i don't know yet
[解决办法]
纯Delphi飘过
[解决办法]
纯支持~~
[解决办法]
关心该话题讨论
[解决办法]
haenmhao
[解决办法]
和前面的不同。。
我不懂delphi
[解决办法]
支持你！@！！！
[解决办法]
delphi有没有线程的流程引擎？
还是
delphi有没有现成的流程引擎？
做肯定是能做的，没现成的。。。
[解决办法]
DEv控件组中有一个流程设计的控件 做得挺好的 楼主要的都有
[解决办法]
5、6年前，用delphi给客户的深圳公司做过一个，口碑不错，后来客户总公司也上系统，基本参考借鉴了这个原型
但是具体实现，因为客户财大气粗，指定要oracle+weblogic
200万能搞定系统，成了1000多万的了
自己总结了一下，关键在于 流程系统和业务系统 的和谐共存
客户自己新上业务、旧业务增减业务字段，流程系统无须任何修改
后期提交给客户的IT人员自行维修，基本也没有什么问题
但是，有一个基本的“缺陷”：流程无法回退！
这个是业务决定的，因为有些流程可能会导致业务数据的复杂变化，而这些变化已经影响了其它相关但是不应该撤销的业务了，想回退是根本不可能的
[解决办法]
让他一人同意以上
[解决办法]
同一人
[解决办法]
是可以转过来，不过要比较了解流程,还要对delphi很熟悉
[解决办法]
delphi好像不错
[解决办法]
[解决办法]osworkflow还是比较容易看懂的，改成delphi应该不难
[解决办法]工作流的难点并不在引擎的实现上，而在引擎的性能和稳定性，及可视化流程定义、监控等
[解决办法]围观一下，我现在也是在用JAVA下的WORKFLOW
[解决办法]围观一下，我现在也是在用JAVA下的WORKFLOW
[解决办法]我们用FLEX+JAVA +EXTJS 开发了一个工作流引擎定义器
所有的流程用户都可以自己进行配置 节点，条件什么的都可以直接设置
流程是自己 在配置区间 里面直接 拖放节点组件、关系链接线 就可以了
[解决办法]不好搞。
------解决方案--------------------
高人可以试试看。
[解决办法]我认为这个要在设计时好好规划的
不然，后期重写的可能性还是有的
别外，现在的工作流都是以WEB方式工作的，楼主想用DELPHI，应该不行，或难度太高。
qq:295286073
[解决办法]不好搞。
[解决办法]起步好像有，不过用delphi做OA的似乎并不多
[解决办法]关注，楼主开源搞一个吧。
[解决办法]围观一下，我现在也是在用JAVA下的WORKFLOW
[解决办法]评价评价
[解决办法]对工作流一直都有兴趣，但是从来木有搞过，旁观
[解决办法]并不是因为难，而是因为很少用delphi做oa
[解决办法][解决办法][解决办法]【实现不了】还是【实现得了】，不能作为标准
管理数据库的人，习惯用sql实现一切；熟悉pb的人，也习惯用pb实现一切；熟悉vba的人，也习惯用vba(excel/access)实现一切
一般的讨论，是针对普通、容易找到的应用开发人员，他们实现起来是否容易
如果各个工具、语言的高手，基本上都有办法用他熟悉的工具、语言来实现（几乎）一切
关键是很多地方，用delphi实现起来，相比用java，可能会 开发快5-20倍，运行效率快2-10倍
如它所述： http://topic.csdn.net/u/20110129/00/6f4795ad-5b40-460b-abe8-10424abe5cb4.html
[解决办法]大难题，同样求解
[解决办法]我也在学delphi
[解决办法]关注。
[解决办法]osworkflow都是基于网络支持来工作的，用delphi来做，没有任何意义！要是实现肯定能做到，只不过一点实际运用意义都没有！
[解决办法]这个贴是怎么成精华的
不明白
[解决办法]没有用过osWorkFlow，但做过工作流。感觉好象没有那么玄啊？
1.对于任何一项工作，都有两个种类（正常业务、非正常业务），由流动起点确定，正常业务流动节点（涉及的组织机构）基本固定，对于任何一个节点而言，信息只有两个流向（流出和待命），三个工作状态（收到、处理中、完毕），两个流通状态（正常、异常）。非正常业务的流动节点不固定，可以跳跃性选择流通节点。
2.对于正常的节点，可以由用户定制并允许修改流程以减少输入和调整量。无论正常非正常的业务，需要建立合理的追踪机制。
3.第1条中所涉及的状态根据行业客户性质不同可进行细分和扩展。
那这条信息该流通到哪儿、谁该看得到就一目了然了罢？
个人感觉：工作流模块的设计关键在于灵活和追踪，在此基础上配合规章制度不断扩展功能并增加其易用性，不要人为地学究地把东西先搞复杂，再想减下来就难了。这需要与用户的沟通技巧，非三言两语能够说得清楚。另外，不是越复杂的东西就越好用，傻瓜式的软件才是工作流的发展方向。
实践中的设计：1.区分工作任务，定制相关固定流程（用户可自行定制）2.针对每个工作任务各个环节的流动协助客户建立相应规章制度。3.根据规章制度规定，确定各环节能够掌握的信息量，可进行的操作。4.根据各个环节用户的处理圈定工作信息状态。由此：封装四个类，TWork/TFlow/TUser/TPoint,其中TWork中具备流动环节(TFlow)、当前环节、上一环节、下一环节、处理状态、处理结果几个属性，TUser封装权限及其它通用属性，TFlow封装固定流程、实际流程属性等等，TPoint封装处理意见、处理结果、流出方向等等。一项工作的流动基本就OK了
结合之前的工作经验，能记起来也就这么多。同志们有什么想法，欢迎板砖。至于如何去表现流程，那属于另外的题目，不加啰嗦：）
