内的jbpm3讨论

我会把内的jbpm3讨论的内容放到这里来，作为记录。今天这个基本上不能称“讨论”，主要是我一个人在说，想让群内的朋友在群内看到，而没有在群内的朋友，通过BLOG看吧。

群内以前还有很多记录，不过就不copy到这里来了。

“动态产生任务”在
jbpm3里面通过swimlane来实现
HongSoft(26929885) 18:33:13
public interface AssignmentHandler { String selectActor( AssignmentContext assignerContext ); }

HongSoft(26929885) 18:33:47
你实现这个接口的方法就可以了。
HongSoft(26929885) 18:34:29
你可以不用 AssignmentContext ，自己从你自己的数据库或者从另外的旧的系统中取出用户的数据
HongSoft(26929885) 18:34:50
就在这里可以替换掉jbpm3的user和group
HongSoft(26929885) 18:35:10
在processdefinition.xml中，
HongSoft(26929885) 18:35:24
<!ELEMENT swimlane ( description?, delegation? ) >
HongSoft(26929885) 18:36:01
为swimlane指定一个delegation，而这个delegation就是你的assignmentHandler
HongSoft(26929885) 18:36:27
这样就替换了jbpm3自己的User
HongSoft(26929885) 18:38:09
而且，包括os在内，自己组织也有个User，但也没有用。在中国，业务流程软环境没有整理好，来上工作流系统硬环境，导致很多的特殊情况，所以，老外写的User，在国内肯定是不能用的。
HongSoft(26929885) 18:39:40
所以，我们谈BPM，关键的还是业务流程重组，然后再来做实施；其实业务流程重组才是关键。
HongSoft(26929885) 18:40:00
这也是为什么SAP/oracle这么赚的原因。
IT浪子(41380364) 18:39:12
业务流程重组是理念，与技术无关！
HongSoft(26929885) 18:41:48
而shark呢，用role/group是可以实现同样的目的的，只不过，这个group应该是动态的；在agileflow里面，就是DynamicMapping
HongSoft(26929885) 18:42:52
其实对SAP的咨询顾问来说，经常自称做技术的。他们的技术不需要用我们这些软件巴了。
HongSoft(26929885) 18:44:25
当然，技术也是很重要的，我就选的这个；我只是说，业务流程重组做好了，才能真正理顺后面的事情。从技术开始理顺流程，是不行的。
HongSoft(26929885) 18:45:32
业务流程重组，在咨询行业来做，能否做好，这个很值的怀疑。
HongSoft(26929885) 18:46:27
需要看自称有理念的人是否真的有理念，还是只会侃
IT浪子(41380364) 18:44:44
技术应该处于被决定的地位，现在却恰恰相反！无奈！
HongSoft(26929885) 18:47:11
被决定的地位？
IT浪子(41380364) 18:45:37
理念决定技术！
HongSoft(26929885) 18:48:57
对的。我们现在其实也是这样。错误的理念决定技术。而这个错误的理念往往定性为合理化需求。
HongSoft(26929885) 18:49:44
其实，如果有这么多的特殊的合理化需求，老外会去做什么osuser吗？
HongSoft(26929885) 18:50:48
不过这个我们决定不了，还是安心做事情吧。：）
HongSoft(26929885) 19:05:02
今天找到jbpm3的system了，以前好象没有
HongSoft(26929885) 19:05:28
jbpm3的actor现在分为3类：System,User,Group
HongSoft(26929885) 19:07:44
而且看样子，jbpm3准备做web形式的流程定义
HongSoft(26929885) 19:08:12
而且能够在运行中直接tune the process definition
HongSoft(26929885) 19:12:19
不过还好，流程实现与流程modeling有很大关系，这个是我们的得分点