体系结构概述
本部分概述了实施 Servigistics InService 时选择体系结构方面的注意事项。
选择部署体系结构会因以下因素变得非常复杂：
• 相对于 Servigistics InService 解决方案位置，源内容 (创作和非创作) 的位置：
• 将访问内容的客户群
• 有效集成 Servigistics InService 解决方案和提供诸如“部件订购”和“反馈投票”服务的其他信息系统的位置和要求。
• 为用户群提供已发布内容的渠道。
本部分将介绍可满足绝大多数要求的体系结构典型示例，包括开发和 QA 阶段的简单 Servigistics InService 实施到可支持成千上万并发用户的大型生产体系结构。
整体服务生命周期管理解决方案有许多功能可供使用。从服务内容的创作源开始，到发布并变换任务来准备内容、再到将内容交付到更大的用户群，最后到选择接收用户反馈并与 eCommerce 应用程序集成的方法。下图说明了这些功能需求以及它们之间的相互关系：
此图包括以下元素：
• 服务信息管理和其他企业源数据。它用于管理产品技术信息，例如；
◦ 拆卸和装配步骤
◦ 测试和调整步骤
◦ 服务公告
◦ 备件信息
◦ 服务有效性
• 数据处理 – 从源提取服务信息，随后进行变换，以便适应内容交付系统。
• 数据加载 - 将服务信息移动到内容交付系统中的最终任务。
• 内容交付 - 将服务内容提供给用户群。已与 eCommerce 解决方案集成。可接收用户反馈。
从部署的角度来看，服务生命周期管理环境应具有以下系统，如下图所示。
为简单起见，此处将每个系统表示为一台服务器。但是每台服务器可由多个硬件资源组成，具体取决于其设计、性能和规模要求。
此图包括以下元素：
• Windchill SIM/SP 或其他 SIM 内容源 - 包含服务信息内容的解决方案。在生产设置中，通常将此看作内部或“后台”系统。
• 其他 CMS/ERP 和提取引擎 - 如果将第三方 CMS/ERP 系统中的数据加载到 Servigistics InService，则必须编写自定义提取引擎从第三方系统提取数据，然后将该数据转换为 Servigistics InService 所需的 CSV 格式。有关详细信息，请参阅《Servigistics InService 发布和加载指南》。
• Windchill 发布引擎或其他提取资源 - 用于将服务内容提取为产品束，以便提交至内容交付系统的引擎。在生产设置中，通常将此看作内部或“后台”系统。
• Publisher - Publisher 接收服务信息束并执行变换、聚合和加载任务，以便将服务内容移动到内容交付系统。在生产设置中，通常将此看作内部或“后台”系统。
• Viewer - 为用户群提供服务内容访问权限。在生产设置中，通常将此看作外部或“面向客户”的系统。它可以本地托管、由第三方外部托管，或在云内托管。
