Neil's questions

只是想在阅读文档后检查我不是 100% 确定，但在我们的场景中，我们有一个单独的服务器运行 Deployer（HTTP 上传），一个单独的带有 Broker 的 SQL Server 和两个演示服务器，每个服务器都有 API服务器角色已安装。

我们想利用 Tridion 对象缓存

在每个演示服务器上：

1. 已安装 CCS。
2. 更新 cd_storage_conf：
   • 启用 ObjectCache = true
   • 添加指向本地缓存通道服务“localhost”的 RemoteSynchronization 条目。
   • 在我要缓存的 ItemTypes 上设置 cached=true。

在部署服务器上：

1. 此处未安装 CCS。
2. 更新 cd_storage_conf：
   • 启用 ObjectCache = true
   • 添加 RemoteSynchronization 条目，指向表示服务器上的每个缓存通道服务。
   • 在我要缓存的 ItemTypes 上设置 cached=true。

我这个正确吗？基本上我不确定 CCS 是否在每个 API 服务器上运行以由 Deployer 通知，或者它是否在 Deployer 服务器上运行并且 API 服务器指向它？

干杯

我们正在我们的 Tridion 2011 SP1 HR1 环境中设置 SmartTarget/Fredhopper 并且遇到了障碍 - 因此问题！

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

2013-01-23 10:46:08,148 信息 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) - 检查
• 发布 - 检查
• Deployer - 配置正确，但看起来无法访问 Web 服务？

任何人都可以就下一步检查或我们遗漏的任何明显问题提出建议吗？

更新_

核心日志中的附加信息 - 此处似乎无法执行 onSuccess，看起来有点可疑！

2013-01-23 14:53:12,094 信息 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 为假

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

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 DEBUG QueueLocationHandler - 删除部署包的独占锁：tcm:0-22272-66560，类型：CONTENT。2013-01-23 14:53:12,265 DEBUG QueueLocationHandler - 删除了部署包的独占锁：tcm:0-22272-66560，类型：CONTENT。

我们有一个要求，允许我们的用户提交有关他们的“项目”的信息——他们上传的一小段文本和一张图片。最终我们将有一个用户贡献项目的列表页面，其他人可以评论和评价。

我们决定在第一阶段使用 Tridion 的 UGC 在整个站点范围内进行评级和评论，这让我开始思考 - UGC 与 Tridion 发布的页面和组件相关联，如果我们希望 UGC 用于我们的用户提交的项目，他们将拥有作为组件本身在 Tridion 中创建，而不是坐在一些自定义数据库表中？

这是核心服务可以发挥作用的地方吗？我的理解是 CD Web 服务用于检索，而不是用于与内容管理器交互。

在架构上是否可以（！）将核心服务仅暴露给我们的实时应用程序服务器，以便我们的后端 .NET 代码可以创建“项目组件”，然后可以由编辑器发布并允许对它们进行评论？

除了“将核心服务暴露给实时服务器”之外，一切听起来都非常整洁。如果没有这个，我将不得不编写自定义方法将其“传输”回内容管理器——也许就像 Audience Manager Sync 一样？

以前有人这样做过吗？

当我们尝试在数据库向导中添加 MTSUser 详细信息时，我们收到错误：

“警告：MTSUser 在本地计算机上的登录尝试失败，原因是：未授予登录类型。如果您输入的值对于管理系统服务器是正确的，请选择确定，否则选择取消以返回到上一个对话框”。

我非常确定帐户详细信息是正确的，并且我偶然发现了 2003 年的一篇旧 Tridion 论坛帖子，该帖子指出在某些情况下，向导尝试的登录类型可能会失败，这是一个已知问题。它旨在尝试提供一些即时反馈，例如，如果密码错误。

九年后还是这样吗？我想单击继续，但也想避免进一步的问题！