CQ5 / AEM5.6工作流:从内部访问工作流实例属性或拆分

时间:2014-04-16 00:58:26

标签: workflow cq5 aem

TL; DR版本:

  • 在CQ工作流程中,与流程步骤相比, OR Split 可用的内容是否存在差异?
  • 是否可以从OR Split?
  • 中访问工作流实例的/ history / nodes
  • 如何?!

整个故事:

我正在使用CQ5 / AEM5.6中的工作流程。

在这个工作流程中,我有一个自定义对话框,它在工作流实例上存储了几个属性。

我遇到问题的属性的路径是:/ workflow / instances / [this instance]/history/[workItem id]/workItem/metaData我已经将该属性称为"拒绝或批准"。

该对话框设置属性正常(通过下拉列表,您可以将其设置为"拒绝"或"批准"),我可以通过流程访问此节点上的其他属性步骤(在ecma脚本中)使用:

var actionReason;
var history = workflowSession.getHistory(workItem.getWorkflow());

// loop backwards through workItems
// and as soon as we find a Action Reason that is not empty
// store that as 'actionReason' and break.
for (var index = history.size() - 1; index >= 0; index--) {
  var previous = history.get(index);

    var tempActionReason = previous.getWorkItem().getMetaDataMap().get('action-message');

    if ((tempActionReason != '')&&(tempActionReason != null)) {
        actionReason = tempActionReason;
        break;
    }
}

但是,流程步骤不是问题。我遇到麻烦的地方是当我尝试从 OR Split 中做同样的事情时。

当我在OR分割中尝试相同的workflowSession.getHistory(workItem.getWorkflow())时,会抛出一个错误,说明未定义workItem。

我已尝试将此属性存储在有效负载上(即将其存储在页面的jcr:content下),在这种情况下,该属性似乎可用于OR Split,但是我的问题是:

  • reject-or-approve属性仅与当前工作流实例相关,因此将其存储在页面上的jcr:content并不真正有意义。 jcr:内容属性将在工作流关闭后保持不变,并且可供将来的工作流实例访问。我可以解决这个问题(即不要让工作流程根据属性做任何事情,除非我确定这个实例已经写入了该属性),但这感觉不对,可能是错误易发。
  • 出于某种原因,在我的工作流程中运行自定义对话框时,只有Admin用户组似乎能够写入jcr:content属性。当我将对话框用作任何其他用户组(我需要为此工作流程设计做)时,对话框看起来好像有效,但实际上从未写入jcr:content属性。

因此,出于几个不同的原因,我宁愿将此属性保留在工作流实例的本地,而不是将其存储在页面的jcr:content - 但是,如果有人能够想到为什么会这样做的原因当我使用除admin之外的任何组时,我的对话框没有在jcr:content上设置属性,即使它不是我正在寻找的解决方案,也会给我一个解决方法。 / p>

如果有人可以提供帮助,请提前致谢!我知道这有点模糊,但我已经坚持了很久。

2 个答案:

答案 0 :(得分:2)

几天前我遇到了同样的问题。这里的问题是你没有workItem对象,因为你没有真正的workItem。想象一下:你正在经历工作流程,你有几个workItems,有手段,要么是流程步骤,要么是收件箱项目。当您处于或拆分时,您没有现有的workItem,您可以通过访问工作流实例的/ workItems节点来确保。您的解决方法似乎是解决此“问题”的唯一方法。

答案 1 :(得分:1)

我已经解决了。它不是那么优雅,但似乎是一个非常可靠的解决方案。

以下是一些背景资料:

对话似乎可靠地让您将属性存储在:

  • 有效负载的jcr:content节点(这对我来说不实用,因为有效负载在工作流程中被锁定,并且不允许非管理员写入其jcr:content)
  • 当前工作流程步骤的workItem/metaData

但是,拆分步骤无法访问workItem。我在这里发现了一个相当无用的确认:http://blogs.adobe.com/dmcmahon/2013/03/26/cq5-failure-running-script-etcworkflowscriptscaworkitem-ecma-referenceerror-workitem-is-not-defined/

基本上问题是,Dialog步骤可以存储属性,但是OR Split无法访问它。

我的解决方法是在我的工作流程中的Dialog之后直接添加一个Process步骤。流程步骤可以访问workItem,因此他们可以读取Dialog设置的属性。我从来没有特别想将这些数据存储在有效载荷的jcr:content上,所以我找了另一个位置。事实证明,流程metaData(工作流实例节点的顶层,而不是workItem/metaData子节点内的/history)可以访问流程步骤和OR拆分。因此,我的Process步骤现在读取workItem的approveReject属性(由Dialog设置),然后将其写入工作流的metaData节点。然后,OR Split从其新位置读取属性,并发挥其魔力。

您从“处理”步骤访问工作流程metaData并且OR拆分不是一致,但可以从两者中获取。

以下是一些代码:(完成评论。欢迎您)

在您选择批准或拒绝的对话框中,该字段的name设置为rejectApprove。它之前没有./或任何东西。这告诉它将属性存储在workItem/metaData节点上,以用于/history/下的当前工作流程步骤。

在对话框之后,一个Process步骤运行:

var rejectApprove;
var history = workflowSession.getHistory(workItem.getWorkflow());

// loop backwards through workItems
// and as soon as we find a rejectApprove that is not empty
// store that as 'rejectApprove' and break.
for (var index = history.size() - 1; index >= 0; index--) {
  var previous = history.get(index);
    var tempRejectApprove = previous.getWorkItem().getMetaDataMap().get('rejectApprove');
    if ((tempRejectApprove != '')&&(tempRejectApprove != null)) {
        rejectApprove = tempRejectApprove;
        break;
    }
}
// steps up from the workflow step into the workflow metaData, 
// and stores the rejectApprove property there
// (where it can be accessed by an OR Split)
workItem.getWorkflowData().getMetaData().put('rejectApprove', rejectApprove);

然后在“处理”步骤之后,OR拆分在其选项卡中显示以下内容:

function check() {
    var match = 'approve';
    if (workflowData.getMetaData().get('rejectApprove') == match) {
        return true;
    } else {
        return false;
    }
}

注意:将此选项用于“批准”路径的标签,然后将其复制并将var match = 'approve'替换为var match = 'reject'

所以这里的关键是来自流程步骤:

workItem.getWorkflowData().getMetaData().put('rejectApprove', rejectApprove);

写入相同的属性:

workflowData.getMetaData().get('rejectApprove')从OR拆分执行时读取。

为了满足我们的业务需求,我实现的工作流程不仅仅是这个,但上面的方法似乎是一种非常可靠的方法来获取在对话框中输入的值,并从OR中访问它们分裂。

OR拆分无法直接访问workItem似乎很愚蠢,我很想知道是否有更少的迂回方式,但是现在这已经解决了我的问题。

我真的希望别人有同样的问题,并发现这很有用,因为我花了很长时间才弄明白,只申请一次!

相关问题