jbpm流程部署之部署服务相关对象扩展

jbpm流程部署之部署服务相关对象扩展

       流程部署服务是流程引擎提供给外界的调用接口，用于外部完成部署相关任务来使用，比如发布流程定义、通过流程名称或者流程ID获取流程定义等，所以说流程部署服务是流程引擎部署对外的门面。流程部署服务相关对象涉及到RepositoryService、RepositorySession、RepositoryCache，今天我们来体验一下JBPM在这方面的扩展性。

       扩展RepositoryService流程部署服务

       如果流程引擎提供的部署服务接口不能满足我们的业务需求，那么我们可以继承流程引擎服务RepositoryServiceImpl(当然我们也可以直接在这个类里边添加，这种方法比较简单)，进行自定义扩展；

       如果我们只是需要修改先前发布服务的接口实现，那么我们只要简单的继承RepositoryServiceImpl就可以了，这样我们就可以避免直接修改原有的代码。但是对于我们需要增加新的部署服务接口，那么需要先在RepositoryService中添加，然后也需要在RepositoryServiceImpl中进行override，最终在我们新的类中实现业务功能，但是这样就对原来的代码进行修改了，我也没有想到别的好的办法！  或者我们直接在我们继承RepositoryServiceImpl的子类中新增我们的接口和实现，这样我们就不用修改原来的类了，但是我们需要在调用新增的接口时进行强制类型转化，这是我们需要付出的代价吧。    

       在RepositoryService中新增我们需要新增的接口          

  //add by 无风听海
  String getProcessDefinitionKey(String deploymentId);
  String getProcessDefinitionId(String deploymentId);  
  //end

      然后我们需要在RepositoryServiceImpl中进行override     

@Override
public String getProcessDefinitionId(String deploymentId) {
    // TODO Auto-generated method stub
    return null;
}

@Override
public String getProcessDefinitionKey(String deploymentId) {
    // TODO Auto-generated method stub
    return null;
}

        新增我们新的部署服务实现类WFTHRespositoryServiceImpl 

package org.jbpm.pvm.internal.repository;

import org.jbpm.api.RepositoryService;

public class WFTHRepositoryServiceImpl extends RepositoryServiceImpl implements RepositoryService {
        
    public String getProcessDefinitionId(String deploymentId) {
        // 我们自己的实现
        return null;
    }

    
    public String getProcessDefinitionKey(String deploymentId) {
        // 我们自己的实现
        return null;
    }
}

       然后新增WFTHRespositoryServiceBinding

package org.jbpm.pvm.internal.wire.binding;

import org.jbpm.pvm.internal.cmd.CommandService;
import org.jbpm.pvm.internal.repository.RepositoryServiceImpl;
import org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor;
import org.jbpm.pvm.internal.wire.descriptor.ReferenceDescriptor;
import org.jbpm.pvm.internal.xml.Parse;
import org.jbpm.pvm.internal.xml.Parser;
import org.w3c.dom.Element;


/**
 * @author 无风听海
 */
public class WFTHRepositoryServiceBinding extends WireDescriptorBinding {

  public WFTHRepositoryServiceBinding() {
    super("WFTH-repository-service");
  }

  public Object parse(Element element, Parse parse, Parser parser) {
    ObjectDescriptor descriptor = new ObjectDescriptor(RepositoryServiceImpl.class);
    descriptor.addInjection("commandService", new ReferenceDescriptor(CommandService.NAME_TX_REQUIRED_COMMAND_SERVICE));
    return descriptor;
  }
}

        修改jbpm.wire.bindings.xml,加载我们新增加的WFTHRepositoryServiceBinding       

  <!--mod by 无风听海-->
  <!--  <binding class="org.jbpm.pvm.internal.wire.binding.RepositoryServiceBinding" />-->
  <binding class="org.jbpm.pvm.internal.wire.binding.WFTHRepositoryServiceBinding" />
  <!--end-->

        然后我们需要配置一下流程引擎初始化的时候加载一下我们新的部署服务，我们需要修改jbpm.default.cfg.xml       

  <process-engine-context>
   <!--mod by 无风听海-->
   <!--  <repository-service />-->
   <WFTH-repository-service />
   <!--end-->    
    <repository-cache />
    <execution-service />
    <history-service />
    <management-service />
    <identity-service />
    <task-service />

    <object class="org.jbpm.pvm.internal.id.DatabaseDbidGenerator">
      <field name="commandService"><ref object="newTxRequiredCommandService" /></field>
    </object>

    <object class="org.jbpm.pvm.internal.id.DatabaseIdComposer" init="eager" />
    
    <object class="org.jbpm.pvm.internal.el.JbpmElFactoryImpl" />

    <types resource="jbpm.variable.types.xml" />

    <address-resolver />
 
  </process-engine-context>

      这样的话经过流程引擎的初始化，我们以后获取到得流程引擎部署服务就是我们新的部署服务了。

      RepositoryCache的扩展

      RepositoryCache对象负责流程发布后流程定义对象实体的缓存，这样的话在以后的流程实例流转的时候，我们就可以重用该流程定义，而不用每次使用时都访问数据库，这在一定的程度上提高了流程引擎的运行效率；RepositoryCache作为缓存，业务功能有限，很多的时候我只需要根据业务的需求进行扩展实现，并不需要新增对外接口；同时其扩展实现与RepositoryService相同，在此不再赘述；

     RepositorySession的扩展

     RepositorySession主要是用来完成流程部署过程中持久化的一些业务功能，其主要是与数据库打交道；所以说部署服务暴露的接口最终都是直接或者间接的与它有关联；虽然RepositorySession的扩展方式和前面的两个对象基本相同，但是还是有一些差别的， repositorySession关联了RepositoryCache和DeployerManager，后者主要完成流程定义的部署解析；同时对这些关联对象的绑定是在运行时实例化的时候动态绑定的，所以我们是不能直接在配置文件中配置的，比如部署交互的数据库、部署使用RepositorySession等；但是这并不是说我们不能对其进行扩展和定制，今天我们就来给他定制换个新的RepositorySession实现

     新建我们的WFTHRepositoryCacheImpl,其直接继承RepositoryCacheImpl    

package org.jbpm.pvm.internal.repository;

/**
 * @author 无风听海
 */
public class WFTHRepositoryCacheImpl  extends RepositoryCacheImpl {
    //override原来的方法，实现自己的业务需求
}

      我们新增WFTHRepositoryCacheBinding，在这里tagName我们既可以使用原来的标签，也可以使用我们新的自定义标签，前者的话我们不用修改jbpm.default.cfg.xml文件      

package org.jbpm.pvm.internal.wire.binding;

import org.jbpm.pvm.internal.repository.WFTHRepositoryCacheImpl;
import org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor;
import org.jbpm.pvm.internal.xml.Parse;
import org.jbpm.pvm.internal.xml.Parser;
import org.w3c.dom.Element;
/**
 * @author 无风听海
 */
public class WFTHRepositoryCacheBinding extends WireDescriptorBinding{

    public WFTHRepositoryCacheBinding() {
        //需要修改jbpm.default.cfg.xml文件，
        this("WFTH-repository-cache");    
        //不需要修改jbpm.default.cfg.xml文件
        //this("repository-cache");    
    }
    
    public WFTHRepositoryCacheBinding(String tagName) {
        super(tagName);        
    }

    @Override
    public Object parse(Element element, Parse parse, Parser parser) {
        ObjectDescriptor objectDescriptor = new ObjectDescriptor(WFTHRepositoryCacheImpl.class);
        return objectDescriptor;
    }
      
}

       然后我们需要修改jbpm.wire.bindings.xml，使流程引擎初始化的时候加载我们新建的WFThRepositoryCacheBinding      

  <!--mod by 无风听海-->
  <!--  <binding class="org.jbpm.pvm.internal.wire.binding.RepositoryCacheBinding" />-->
  <binding class="org.jbpm.pvm.internal.wire.binding.WFTHRepositoryCacheBinding" />
  <!--end-->

      如果我们自定义了WFThRepositoryCacheBinding 中的tagName，那么我们就需要将jbpm.default.cfg.xml中的repository-cache元素改成自定义的tagName就可以了。

      以上对RepositorySession的扩展并不是直接对其进行控制，而是直接对其关联的对象进行了扩展，所以也可以说在扩展、RepositoryCache的时候，我们也同时被动的扩展了RepositorySession!