使用Camunda流程引擎開(kāi)發(fā),如何讀取流程圖中配制的參數(shù)及參數(shù)值?

在使用開(kāi)源?Camunda 流程引擎框架做二次開(kāi)發(fā)，有時(shí)候會(huì)在固定節(jié)點(diǎn)添加固定的參數(shù)及參數(shù)值，流程在流轉(zhuǎn)到此節(jié)點(diǎn)時(shí)，我們?nèi)绾芜\(yùn)用Camunda從中取出配制的參數(shù)呢？

下面首先介紹?Camunda 支持配制哪些參數(shù)：

1. String

2. Map

3. List

4. Script

5. String or Expression

在Camunda中，除開(kāi)1類型之外，其它四種都是以對(duì)象的方式保存在流程中(解析出來(lái)保存在?ACT_GE_BYTEARRAY 表中)。配制String類型的是在 Extensions ；其它4種是在 ?Input/Output

上面介紹了使用?Camunda Modeler 流程圖工具配制參數(shù)，下面來(lái)看下流程圖是如何取到這些值的。

讀取這些值的方法還是很簡(jiǎn)單，只有一句代碼：

Map<String, Object> map = runtimeService.getVariables(task.getExecutionId());

讀取配制的值很簡(jiǎn)單，那有沒(méi)有想過(guò)這些值是怎么取到的呢？

大膽猜想一下，就是在部署流程解析XML文件的時(shí)候，這些值就解析出來(lái)了，然后在保存在緩存中。

有了猜想，下面再來(lái)驗(yàn)證我們的猜想。

protected DeploymentWithDefinitions doExecute(final CommandContext commandContext) { DeploymentManager deploymentManager = commandContext.getDeploymentManager();

// load deployment handler ProcessEngine processEngine = commandContext.getProcessEngineConfiguration().getProcessEngine(); deploymentHandler = commandContext.getProcessEngineConfiguration() .getDeploymentHandlerFactory() .buildDeploymentHandler(processEngine);

Set<String> deploymentIds = getAllDeploymentIds(deploymentBuilder); if (!deploymentIds.isEmpty()) { String[] deploymentIdArray = deploymentIds.toArray(new String[deploymentIds.size()]); List deployments = deploymentManager.findDeploymentsByIds(deploymentIdArray); ensureDeploymentsWithIdsExists(deploymentIds, deployments); }

checkCreateAndReadDeployments(commandContext, deploymentIds);

// set deployment name if it should retrieved from an existing deployment String nameFromDeployment = deploymentBuilder.getNameFromDeployment(); setDeploymentName(nameFromDeployment, deploymentBuilder, commandContext);

// get resources to re-deploy List resources = getResources(deploymentBuilder, commandContext); // .. and add them the builder addResources(resources, deploymentBuilder);

Collection<String> resourceNames = deploymentBuilder.getResourceNames(); if (resourceNames == null || resourceNames.isEmpty()) { throw new NotValidException("No deployment resources contained to deploy."); }

// perform deployment DeploymentWithDefinitions deployment = commandContext.runWithoutAuthorization(() -> { acquireExclusiveLock(commandContext); DeploymentEntity deploymentToRegister = initDeployment(); Map<String, ResourceEntity> resourcesToDeploy = resolveResourcesToDeploy(commandContext, deploymentToRegister); Map<String, ResourceEntity> resourcesToIgnore = new HashMap<>(deploymentToRegister.getResources()); resourcesToIgnore.keySet().removeAll(resourcesToDeploy.keySet());

// save initial deployment resources before they are replaced with only the deployed ones CandidateDeployment candidateDeployment = CandidateDeploymentImpl.fromDeploymentEntity(deploymentToRegister); if (!resourcesToDeploy.isEmpty()) { LOG.debugCreatingNewDeployment(); deploymentToRegister.setResources(resourcesToDeploy); deploy(commandContext, deploymentToRegister); } else { // if there are no resources to be deployed, find an existing deployment String duplicateDeploymentId = deploymentHandler.determineDuplicateDeployment(candidateDeployment); deploymentToRegister = commandContext.getDeploymentManager().findDeploymentById(duplicateDeploymentId); }

scheduleProcessDefinitionActivation(commandContext, deploymentToRegister);

if(deploymentBuilder instanceof ProcessApplicationDeploymentBuilder) { // for process application deployments, job executor registration // is managed by the ProcessApplicationManager ProcessApplicationRegistration registration = registerProcessApplication( commandContext, deploymentToRegister, candidateDeployment, resourcesToIgnore.values());

return new ProcessApplicationDeploymentImpl(deploymentToRegister, registration); } else { registerWithJobExecutor(commandContext, deploymentToRegister); }

return deploymentToRegister; });

createUserOperationLog(deploymentBuilder, deployment, commandContext);

return deployment;}


、********************、

public T runWithoutAuthorization(Callable runnable) { CommandContext commandContext = Context.getCommandContext(); boolean authorizationEnabled = commandContext.isAuthorizationCheckEnabled(); try { commandContext.disableAuthorizationCheck(); return runnable.call(); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new ProcessEngineException(e); } finally { if (authorizationEnabled) { commandContext.enableAuthorizationCheck(); } }}


代碼調(diào)試發(fā)現(xiàn)，上面的代碼就是部署流程的核心代碼。

代碼一步一步跟蹤調(diào)試，終是沒(méi)有發(fā)現(xiàn)解析參數(shù)的地方？上面的猜想失敗了

那Camunda 到底是如何處理參數(shù)的呢？調(diào)試了好幾天，都沒(méi)有發(fā)現(xiàn)解析參數(shù)的地方！真的都被搞的很點(diǎn)失去信心了。

就在3月17日下午，我重新整理了調(diào)整了思路。

是不是直接從表里面查詢出來(lái)的？

試試跟蹤?runtimeService.getVariables(task.getExecutionId())?這個(gè)方法，終于發(fā)現(xiàn)了一點(diǎn)眉目，真是從表查詢出來(lái)的。

public VariableMap execute(CommandContext commandContext) { ensureNotNull("executionId", executionId);

ExecutionEntity execution = commandContext .getExecutionManager() .findExecutionById(executionId);

ensureNotNull("execution " + executionId + " doesn't exist", "execution", execution);

checkGetExecutionVariables(execution, commandContext);

VariableMapImpl executionVariables = new VariableMapImpl();

// collect variables from execution 核心方法 execution.collectVariables(executionVariables, variableNames, isLocal, deserializeValues);

return executionVariables;}

?? ?

// selectVariablesByExecutionId 對(duì)應(yīng)執(zhí)行的SQL語(yǔ)句SELECT RES.*, ( case when RES.TASK_ID_ is not null and RES.EXECUTION_ID_ is not null then EXECUTION.ACT_INST_ID_ when RES.CASE_EXECUTION_ID_ is not null then RES.CASE_EXECUTION_ID_ when EXECUTION.PARENT_ID_ is null and RES.IS_CONCURRENT_LOCAL_ = 0 then EXECUTION.ID_ when EXECUTION.IS_SCOPE_ = 1 and EXECUTION.PARENT_ID_ is not null and RES.IS_CONCURRENT_LOCAL_ = 0 then PARENT_EXECUTION.ACT_INST_ID_ else EXECUTION.ACT_INST_ID_ end ) ACT_INST_ID_FROM ACT_RU_VARIABLE RES LEFT JOIN ACT_RU_EXECUTION EXECUTION ON RES.EXECUTION_ID_ = EXECUTION.ID_ LEFT JOIN ACT_RU_EXECUTION PARENT_EXECUTION ON EXECUTION.PARENT_ID_ = PARENT_EXECUTION.ID_WHERE EXECUTION_ID_ = '54854e59-a5c7-11ec-a5f8-92b1d713a145' AND TASK_ID_ is null

執(zhí)行上面的SQL后，會(huì)返回?List<VariableInstanceEntity>?列表對(duì)象，在?VariableInstanceEntity?對(duì)象中有?ByteArrayField?屬性，它保證的是 一條?ACT_GE_BYTEARRAY（保存的對(duì)象信息，也就是需要序列化的參數(shù)） 表的數(shù)據(jù)信息。

總結(jié)?runtimeService.getVariables 執(zhí)行過(guò)程：

? ? 1、根據(jù)當(dāng)前任務(wù)ID獲取當(dāng)?executionId，根據(jù)?executionId 查詢?ACT_RU_VARIABLE 參數(shù)表

? ? 2、判斷?ACT_RU_EXECUTION 表中的?PARENT_ID_ ?是否有值，有值就繼續(xù)根據(jù)此值查詢?ACT_RU_VARIABLE

? ? 3、 根據(jù)查詢的 ?ACT_RU_VARIABLE 結(jié)果中?BYTEARRAY_ID_ 有值，就根據(jù)此ID去查詢ACT_GE_BYTEARRAY 資源信息表，反序列化對(duì)象

? ?