Tridion 2011 SP1 HR1 – 将内容发送到SmartTarget / Fredhopper

我们在Tridion 2011 SP1 HR1环境中设置了SmartTarget / Fredhopper,并遇到了麻烦 – 因此,这个问题!

  • CMconfiguration正确,我们可以在发送给部署者的包中看到<SmartTarget addToFredhopper="true"/>条目。
  • 日志logging在部署者的DEBUG级别configuration,我们可以在智能目标日志中看到一个条目:

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中configuration了它:

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

在浏览器中快速检查该URL是否成功响应了WSDL。 我们还将服务configuration为DEBUG级别,但是没有写入日志文件,这表明部署者从未成功向其发送任何内容。

所以:

  • Fredhopper安装 – 检查
  • SmartTarget Web服务(Tomcat) – 检查
  • 发布 – 检查
  • 部署者 – configuration正确,但无法通过它的外观到达Web服务?

任何人都可以build议下一步检查或任何明显的我们已经错过了?

UPDATE_

来自核心日志的额外信息 – 似乎无法在这里执行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,109debuggingRMICacheChannelConnector – 关键广播事件完成: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是错误的

2013-01-23 14:53:12,250 INFO DeployPipelineExecutor – 在17722毫秒内完成正在执行的部署pipe道:tcm:0-22272-66560。

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

2013-01-23 14:53:12,265 INFO TransactionManager – 完成对部署包的处理:tcm:0-22272-66560,types:CONTENT

2013-01-23 14:53:12,265 DEBUG QueueLocationHandler – 从队列中移除部署包:tcm:0-22272-66560,types:CONTENT。

2013-01-23 14:53:12,265debuggingQueueLocationHandler – 删除types为CONTENT的部署包的唯一锁:tcm:0-22272-66560。 2013-01-23 14:53:12,265debuggingQueueLocationHandler – 删除部署包中的排它锁:tcm:0-22272-66560,types为:CONTENT。

SmartTarget发布者扩展程序是否正确安装?

在您的Transport Package中,应该在component_presentations.xml中有一个部分,其中包含额外的信息。 该信息由“发布商扩展”填写。

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

它应该正确处理错误(并logging它们),但也许有什么地方出错了。

如果将其从使用部署Web服务更改为将XML文件存储在同一服务器上某个位置,会发生什么情况? 它是否创build文件,并继续发布? 这会给出线索问题在哪里…