osworkflow工作流的workitem的一种实现方式

osworkflow是一个开源的工作流引擎，它提供了一种相对而言较为简单和灵活的实现方式，在oa和mis系统里是一个较为轻量级的解决方案，但是osworkflow只提供了一个引擎，大部分的功能都需要用户自己进行扩展。我在使用的过程中虽然陶醉于osworkflow所提供的极端的灵活性但同时也对osworkflow其他功能的匮乏而头痛不已，特别是workitem的缺乏尤其令我愤怒。

在网上搜索到一些实现方式大部分都需要用户自己维护任务列表，在复杂的业务流程中让用户自己实现任务列表简直让人抓狂，在仔细研究了oswf自带的数据表后，我决定使用oswf的数据表实现任务列表功能，具体的使用方式是在业务数据库中加入一个enteyId字段，代表该记录使用的是哪个流程。在这条业务记录的流程开始初始化时将流程实例的id号放入业务数据记录的enteyId字段。在业务表中加入一个state字段，记录这条业务记录的状态，使用这种构造的优点是将业务数据的状态与工作流的状态分离，业务记录的状态不再依赖工作流表（os_currentstep）所提供的流程状态，即便整个业务流程已经结束，os_currentstep表中不再显示该业务流程的步骤信息，业务数据依旧能够依靠自己的状态进行显示；缺点是业务数据在流转过程的每一步中都需要依靠代码更改业务数据的状态字段，用户必须事先定义好业务数据状态的表示方式，业务记录的状态在修改和显示时根据用户定义好的表现方式进行操作。

将os_currentstep作为任务列表，要实现这个功能，用户需要添加一个“OwnerUserRelation”表，用于将步骤操作员与业务系统中的用户进行关联，操作员与用户的是多对多的关系，即一个操作员可以包含多个用户，其中任意一个用户都可以进行操作；一个用户也可以是多个操作员，他可以操作一个流程的多个步骤。通过关联查询，系统可以为用户提供任务列表（"SELECT ENTRY_ID ,state,业务数据字段 from 业务数据表 pra left outer join OS_CURRENTSTEP prb on pra.entryId=prb.ENTRY_ID left outer join OwnerUserRelation prc  on prb.OWNER = prc.ownerId where prc.userId='"+strUserId+"'"），使用这种实现方式的优点是用户不需要再维护自己的任务列表，不用再考虑复杂的流程在workitem中的实现，同样缺点也很明显，使用这种实现方式我们不得不将业务数据与oswf工作流的数据表进行紧耦合。