浅谈Activiti Modeler 的扩展

• 为什么要扩展

        最近项目打算用activiti工作流中activiti modeler来做模块的可视化订阅，但是原生的activiti任务节点，有一些不符合业务需要，比如

• • 配置项多，属性暴露。比如service task,配置时就要暴露其Java Degelete方法类，这样以后实施人员去配置的时候，第一他每次去配个service task都要去配置，第二他不会知道这个任务要配什么委托类，所以这对职责单一的一个service task来说，比如就需要一个解析xml的任务，那么我除了id ，name，其他都是不需要的，内部封装属性，不暴露出去。
  • 图标单一，一眼看不出任务职责。
  • 子流程内容跟父流程内容在一个面板，流程定制面视觉效果不好，而且固定子流程不能得到复用。

            对以上一些不足，其实对activiti来说，他要考虑的当然是多开放配置，更容易兼容场景，或许有些人会认为这都不是事，做这种扩展没有必要，大题小作。仁者见仁智者见智吧，我认为这种扩展，

            对使用会更便捷，用户友好性也更好，具有一定的业务特色，也不改变原生activiti任务的职能，何乐不为。

• 如何扩展

         首先考虑一下可行性，这种扩展以什么为切入点。扩展任务节点，那就得发现service task这个任务的特性，它不想user task,script task的只能那么单一，它可以指定委托处理类，来达到执行目的。

          因此，在任务定制这方面，完全可以由service task进行属性扩展和封闭。具体扩展细节，如下考虑

 

　　　　 

          那么还有一个难题，就是子流程的改造，原生的子流程是一个类似于容器面板，里面可以再放一个流程；现在的想法是，讲子流程变成类似任务节点的一个节点独立展示，这个节点可以通过属性来关联到子

          流程，这个子流程可以自成一个模型，用属性关联达到复用，实现构思还是基于原生子流程节点进行改造

 

         

• 编后语

       在子流程这方面需要考虑的还很多，比如后续的流程跟踪该如何处理，以及上述部署组装bpmn文件的坐标问题等。这要继续看下activiti源码（ps:activiti 源码写的很漂亮，very  good,建议去看，

        然后一起探讨），后续会更新一些现有的实现。