以下各节中介绍了安装 Windchill 解决方案时建立的队列。安装可选产品时，可建立其他队列。这些队列被描述为产品说明的一部分。而例如，用于文件存储的队列在出厂设置的外部存储后台队列中进行介绍，用于内容复制的队列在出厂设置的复制后台队列中进行介绍。

CollectorBasedPackageQueue 可使基于收集器的包集合作为后台进程刷新。此选项可通过将集合移至后台来为前台进程释放可用资源。默认情况下，此选项是禁用的。以下特性对此队列很有用：

commonScheduleQueue 用于多种低容量的队列条目。这些低容量条目需要有限的资源，并且通常仅运行一次或偶尔运行。将这些队列条目合并为 commonScheduleQueue 可释放系统资源，从而集中处理高容量队列。以下列表说明了每个 commonScheduleQueue 条目类型：

LicenseScheduleQueue 为不可变队列，并用于与许可证相关的队列条目。由于此队列是不可变的，因此您无法对此队列或其条目执行停止、禁用、编辑、重置或删除等操作。这些操作在 LicenseScheduleQueue 的队列管理用户界面中处于隐藏状态。仅 PTC 有权创建和修改许可证相关队列。

下表对 LicenseScheduleQueue 中的各类条目进行了说明：

ContentControlQueue 在启用包的内容控制功能后使用。用户可通过内容控制功能从“文件表格”中指定哪些内容文件应包括在包交付中，方法是在“包内容”表格的“操作”菜单中选择“选择文件”。内容控制功能需要使用基于包类型的特性中所述的基于类型的特性文件显式启用。

当包的内容控制功能已启用并且包已锁定时 (或者随后解锁)，队列中会添加一个新条目。相似地，通过“包内容”用户界面进行的任何包成员内容控制信息更改都会向队列中添加新的条目。当执行队列条目时，将保持包成员的内容控制数据。

CtScheduleQueue 在开启团队更新的自动安排后使用。

有关团队更新的自动安排的详细信息，请参阅同步团队和用户定义的组。

dataMonitorProcessingQueue 及 dataMonitorScheduleQueue 与 Windchill 报告数据监控器功能一起使用。执行数据监控器的已安排实例后，系统会向 dataMonitorProcessingQueue 添加一个条目。如果删除了数据监控器，则所有 dataMonitorProcessingQueue 条目在执行完毕后均会被删除。dataMonitorProcessingQueue 状况显示在数据监控器信息页面“已执行的报告”表格的“状况”列中。

dataMonitorScheduleQueue 及 dataMonitorProcessingQueue 与 Windchill 报告数据监控器功能一起使用。创建数据监控器后，系统会针对数据监控器执行操作的每个已安排实例向 dataMonitorScheduleQueue 添加一个条目。执行已安排实例后，系统会向 dataMonitorProcessingQueue 添加一个条目。删除某个数据监控器后，该数据监控器的所有 dataMonitorScheduleQueue 条目均会被删除。dataMonitorScheduleQueue 状况显示在“数据监控器”表格的“状况”列中。

当上下文之间存在数据共享时，系统会使用 DataSharingQueue。在某些情况下，共享状况的更新会涉及大量的处理工作。例如，如果共享某个文件夹，则所有入夹对象也相应共享。此队列用于在后台处理这一类更新。使用此队列可使用户响应时间不受共享更新处理的影响。

DeleteCompletedWorkItemsQueue 会删除特定上下文中特定参与者的已完成工作项。在删除工作项之前，DeleteCompletedWorkItemsQueue 会读取首选项。首选项值可以为数字、ALL 或 NO。如果值为 NO，将不删除已完成的工作项。如果为 ALL，则删除所有已完成的工作项。如果值为数字，则表示最近完成工作中未删除的项数。其余工作项将被删除。只有当超出的完成工作项的数量为指定首选项的两倍时，才会对完成的工作项执行删除操作。例如，如果首选项为 10，则只有在超出的工作项的数量为 20 时才会对完成的工作项执行删除操作。请注意，只有当工作项的父进程为 CLOSED·时，该工作项才会被删除。不删除完成的项目工作项。

在 Windchill 9.1 M070 或 Windchill 10.0 之前，该首选项的默认值为 100。当前的默认值为 NO。

删除完成的工作项 (由首选项决定) 时，此队列中的失败条目会导致操作失败。

DigestNotificationQueue 由通知服务用来排列发送电子邮件的请求。会对请求进行排队，以根据排程针对要传送的通知订阅发送摘要通知电子邮件，而并不会立即发送。用户可以在订阅对象时利用订阅用户界面选择传送方法。可在“站点”级别或“组织”级别设置在订阅对象时，从而设置摘要通知的传送时间。“组织”级别首选项适用于组织中的用户，“站点”级别首选项适用于“组织”级别首选项未涵盖的用户。针对每个唯一的首选项值在 DigestNotificationQueue 上对请求进行列队，以安排摘要通知电子邮件的传送，而这些请求将摘要通知电子邮件传送给由该请求表示的首选项所涵盖的所有用户。

DTODeliverablesQueue 处理可交付结果的请求，即用户请求从可配置部件 (原通用部件) 生成可交付结果。请求会被放入队列中进行处理，并在完成后将结果发送给用户。唯一支持出厂设置的可交付结果生成器为 BOMMaker，该生成器可生成各种部件结构。通常情况下，BOMMaker 运行速度较快。还有其他可交付结果生成器。另外，客户还可以编写自己的可交付结果生成器，但这也许会花费较长时间 (分钟或小时)。在这些情况下，DTODeliverablesQueue 最为有用。

DTOOffPeakQueue 处理应在非高峰期间 (例如晚间) 运行的运行任务。这些任务长时间运行且没有优先级。例如，一项任务可能会搜索可配置部件的潜在变形，并将其作为变形进行附加。

EMailQueue 由邮件服务用来排列发送电子邮件的请求。向邮件服务请求发送电子邮件时，将在 EMailQueue 上对该请求进行列队。在队列中处理该请求时，便会发送电子邮件。邮件服务还会使用队列来重新尝试发送那些发送失败的电子邮件。请求发送电子邮件失败时，邮件服务需要在邮件发出的一段时间后对该请求重新进行处理。默认情况下，发送电子邮件的请求在 24 小时之内有效。如果邮件服务未在有效时间内成功处理此请求，则邮件服务将放弃尝试针对该请求发送电子邮件。

“讨论论坛”使用 forumEventPropogationQueue 来删除以下对象：

失败的队列条目指示以下一种情况：

每天都应检查此队列以确保该队列工作正常。如果对“讨论论坛”的使用频率较高，可能需要经常检查队列。对于每个失败的队列条目，将队列条目状态重置为就绪。

“索引队列”和“成批索引队列”是在安装 Windchill Index Search 时设置的可选队列。在索引过程中要用到这些队列。应定期检查“索引队列”和“成批索引队列”是否存在失败条目。

如果某个索引队列条目处于“严格的”状态，请确保正确配置了索引和搜索引擎且 Windchill Index Search 软件正在运行。然后将队列条目重置为“就绪”。重置队列条目会重新启动索引进程。

包“标准接收的交付服务”可利用 IXRepositoryQueue 来为导入创建对象信息。此信息将在包导入期间用于创建批处理。

用户上载包含包数据的 ZIP 文件时，由 ReceivedDeliveryChunkInfo (ZIP 信息) 组成的队列条目将添加到此队列中。执行队列条目时，将针对 ZIP 中的对象创建元数据信息。

NotificationQueue 由通知服务用来排列生成和发送通知 (基于策略和订阅的通知) 的请求。

通知服务支持两种预定/通知：

NotificationQueue 用于电子邮件预定和对象监听程序预定；因此，只有为 WfSynchRobots 启动 NotificationQueue 才能得到通知，这样它们可以在满足预定时执行所需处理。停止 NotificationQueue 会阻止电子邮件通知的发送，并能够阻止对象监听程序订阅者发挥作用。

NotificationScheduleQueue 由通知服务使用。请求排队等待终止订阅。订阅 UI 允许用户设置订阅的截止日期，排列的请求在到期时删除订阅。

PartsLinkQueue 是可选队列，在安装 Windchill PartsLink 时设置。此队列由 Windchill PartsLink 服务用来发布已被分类到 PartsLink Server 的部件。

应定期检查 PartsLinkQueue 是否存在失败条目。如果存在失败状态，则所需的唯一操作是将队列条目重置为“就绪”。

“典型项目管理”使用 ProjectScheduleQueue 根据错过最后期限、接近最后期限和超过最后期限发送事件。

无需定期检查此队列，此队列中发生失败的可能性极低。如果有未发送项目管理最后期限消息的投诉，则应检查此队列。但是，通知失败更多由电子邮件服务器的问题所导致。

会创建 PublisherQueues，供“可视化服务”用来管理可视化数据的发布和打印，以及相关工程计算，如干涉检测。此外，当包压缩处理进程中需要内容同步时，Windchill 包会向 PublisherQueues 中添加条目，本主题稍后将对此进行介绍。

在可视化服务中 CAD 数据通常在检入后发布。这样，许多客户站点便可大量使用这些队列来执行长时间 (可能是几小时) 运行的作业。每个 PublisherQueue 都遵循 PublishQueue<queueset>L/M/H 或 PublishQueue<queueset>N 的命名约定，其中 L/M/H 代表低/中/高属性，而 N 是从 1 开始的连续整数。具有相同 queueset 的队列被称为队列集。以空字符串作为名称的默认队列集始终存在；所有附加队列集必须由 wvs.properties 中的 publish.publishqueue.setnames 特性声明。以下队列集和队列在出厂设置时创建：

根据作业类型、提交作业的方式及数据类型将所有提交的 WVS 作业添加到优先级队列中 (名称以 L、M 或 H 结尾)。此流程由 wvs.properties 中的特性设置控制。有关详细信息，请参阅 wvs.properties.xconf 中的以下特性：

L、M 和 H 优先级队列中正在执行的作业在相同队列集中查找可用编号队列 (名称以连续数字 N 结尾)。如果找到某个队列，该作业会将 WVS 作业提交到该队列，立即执行该作业。默认情况下，只会为每个队列集创建一个编号队列。其他发布队列 (例如 PublisherQueue2、PublisherQueue3、PublisherQueueCLASH2 等) 可使用 Windchill“队列管理”实用程序进行创建以获得可伸缩性。

存储在队列条目中的对象为 com.ptc.wvs.server.publish.PublishJob、com.ptc.wvs.server.publish.ClashJob 或 com.ptc.wvs.server.publish.PrintJob 对象。您可以在“WVS 作业监视器”中查看 WVS 作业的详细信息。如果作业失败，使用队列条目的日志信息 (显示在 WVS 作业监视器中) 来调查失败的原因。解决问题后，重新提交作业。

当导出并压缩 Windchill 包时，可将条目添加到其中一个默认的 PublisherQueues 中，如 PublisherQueue1。这些条目用于对要导出的所有 CAD 内容进行更新，以将与该内容相关的全部 Windchill 元数据更改包括在内。

要在导出并压缩包时将队列用于 CAD 内容同步，必须设置具体的包首选项。有关首选项的详细信息，请参阅设置包首选项。

如果包首选项设置为启用队列的使用，则使用的队列处理与可视化服务生成表示时使用的处理相同。存储在包队列条目中的对象是 com.ptc.wvs.server.publish.PublishJob 对象。因此，Windchill 包队列条目与可视化服务中的条目有相同的属性。相似地，您可以在“WVS 作业监视器”中查看作业的详细信息。如果作业失败，使用队列条目的日志信息 (显示在 WVS 作业监视器中) 来调查失败的原因。解决问题后，重复包导出操作。

RDImportExecutorQueue 用于处理接收的交付包的导入。对接收的交付启动“导入”操作后，含有接收的交付标识信息的条目将添加到此队列中。执行队列条目时，将触发接收的交付的导入。有关导入的信息，请参阅导入接收的交付文件。

根据要处理对象或文件的数目，导入接收的交付可能是个很长的过程。

工作流 (及其关联任务) 使用 WfPropagationQueue 将所有状态更改传播到“工作流”对象。这包括与那些状态更改关联的所有路由表达式和转变表达式。

当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的情况下也可能频繁使用它们。

如果工作流队列的性能出现问题，可设置包括 WfUserWorkQueue 和 WfPropagationQueue 队列的队列池。WfPropagationQueue 队列在池中以 WfSharedPropagationQueue<n> 命名 其中 <n> 从 1 开始并针对每个附加队列以 1 递增。有关设置队列池的详细信息，请参阅队列池。

工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。

当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除出旧条目。

WfScheduleQueue 由工作流 (及其关联任务) 用来排列所有定时的事件。最后期限检查具有最后期限设置的任意工作流对象，并且在此队列内执行基于表达式的“同步自动机”。

当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的情况下也可能频繁使用它们。

工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。

当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除出旧条目。

WfUserWorkQueue 由工作流 (及其关联任务) 用来实例化工作流自动机和执行工作流自动机操作。

当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的情况下也可能频繁使用它们。

如果工作流队列的性能出现问题，可设置包括 WfUserWorkQueue 和 WfPropagationQueue 队列的队列池。WfUserWorkQueue 队列在池中以 WfSharedUserQueue<n> 命名，其中 <n> 从 1 开始并针对每个附加队列按 1 递增。有关设置队列池的详细信息，请参阅队列池。

工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。

当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除旧条目。

WPSyncQueue 用于处理包导出操作。每次包压缩操作都会针对压缩进程的长度在 WPSyncQueue 上生成一个条目。当有大量对象或对象含有大量内容时，包压缩可能是个长时间运行的进程。

此外，当压缩进程中需要内容同步时，将在 PublisherQueues 中创建队列条目以使内容同步。如果受支持的 CAD 内容位于包中且内容同步已启用，则将进行内容同步。