应用开发平台集成工作流系列之16——办理意见设计与实现

背景

流程任务流转过程中，各环节的处理，会填写处理意见。
Camunda自带了相关的功能，但功能过于简陋，问题较多，今天来说说这一块。

自带功能的问题

如使用Camunda官方自身的办理意见相关功能，会遇到两个问题：
1.因为指定环节跳转，使用了cancelActivityInstance，所以存在部分历史任务状态为deleted，需要过滤掉该部分数据
2.任务转办，需要查询并显示状态为未结束的任务环节相关审批意见（任务转办只重新设置审批人，不会重新生成1条新的任务）

使用官方自带的api，如下，始终无法拼接生成有效的sql语句

    HistoricTaskInstanceQuery query = historyService.createHistoricTaskInstanceQuery();
    query.processInstanceId(id).taskDeleteReason(WorkFlowConstant.TASK_DELETE_REASON_COMPLETE)
    .or().taskDeleteReason(null).endOr().orderByHistoricActivityInstanceStartTime().asc();

生成的sql语句如下：

==>  Preparing: select distinct RES.* from ACT_HI_TASKINST RES WHERE ( 1 = 1 and RES.PROC_INST_ID_ = ? and RES.DELETE_REASON_ = ? ) and ( 1 = 1 ) order by RES.START_TIME_ asc LIMIT ? OFFSET ? 
==> Parameters: a1624965-e050-11ea-a4ec-8c1645df7f9d(String), completed(String), 2147483647(Integer), 0(Integer)

即api无法支持查询null值，推测碰到null值会自动忽略

转而采用native查询来实现

  NativeHistoricTaskInstanceQuery query =historyService.createNativeHistoricTaskInstanceQuery()
            .sql("select * from act_hi_taskinst where PROC_INST_ID_=#{processInstanceId} " +
                    "and  (delete_reason_=#{deleteReason} or delete_reason_ is null)  order by start_time_ ")
            .parameter("processInstanceId",id)
            .parameter("deleteReason",WorkFlowConstant.TASK_DELETE_REASON_COMPLETE);
  

以上代码能获取到期望的审批历史，但是……仍然存在问题：
1.任务转办后，查出任务历史直接是被转办人，例如张三转办给李四，在李四处理前，显示该环节为李四，但审批意见是张三写的，看上去很诡异
2.任务转办处理后，显示任务是李四处理的，张三和李四的审批意见做了拼接，依旧很诡异，看上去张三仍然在流程处理过程中但什么也没做，实际原本流程处理人就是他，并由他进行了任务转办。

任务委派也出现复用任务的情况，导致流程处理过程不清晰，不显示某些实际参与流程处理的人，以及合并显示审批意见的情况出现。

基于以上几点，还是自己实现审批意见表比较合适。

自行设计与实现

实体配置

实体属性

常用处理意见

通过平台数据字典功能，配置常用的处理意见，用于快速填充

数据写入

在任务处理等环节，弹出对话框，由用户录入办理意见或通过常用处理意见下拉列表快速填充

任务处理时，调用办理意见的服务接口，写入数据，以任务提交为例：

 /**
    * 新增处理意见
    * @param processInstanceId 流程实例标识
    * @param nodeId 环节标识
    * @param nodeName 环节名称
    * @param comment 处理意见
    * @param commitType 提交类型
    */
   void addComment(String processInstanceId,String nodeId,String nodeName, String comment, CommitTypeEnum commitType);

  @Override
    public void addComment(String processInstanceId,String nodeId,String nodeName, String comment, CommitTypeEnum commitType) {
        WorkflowComment entity=init();
        entity.setProcessInstanceId(processInstanceId);
        entity.setNodeId(nodeId);
        entity.setNodeName(nodeName);
        entity.setComment(comment);
        entity.setCommitType(commitType.name());
        add(entity);
    }

流转历史

在流程流转期间以及流程结束的查看页面，通过办理意见表，可以直观地看到该流程实例的流转和处理情况，如下图所示：

前端封装了一个通用组件

<template>
  <el-card>
    <template #header>
      <span>历史</span>
    </template>
    <el-timeline>
      <el-timeline-item v-for="(step, index) in steps" :key="index" type="success" size="large">
        <div style="font-weight: bold">{{ step.nodeName }}</div>
        <div>{{ step.assigneeName }}</div>
        <div>{{ step.commitTypeName }}</div>
        <div :title="step.comment">{{ abbreviate(step.comment, 20) }}</div>
        <div>{{ $dateFormatter.formatUTCTime(step.commitTime) }}</div>
      </el-timeline-item>
    </el-timeline>
  </el-card>
</template>
<script>
import { abbreviate } from '@/utils'
export default {
  data() {
    return {
      // 历史信息
      steps: [],
      queryParams: {
        processInstanceId: '',
        sortInfo: {
          sort_field: 'commitTime',
          sort_sortType: 'ascending'
        }
      }
    }
  },
  methods: {
    abbreviate,
    view(processInstanceId) {
      this.queryParams.processInstanceId = processInstanceId
      this.$api.workflow.workflowComment.list(this.queryParams).then((res) => {
        this.steps = res.data
      })
    }
  }
}
</script>

<style scoped></style>

调用的后端方法就是标准的获取办理意见的列表，按提交时间升序排列即可。

此外，流程中可能存在上传附件的需求，跟办理意见类似，Camunda也有这方面功能支持，同样支持的不好，我们平台的表单自身就能处理附件，不使用Camunda的附件相关功能。

开发平台资料

平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
开源不易，欢迎收藏、点赞、评论。