Tridion 2011 SP1 HR1 - 将内容发送至 SmartTarget/Fredhopper

Tridion 2011 SP1 HR1 - 将内容发送至 SmartTarget/Fredhopper

我们正在 Tridion 2011 SP1 HR1 环境中设置 SmartTarget/Fredhopper 但遇到了障碍 - 因此提出了这个问题!

  • CM 配置正确,我们可以<SmartTarget addToFredhopper="true"/>在发送给部署者的包中看到条目。
  • 部署程序的日志配置为 DEBUG 级别,我们可以在 smarttarget 日志中看到一个条目:

2013-01-23 10:46:08,148 INFO FredhopperDeployerModule - 开始将传输包“D:\Tridion\incoming\Zip\tcm_0-22268-66560.Content\”部署到 Fredhopper。

  • 但遗憾的是,Fredhopper 中没有出现任何内容 - 发布队列停留在提交部署阶段,直到最终因“超出轮询错误”而失败。

Fredhopper 安装在不同的服务器上,因此我们使用 SmartTarget Web 服务(非 J2EE 和 Tomcat)并在 smarttarget_conf.xml 中对其进行了配置:

Location>http://server:8080/SmartTargetDeploymentWebService/SmartTargetDeploymentWebService?wsdl</Location>

在浏览器中快速检查此 URL 可成功响应 WSDL。我们还将服务配置为 DEBUG 级别,但从未写入任何日志文件,这表明部署程序从未成功向其发送任何内容。

所以:

  • Fredhopper 已安装 - 检查
  • SmartTarget Web 服务 (Tomcat) - 检查
  • 出版 - 检查
  • 部署程序-配置正确,但看起来无法访问 Web 服务?

有人能就下一步该检查的步骤或我们遗漏的任何明显内容提出建议吗?

更新_

来自核心日志的附加信息 - 这里似乎无法执行 onSuccess,看起来有点可疑!

2013-01-23 14:53:12,094 INFO FredhopperDeployerModule - 开始将传输包“D:\Tridion\incoming\Zip\tcm_0-22272-66560.Content\”部署到 Fredhopper。

2013-01-23 14:53:12,109 DEBUG RMICacheChannelConnector - 密钥的广播事件已完成:67:17789:17791

2013-01-23 14:53:12,250 错误 DeployPipelineExecutor - 无法在阶段执行 onSuccess 事件:事务的部署提交阶段:tcm:0-22272-66560

2013-01-23 14:53:12,250 DEBUG DeployPipelineExecutor - 检查事务是否完成:tcm:0-22272-66560 为 false

2013-01-23 14:53:12,250 INFO DeployPipelineExecutor - 已完成执行部署管道:tcm:0-22272-66560,耗时 17722 毫秒。

2013-01-23 14:53:12,250 INFO TransactionManager - 清理事务的部署包:tcm:0-22272-66560 和类型:CONTENT

2013-01-23 14:53:12,265 INFO TransactionManager - 已完成部署包的处理:tcm:0-22272-66560,类型为:CONTENT

2013-01-23 14:53:12,265 DEBUG QueueLocationHandler — 从队列中删除部署包:tcm:0-22272-66560,类型为:CONTENT。

2013-01-23 14:53:12,265 调试 QueueLocationHandler - 删除部署程序包上的独占锁:tcm:0-22272-66560,类型为:CONTENT。 2013-01-23 14:53:12,265 调试 QueueLocationHandler - 删除部署程序包上的独占锁:tcm:0-22272-66560,类型为:CONTENT。

答案1

SmartTarget Publisher Extension 是否安装正确?

在您的传输包中,component_presentations.xml 中应该有一个包含额外信息的部分。该信息由上述发布者扩展填充。

答案2

我会仔细检查部署 Web 服务的属性文件中存储 XML 文件的位置。然后确保它可以写入该位置(使用监控工具检查这一点)

它应该正确处理错误(并记录它们)但也许那里出了问题。

如果您将其从使用部署 Web 服务更改为将 XML 文件存储在同一服务器上的某个位置,会发生什么情况?它会创建文件并继续发布吗?这将为问题所在提供线索……

相关内容