工作流系统中增加“业务活动”这一概念的想法
这样我们在为业务流程建模时，首先是定义“业务流程”，其次应该是识别流程中有哪些“业务活动”，并为“业务活动”定制一些属性，最后才是定义具体的流程。使用一套已经建立好了的“业务流程”来定制流程就变得非常的轻松，流程上关联业务流程，活动上关联业务活动，这样所有与业务相关的属性就都可以设置好。
先前版本的工作流将活动上不管是与业务相关的，还是与流程相关的属性一齐混杂在流程设计器上。这种实现方式有几大弊端：1、无法实现同一业务概念的复用，在一个活动上定的业务概念，需要在另一个相同业务意义的活动上原封不同的重定一遍。虽然我们实现了活动的复制，但我认为这种复制不是解决这种业务意义复用的很好方式。2、所有的与业务相关的实体都是独立于工作流系统之外的，在定义流程时将这些业务实体的设置记录在流程定义中。由于流程的版本控制，先前已经运行的流程定义是无法改变的，而业务实体又可能是会发生变化的，如单据的字段权限变化了（对于自定义表单这样生来就是为适应变化的，就更容易发生变化了），构件的参数又增加了一个等等，致使流程运行时业务上的改变得不到及时的体现，甚至运行不下去。3、流程运行结果，更通俗的讲可能是审批的结论、意见不能根据业务意义进行分类，明显的体现是审批结果打印时，所有的意见结论都罗列在一起（这个需求来源于OA项目组）。
哪些活动属性应该放到“业务活动”上，我认为表单定义、表单权限设置（动作权限、字段权限），其他象外部工具、规则等也可以考虑放进来。
工作流可以无区别的对待普通流程和OA使用的动态流程的权限设置，都包括表单参数设置、表单动作权限的设置、表单字段权限的设置。
值得一提的是，像加签、会签、跳转等权限，我认为是纯粹的流程权限，不应该去表单的权限混为一谈，可以强制识别这些的流程引擎提供了的流程动态功能，并为其设置权限。
对特殊性、向下兼容的考虑，在流程定义上仍然保留这些在“业务活动”添加的属性，在使用时首先查找具体活动上的定义，再查找业务活动上的定义。这样的同一“业务活动”对应的活动也可以有完全不同的特性，而且对于老版本的流程定义，即使没有在活动上关联业务活动，仍可以正常运行。
