1,流程结束后会自动删除execution表中的数据和task中的数据.但是不会删除deployment和deployprop表中的数据。而且task数据会自动加入到history表中。
2.若加了repositoryService.deleteDeploymentCascade(deployId)方法。会将history中的数据也删掉.
3.在流程中processInstance和execution的id号相同.
4,task查询可以通过query进行。而且对task的属性的设定,还要增加taskService.save()方法,才能将数据加入到数据库中。
5,task表中的dbversion是task的更改的次数,也就是当task被taskService.saveTask()持久化一次dbversion就增加1,每次参数的保存都要用到taskService.saveTask(),否则只能在内存中。一个task在立个流程的流转过程中dbid有可能会变,比如说之间拒绝时,但是一般情况下不会变(正在思考为什么)。id不变则变量也不会变。id变变量也会变,但是无论怎样execution-id都不会变。
6.jbom4和spring的集成中要删除jbpm.jar中的配置文件一小段。使他默认从appliance.xml中启动。
2.若加了repositoryService.deleteDeploymentCascade(deployId)方法。会将history中的数据也删掉.
3.在流程中processInstance和execution的id号相同.
4,task查询可以通过query进行。而且对task的属性的设定,还要增加taskService.save()方法,才能将数据加入到数据库中。
5,task表中的dbversion是task的更改的次数,也就是当task被taskService.saveTask()持久化一次dbversion就增加1,每次参数的保存都要用到taskService.saveTask(),否则只能在内存中。一个task在立个流程的流转过程中dbid有可能会变,比如说之间拒绝时,但是一般情况下不会变(正在思考为什么)。id不变则变量也不会变。id变变量也会变,但是无论怎样execution-id都不会变。
6.jbom4和spring的集成中要删除jbpm.jar中的配置文件一小段。使他默认从appliance.xml中启动。