我应该能够将资产的再现从工作实例复制到主实例,然后使用 DAM 更新资产卸载工作流删除工作实例中的资产
问问题
1097 次
1 回答
0
在我看来,更新工作实例上的更新资产工作流不是一个好习惯 -
- 整个卸载基于 Sling Discovery 和事件机制。这需要将卸载的资产发送回(读取反向复制)到领导者实例
- 在更新资产工作流程中添加步骤可能会导致资产反向复制出现问题。
您必须构建独立于卸载过程的东西才能实现此删除。有多种方法可以做到 -
一种可能的方式 -
- 拥有基于 JMS 的实现来监控反向复制
- 如果反向复制成功,则删除资产或将资产标记为删除(强烈推荐)
- 如果遵循标记资产删除的方法,设置一个清理任务只运行工作实例(安排到方便的时间)。此清理任务识别标记为删除的资产并对其进行处理。
恕我直言,将资产标记为删除是更好的方法,因为它的性能和效率更高。所有资产在非高峰时间立即处理。
还有其他方法可以做到这一点,但需要编写大量自定义代码。
更新 -
利用反向复制 -
您需要了解反向复制的工作细节。
- 要反向复制的内容被推送到 OUTBOX
- 如果您查看
/etc/replication/agents.publish/outbox/jcr:content
本地实例,请查找transportUri
默认情况下的属性 -repo://var/replication/outbox
即反向复制的内容被推送到“/var/replication/outbox” - 现在看看
/libs/cq/replication/components/revagent/revagent.jsp
,这是在接收实例上工作的逻辑。
浏览上述内容将使您更深入地了解反向复制的工作原理。
现在您有两种选择来实现您想要的 -
- 要检查复制状态,请在代码执行时进入复制队列
/libs/cq/replication/components/revagent/revagent.jsp
。这是在内容被反向复制的 Author 实例上执行的代码,在您的情况下是其 Leader 实例。您将不得不解决此代码以使其在 Worker 实例上工作。为了更具体地实现,您的代码将更新Agent agent = agentMgr.getAgents().get(id);
id 是 OUTBOX 代理 id 的行。 - 让事件侦听器监视发件箱。检查用于复制的有效负载并将其用于您的功能。
我所提到的是不包括故障转移/恢复用例的粗略方法,即如果您的复制队列由于任何原因被阻塞并且图像没有被推回领导者,您将如何处理删除。
于 2016-07-22T13:57:28.807 回答