监视、诊断和解决问题的指导

企业管理 > Windchill ESI > 在 ORACLE Applications 环境中管理 Windchill ESI > 监视、诊断和解决问题的指导

监视、诊断和解决问题的指导

本节提供：

• 有关如何监视和诊断问题的常规指导，并列出了可以用于解决这些问题的某些特定技巧。

• 特定问题、问题起因及其解决方法的列表。

监视问题

作为 Windchill ESI 管理员，您会接收到通过报告通道 (如包含通过帮助桌面记录的失败记录卡的用户报告) 或通过电子邮件及通过自动系统警报发出的问题警报。

用户报告是一种检测问题的被动反应方法。要提高 Windchill ESI 系统稳定性并降低总体所有权成本，建议用自动系统警报来补充用户报告，因为自动系统警报是一种可以防止问题恶化的预防方法。

以下内容说明了如何使用下列方法监视问题：

• TIBCO BusinessWorks 监视服务

• 错误处理进程和日志记录服务

• 事件规则和问题检测方法

使用 BusinessWorks 进行监视

Windchill ESI 错误处理进程使用 TIBCO BusinessWorks 监视 Windchill EAI 软件组件并处理系统问题。TIBCO 管理器向您提供了图形用户界面和微代理，用于监视和维护 TIBCO 管理域中的硬件和软件组件。可以对这些工具进行配置以监视 BusinessWorks 进程引擎、适配器、日志文件条目、可用磁盘空间、操作系统参数以及更多内容。定义部署配置时，TIBCO 管理器提供工具以创建由预定义事件 (例如组件失败、暂停进程或日志事件) 触发的警报和操作升级规则。

可以使用 BusinessWorks 监视以下问题：

• BusinessWorks 引擎问题

• 适配器问题

• JMS 问题

BusinessWorks 引擎问题

需要为在 Windchill ESI 中使用的每个进程运行 TIBCO BusinessWorks 引擎。因此，BusinessWorks 监视组件必须能够执行以下操作：

• 处理 BusinessWorks 引擎失败导致消息丢失或处理停止时出现的事件

• 出错时将警报发送到 TIBCO Administrator 监视

• 随着失败频率的增加逐步升级操作

失败类别

在部署中，可以将失败分成以下类别：

• Any Failure：捕捉所有失败并执行某项操作

• First Failure：捕捉引擎的第一个失败并执行某项操作

• Second Failure：捕捉引擎的第二个失败并执行某项操作

• Subsequent Failure：捕捉第二个失败之后发生的所有失败并执行某项操作

建议的部署配置

以下内容列出了可在部署过程中配置的建议操作，适用于各种失败类型：

• Any Failure：向管理员发出警报

• First Failure：重新启动引擎

• Second Failure：重新启动引擎并发出第二个失败警报

• Subsequent Failure：重新启动引擎并向管理员发送电子邮件

这里包含一个可配置计数器 (同时也是一个计时器)，用于确定何时将失败计数重置为第一个。使用此计数器上的计时器设置来设置一个特定时限，如果在该时限中发生两次以上故障，则需要大大提高对系统总体完整性的关注。

1. 向下导航整个 TIBCO Administrator GUI：

◦ 应用程序管理 > <应用程序名称> > 配置 > Process Archive.par

2. 单击“监视”选项卡：

3. 在“事件”下单击“添加”按钮。将出现“添加事件”屏幕：

4. 选择想要监视的事件的类型。例如，如果 JMS 队列失败，则进程将处于暂停状态。可配置一个警报以监视进程暂停：

作为系统管理员，您能够使用 TIBCO BusinessWorks Administrator 重新启动引擎。有关详细信息，请参阅下面的主题“JMS 问题”。

适配器问题

对于 Windchill ESI 中使用的多个进程，适配器的分布目标系统需要处于运行状态。因此，TIBCO BusinessWorks 监控组件必须能够执行以下操作：

• 适配器实例失败时重新启动这些实例

• 出错时将警报发送到 TIBCO Administrator

• 随着失败频率的增加逐步升级操作

失败类别

在部署中，可以将失败分为以下类别

• Any Failure：捕捉所有失败并执行某项操作

• First Failure：捕捉引擎的第一个失败并执行某项操作

• Second Failure：捕捉适配器的第二个失败并执行某项操作

• Subsequent Failure：捕捉第二个失败后的所有失败并执行某项操作

建议的部署配置

以下内容列出了可在部署过程中配置的建议操作，适用于各种失败类型：

• Any Failure：向管理员发出警报

• First Failure：重新启动适配器

• Second Failure：重新启动适配器并发出第二个失败警报

• Subsequent Failure：重新启动适配器并向管理员发送电子邮件

JMS 问题

为了使主控进程流和错误处理进程得以正确运行，EMS 服务器需要处于运行状态。TIBCO Administrator 必须能够执行以下操作：

• 处理 EMS 服务器出错时出现的事件

• 出错时将错误发送至错误处理进程

不幸的是，EMS 服务器失败时，TIBCO BusinessWorks 并不会创建事件。要解决这个问题，可以执行以下操作之一：

• 不暂停：如果未选中暂停复选框选项，则当 JMS 队列在 repeat-on-error-until-true 组之后运行时没有响应或无法连接到该队列时，BusinessWorks 将创建进程引擎日志条目，表示 JMS 活动超时。您可在 TIBCO Administrator 中配置日志事件，以便针对此情况监控日志并发出警报。

• 暂停：如果选中暂停复选框选项，则当 JMS 队列在 repeat-on-error-until-true 组之后运行时没有响应或无法连接到该队列时，BusinessWorks 将暂停进程，您可以配置 TIBCO Administrator 规则基准以发出警报。

默认情况下，Windchill ESI 将配置为使用暂停方法，因为这样可以允许捕捉 JMS 队列失败的进程在重新启动 EMS 服务器之后继续运行。

EMS 服务器问题的特殊指导

Windchill PDMLink 允许每次使用一个 JMS 提供者。因此，TIBCO EMS 服务器将成为 Windchill ESI 体系结构不可或缺的一部分，且 Windchill PDMLink 用户可将其用于除 Windchill ESI 应用程序之外的其他功能。因此，当存在与 JMS 问题相关的 Windchill ESI 问题时，将 Windchill ESI 配置为自动重新启动 EMS 服务器的做法可能不妥。相反，当检测出严重的 JMS 问题时，默认和推荐的配置是让错误处理进程将当前 BusinessWorks 作业置于暂停模式。

暂停模式使您可以进行手动干预，并且不会带来数据丢失的危险。仅暂停受影响的 BusinessWorks 作业 (即，正在发布的产品数据事务处理)，而同一进程引擎中的其他作业可以继续进行。如果其他作业遇到同样的 JMS 问题，则这些作业也将被分别暂停。可以通过 TIBCO BusinessWorks 管理器分别重新启动作业。作业从暂停点 (而不是最后一个检查站) 恢复。

TIBCO Administrator 不提供 TIBCO EMS 的内置管理域监视。但是，可以将 TIBCO BusinessWorks 配置为在 EMS 服务器暂停或要求重新启动时发布警报。最终用户可以使用 TIBCO EMS 中的基本管理控制台将 TIBCO BusinessWorks 配置为在 EMS 服务器处于暂停状态或要求重新启动时发出警报。有关详细信息，请参阅下面的主题“配置电子邮件警报”。

Oracle Applications 问题

TIBCO Adapter for Oracle Applications 日志文件能够报告 Oracle ApplicationsWindchill ESI 用户帐户无效这类的问题。这些情况通常由安装时发生的印刷错误或密码在预定时段后过期之类的问题所致。此类问题无法预料，并且难以诊断。因此，您可能希望将 TIBCO BusinessWorks 配置为监视这些日志文件中是否出现相关消息文本，并在事件发生时发出警报。

使用错误处理进程和日志记录服务

除了配置基础 TIBCO 产品的问题警报，还可以使用错误处理和日志记录共享服务来检测和诊断 Windchill ESI 问题。

开发事件规则和问题检测方法

由于事件规则与硬件部署联系紧密，因此，想要让 Windchill ESI 提供预定义的、随时可用的配置并不可行。但是，可以按照需要逐步开发和调整事件规则，要避免对基础 TIBCO 产品以及 Windchill ESI 业务逻辑组件产生不良的影响。可以基于遇到的最常见或最棘手的问题确定开发规则的优先顺序，如此逐步从反应方法转移到预防性的问题检测方法。

诊断问题

检测到无法自动纠正或无法由用户纠正的问题后，您需要开始诊断问题。这将涉及到对问题分类并确定发生问题的位置，以确定其根本原因。

确定问题的位置

要确定问题来源的位置，您需要提出一些问题，例如：

• 该问题是否与业务流程问题 (如系统记录冲突)、功能问题 (如无效数据) 或技术问题 (如服务器关闭) 关联？

• 该问题是否与 Windchill PDMLink、TIBCO 或分布目标 ERP 系统关联？

• 该问题是否与 TIBCO 有关，是否与 TIBCO EMS、BusinessWorks 或 Adapter for Oracle Applications 关联？

• 该问题是否与 BusinessWorks 部署和/或运行期代理关联？

• 该问题是否与基础物理网络和计算关联而与 Windchill ESI 无关？

• 是否可以在与生产环境具有相同配置的测试系统中重复这一问题发生的情景？

对问题进行分类：故障排除的关键区域

要对问题进行分类，您需要将重点放在关键问题区域，并逐渐熟悉错误处理报告，例如错误日志和错误处理代码。

大多数与系统相关的技术问题可以根据根本原因的位置进行分类。如有必要，请参见 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》) 以及系统集成方提供的适用文档，以验证和恢复正确的配置设置。

对您来说，熟悉业务流程以及功能性故障排除信息也很重要。不熟悉此信息的用户可能向您提出这样的问题。

以下问题及其说明的分类并没有一步一步列出详细过程，而是帮助您将重点放在导致出现以下技术问题的某些关键或潜在的根本原因上：

• 源自 Windchill ESI 的问题

• 源自 TIBCO 组件的问题，例如：

◦ EMS

◦ BusinessWorks

◦ Adapter for Oracle Applications

• 源自分布目标的问题。

• Windchill ESI 日志中指示的问题。

Windchill ESI 问题

以下内容列出了如何处理可能源自 Windchill ESI 服务的问题：

• 验证 Windchill 服务器和应用程序是否正在运行

• 验证 Windchill JMS 客户端是否正在连接至 TIBCO EMS 服务器

• 验证是否已正确配置了 EMS 服务器的 Windchill ESI 用户帐户

• 验证所有其他与 JMS 相关的配置

• 审阅 Windchill 管理日志中的错误消息

• 验证给定版本的分布目标及其属性

• 验证 Windchill Enterprise Integration Access 远程过程调用 (RPC) 是否运行正常

• 验证各个 Windchill ESI 首选项设置值的正确性

TIBCO 问题

以下内容列出了如何处理可能源自 TIBCO 组件的问题：

EMS 问题

• 验证 EMS 服务器是否正在运行

• 验证是否已正确配置 EMS 服务器

• 确保已对所需的 Windchill ESI JMS 队列进行了定义

• 验证是否已正确配置了 EMS 服务器的 BusinessWorks Windchill ESI 用户帐户

• 验证安全队列验证配置

• 隔离所有 Java 虚拟机 (JVM) 问题，例如不受支持的版本或内存溢出错误

BusinessWorks 问题

• 验证所有必需的 TIBCO 服务是否正在运行。如果下列所必需的服务未运行，则进程引擎不会启动。验证所有必需的 TIBCO 服务是否正在运行：

◦ TIBCO Administrator <版本> (域名)

◦ TIBCO HAWK Agent (域名)

• 验证所需的 Windchill ESI BusinessWorks 应用程序特性和配置文件是否存在以及其内容：

◦ ESIORAEMailMessageLookups.properties

◦ ESIORADefaults.properties

◦ ESIORAErrorHandlingCodes.properties

◦ ESIORALookups.properties

◦ ESIORAMessageLookups.properties

◦ FilesToRead_ORA.properties

• 验证 BusinessWorks JMS 客户端是否正在连接至 TIBCO EMS 服务器

• 验证所有其他与 EMS 相关的配置

• 隔离所有 Java 虚拟机 (JVM) 问题，例如不受支持的版本或内存溢出错误

• 验证是否将 Windchill ESI 组件部署到正确的域

• 验证 Windchill ESI 业务逻辑配置和部署设置，包括全局变量值

必须重新启动进程引擎才能使新的全局变量值生效。

• 验证 Java classpath

• 验证 TRA 文件中的配置设置

• 通过以下方式验证 BusinessWorks 管理器服务器配置：

◦ 向用户授权帐户

◦ 确保相同子网上具有同一集点配置 (网络、服务和守护程序) 的多个信息库具有唯一的名称，而不管 BusinessWorks 管理域如何

◦ 确保未直接删除基于服务器的信息库 (.dat) 文件。要从管理域中正确删除基于服务器的项目，请执行以下步骤：

▪ 取消项目的部署 (这将删除所有 .tra 和 .cmd 文件)

▪ 停止管理服务器服务

▪ 删除 <Tibco_Home>/tra/domain/<Domain_Name>/application/<Application_Name>/工作文件夹的内容

▪ 重新启动管理服务器服务

上述参考路径中的 <Application_Name> 的含义可通过以下事实加以理解：应用程序的部署名称采用 <Domain_Name>-<Application_Name> 形式。

• 隔离国际化或区域设置的配置设置方面的所有问题。检出以下内容：

◦ 消息的 JMS 标题中的 com_infoengine_localeWindchill ESI 属性

◦ ESIOMAdapter/Locale 全局变量

◦ 数据映射中使用的默认设置和交叉参考查找文件条目

Adapter for Oracle Applications 问题

下面列出了如何处理可能源自 Oracle Applications 分布目标的问题。有关详细信息，请参见 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》)。

• 验证是否所有 Oracle Applications 服务器都在运行。

• 验证 Oracle Applications 系统是否正在运行支持的版本

• 验证在所有 ESITarget 实例中是否存在 TIBCO Adapter for Oracle Applications 所使用的有效 ESISYS Oracle Applications 用户帐户。

• 验证 ESISYS 用户帐户是否已具备必需的安全授权配置文件

• 隔离国际化或区域设置配置方面的所有问题。

Oracle Applications 问题

• 验证是否所有 Oracle Applications 服务器都在运行。

• 验证 Oracle Applications 系统是否正在运行支持的版本

• 验证在所有 ESITarget 实例中是否存在 TIBCO Adapter for Oracle Applications 所使用的有效 ESISYS Oracle Applications 用户帐户。

• 验证 ESISYS 用户帐户是否已具备必需的安全授权配置文件

• 隔离国际化或区域设置配置方面的所有问题。

日志和错误处理代码

为有助于诊断问题，您需要彻底熟悉 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》) 中描述的关键 Windchill ESI 日志。您也需要熟悉 EAI 错误处理体系结构和错误代码。以下内容列出了可用的日志以及如何访问这些日志：

日志

如何访问

Windchill Enterprise Systems 事务处理日志

Windchill PDMLink 用户界面

TIBCO BusinessWorks 进程引擎日志

显示 Windchill ESI 应用程序消息时，同时显示 ESI 的角色指定，从而将其与标准 TIBCO 产品消息区别开。

TIBCO BusinessWorks 管理器。日志文件所在位置：<TIBCO_HOME>/tra/domain/<domain_name>/application/logs/<Application_Name>-Process_Archive.log[.sequence#]

TIBCO EMS 日志

文件名称和路径由 tibemsd.conf 文件中的与日志文件相关的配置参数确定。

TIBCO Adapter for Oracle Applications 日志

<TIBCO_HOME>/tra/domain/<domain_name>/application/logs/<Application_Name>-ESIOMAdapter.log.[.sequence#]

Oracle Applications 日志

请咨询 Oracle Applications 管理员。

您还应该熟悉 Oracle Applications 分布目标以及受 Windchill ESI 影响的数据对象和属性。您可能要直接负责查看和处理 Oracle Applications 中的数据，或可能只需要与 Oracle Applications 管理员协调这些活动。要查看由 Oracle Applications 传送到 Windchill ESI 中的数据，以下窗口尤为重要：

• 主数据项

• 物料清单

• 工程更改命令

• 路由选择

解决问题

在监视、检测和诊断问题之后，需要解决这些问题。以下内容列出了进行故障排除时可以使用的一些常用技巧以及特定问题及其解决方法。

解决问题的技巧

以下内容列出了可以用于解决问题的一些故障排除技巧。

协调故障排除团队以及提交问题

作为 Windchill ESI 管理员，您可能需要召集并协调各类专业人员才能完全解决生产问题。其中可能会涉及最终用户、运行专家、Windchill PDMLink 管理员、Oracle Applications 管理员、数据库专业人员、操作系统专业人员、网络管理员以及其他人员。如果在诊断并确定问题发生的位置之后，您确信该问题无法在内部解决，可能需要将这个问题提交给系统集成合作者和/或 PTC 技术支持，以向他们寻求帮助。系统集成合作者可能在帮助您解决涉及对标准 Windchill ESI 产品做出的特殊配置或自定义的问题时发挥特别关键的作用。

手动忽视检查站

Windchill ESI 应用程序在 TIBCO BusinessWorks 处理流的关键点上使用检查站活动。检查站保存当前运行进程实例的进程数据和状态，以便以后万一发生故障时可以恢复。如果进程引擎失败，可以恢复所有进程实例，并可以在进程定义中最后一个检查站的位置恢复执行。检查站仅保存最新状态。如果在一个进程中存在多个检查站，则仅最后一个检查站的状态可用于恢复进程。

对 Windchill ESI 检查站的位置从策略角度进行了设计，在确保强健事务处理集成的同时最小化对性能的不利影响。有些时候，进程引擎重新启动时，可能需要手动忽视已激活的检查站以从头开始重新启动事务处理进程。

由于可以导致重复或不完整的数据、不正确的导出历史记录和数据损坏，所以忽视检查站时应相当小心。

但是如果情况允许，您可以通过删除 <Tibco_Home>/tra/domain/<Domain_Name>/application/<Application_Name>/working 目录及其内容来覆盖检查点。根据进程引擎模式，在需要删除的 /tibco 路径下可能存在许多其他 /working 子目录。搜索 /working 以找到并删除所有这些子目录。

解决 Solaris 平台问题

在 Solaris 平台上，您可能必须解决因以下原因而导致的问题：

• 环境变量问题

• 设计者部署配置问题

以下内容说明了解决这些问题的技巧。

环境变量问题

在各种 Unix 平台上，某些 TIBCO 组件由于存储库相关性而无法启动。如果该特定组件的 bin 目录中存在任意 *.sh 或 *.csh 文件，则应执行这些文件，以便可以使用 ‘ldd’ 命令来标识存储库相关性。所有所需的存储库路径都应添加至存在于 *.tra 文件中的 tibco.env.CUSTOM_EXT_PREPEND 变量。

设计者部署配置问题

有些时候，TIBCO 管理器和 TIBCO Runtime Agent (TRA) 会中断，并在不发出警告的情况下在 Solaris 平台上关闭。如果在 TIBCO 设计器处于运行状态时出现这种情况，部署配置和 TIBCO 设计器可能会出现运行异常，例如：

• 打开项目时，基于服务器的信息库没有出现在当前域的项目下拉列表中

• 尽管部署历史记录显示组件已经部署，但部署组件仍显示为新建

• 部署和取消部署选不能用于已部署、已更改、甚至是新的部署组件

如果出现以上任意征兆，请重新启动 Solaris 计算机，重新启动 TRA 和 TIBCO 管理器，然后重新启动设计器。

找到并停止 UNIX 平台上的 TIBCO 进程

某些时候，作为解决问题的一个步骤，可能需要停止所有正在运行的 TIBCO 进程。

在 UNIX 平台上，可以使用 UNIX 命令 ‘ps’ 列出所有正在运行的进程。但是，不需要运行标准的“全部”标志 (-a) 来列出低级 TIBCO 进程，例如 TIBCO 集合点。要查看这样的进程，可以执行以下命令：

# ps -ef | grep <filter>

例如：

# ps -ef | grep tibco

上述操作将导致显示以下几行输出：

root 5559 1 0 09:10:02 pts/1 0:18
/opt/tibco/administrator/<version>/bin/tibcoadmin --propfile /opt/

可以使用带有标志 -9 和进程 ID ('ps -ef' 命令的第二列) 的“停止”命令来强制停止所列出的进程

# kill -9 5559

使用 -9 标志确保进程确实已停止。通常来说，要确保所有 TIBCO 进程停止，应运行

ps -ef | grep tibco
ps -ef | grep hawk

和

ps -ef | grep rvd

并验证是否找到正在运行的进程。

配置电子邮件警报

如前所述，当 Windchill ESI 业务逻辑出现错误时，可以将 Windchill ESI 配置为向您发送电子邮件警报消息：

• 向 Windchill PDMLink 发送 ESIPostResult 消息

• 等待来自 Windchill PDMLink 的 ESIResultResponse 消息

• 分析 ESIResultResponse 消息

通过以下全局变量执行此配置：

• ESIMail/ToAddress

• ESIMail/FromAddress

• ESIMail/CCAddress

• ESIMail/BCCAddress

使用以下全局变量来配置服务器：ESIMail/SMTPHostServer。

有关如何配置全局变量的详细信息，请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》)。

Windchill ESI 业务逻辑将尝试按照由 TIBCO BusinessWorks 全局变量 ESIJMS/RetryCount 指定的次数重试与 EMS 相关的所有操作。因此，您可能会收到同一问题的多个电子邮件消息。最后一次尝试失败后，Windchill ESI 业务逻辑将暂停关联的 BusinessWorks 进程，使您可以检查电子邮件警报消息中说明的错误、更正基本问题以及使用 TIBCO Administrator 恢复或停止 BusinessWorks 进程。有关如何使用此界面的详细信息，请参见 TIBCO Administrator User's Guide (《TIBCO 管理器用户指南》)。

解决特定问题

以下内容列出了特定问题，并提供了可能的原因以及解决问题时建议使用的方法。

TIBCO Administrator 显示 BWengine 或适配器进程的未知状况

某些时候，作为解决问题的一个步骤，可能需要停止所有正在运行的 TIBCO 进程。

# ps -ef | grep <filter>

例如：

# ps -ef | grep tibco

上述操作将导致显示以下几行输出：

root 5559 1 0 09:10:02 pts/1 0:18
/opt/tibco/administrator/<version>/bin/tibcoadmin --propfile /opt/

可以使用带有标志 -9 和进程 ID ('ps -ef' 命令的第二列) 的“停止”命令来强制停止所列出的进程

# kill -9 5559

使用 -9 标志确保进程确实已停止。通常来说，要确保所有 TIBCO 进程停止，应运行

ps -ef | grep tibco
ps -ef | grep hawk

和

ps -ef | grep rvd

并验证是否找到正在运行的进程。

配置电子邮件警报

如前所述，当 Windchill ESI 业务逻辑出现错误时，可以将 Windchill ESI 配置为向您发送电子邮件警报消息：

• 向 Windchill PDMLink 发送 ESIPostResult 消息

• 等待来自 Windchill PDMLink 的 ESIResultResponse 消息

• 分析 ESIResultResponse 消息

通过以下全局变量执行此配置：

• ESIMail/ToAddress

• ESIMail/FromAddress

• ESIMail/CCAddress

• ESIMail/BCCAddress

使用以下全局变量来配置服务器：ESIMail/SMTPHostServer。

解决特定问题

以下内容列出了特定问题，并提供了可能的原因以及解决问题时建议使用的方法。

TIBCO Administrator 显示 BWengine 或适配器进程的未知状况

之所以出现这个问题，可能有以下两个原因：

• 特定服务的 microhawk 代理正在将其状况发送给 Administrator，这需要一定时间；几分钟后应该可以解决此问题。

• hawk 服务尚未获悉配置更改；重启 hawk 服务即可解决此问题

无法通过 JMS 传输启动适配器

安装 TIBCO Runtime Agent <版本> 和 TIBCO Runtime Agent <版本>.1 后，使用 Enterprise Message Service 作为传输的 TIBCO Adapter 项目不会从 TIBCO 设计器中启动并给出下列错误：

Message "Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms." displays

这可能由于 Adapter SDK 库不兼容。要解决此问题：

• 在 Window 平台上：从 <TIBCO_HOME>/adapters/sdk/version/lib 中移除 libeay32.dll 和 ssleay32.dll 文件

• 在 UNIX 平台上：从 <TIBCO_HOME>/adapters/sdk/version/lib 目录中移除 libssl 和 libcrypto openssl 存储库。

未解决的存储库相关性

Message "Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms." displays

这可能由于 Adapter SDK 库不兼容。要解决此问题：

• 在 Window 平台上：从 <TIBCO_HOME>/adapters/sdk/version/lib 中移除 libeay32.dll 和 ssleay32.dll 文件

• 在 UNIX 平台上：从 <TIBCO_HOME>/adapters/sdk/version/lib 目录中移除 libssl 和 libcrypto openssl 存储库。

在 TIBCO BusinessWorks 引擎日志中，出现“Coyote 连接器未启动”错误

这可能是由于 ESIOthers/WSHost 和 ESIOthers/WSPort 变量的值不正确。提供合适的值即可解决此问题。

手动启动 EMS 服务器后，所有 EMS 服务器配置消失

这可能是由于用于启动 EMS 服务器的命令在 5.1.4 版本中已更改。在 EMS 版本 4.x 中，启动 EMS 的命令为 "/tibemsd"。在 EMS 版本 5.1.4 中，命令为 "/tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"。此命令使用相对路径，且应从 "<TIBCO_HOME>\ems\<version>\bin" 中执行。

要解决此问题，停止由此命令启动的进程：

"./tibemsd"

并用正确的命令启动 ems 服务器：

"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"

使用 TIBCO Administrator GUI 的应用程序部署显示一条失败消息

如果先前的任何部署或取消部署曾意外需要锁定，且该锁定未解除，则可能会发生这种情况。

要解决此问题，从命令提示符运行 AppManage 命令，以相应地诊断并解决此问题：

• 浏览到 <Tibco_Home>\tra\<版本>\bin

• 运行以下命令：

AppManage -deploy -app <Application name> -user <username>
-pw <password> -domain <Domain_Name>

例如：

AppManage -deploy -app ORA_ESI_Solution -user admin -pw admin
-domain I4590

有关详细信息，请参阅 <Tibco_Home>\tra\domain\<Domain_Name>\logs\ApplicationManagement.log 文件。

TIBCO BusinessWorks 返回错误消息

TIBCO BusinessWorks 返回如下错误消息：

-2003 Feb 19 13:27:12:294 GMT -5 Engine Error [] PE-Error
process initialization failed for
ProcessDefinitions/Services/WCResult_Service

--Initialization error in
[ProcessDefinitions/Services/WCResult_Service/JMSRepeatUntilTru
e_ESIPostResult_Result/JMSSender_ESIResult_PostResult]

--javax.naming.ServiceUnavailableException: Failed to query
JNDI: Failed to connect to the server at tcp://localhost:7222.
Root exception is javax.jms.JMSException: Failed to connect to
the server at tcp://localhost:7222

如果 EMS 服务器名称无效，可能发生此种情况。

要解决此问题，请确认进程引擎部署配置中的 ESIJMS/JNDIContextURL 全局变量与 factories.conf 文件 (位于 <Tibco_Home>/ems/<版本>/tibco/cfgmgmt/ems/data) 中的 QueueConnectionFactory URL 中的值相匹配。

ESIJMS/JNDIContextURL 全局变量应设置为：

tibjmsnaming://<计算机名>:<端口>

QueueConnectionFactory URL 应设置为：

tcp://<计算机名称>:<端口>。

计算机名称和端口值应匹配。

例如，如果将 ESIJMS/JNDIContextURL 设置为 tibjmsnaming://mymachine.mycompany.com:7222，则应将 QueueConnectionFactory URL 设置为 tcp://mymachine.mycompany.com:7222。

有关此变量的详细信息，请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》) 中的 "Global Variables for Process Engines" (进程引擎的全局变量)。

BusinessWorks 返回错误消息

BusinessWorks 返回如下错误消息：

-2003 Feb 19 18:57:29:051 GMT -5 Engine Error [] PE-Error process
initialization failed for
ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_
End_PD

--Initialization error in
[ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease
_End_PD/JMSReceiver_Event_ESIEvent]

--Could not establish connection or session with EMS provider.

--javax.naming.AuthenticationException: Not permitted: invalid name
or password. Root exception is javax.jms.JMSSecurityException:
invalid name or password

当 JMS 服务器的用户名和密码无效时，可能发生这种情况。

要解决此问题，请确认在进程引擎的部署配置中的 ESIJMS/Username 和 ESIJMS/Password 全局变量与在 EMS 服务器上为队列指定的用户名和密码的值相匹配。

为 EMS 服务器设置的用户名称和密码值在位于 <Tibco_Home>/ems/<版本>/tibco/cfgmgmt/ems/data 目录下的 users.conf 文件中。有关此变量的详细信息，请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》) 中的 "Global Variables for Process Engines" (进程引擎的全局变量)。

如果使用 EMS 管理工具设置这些密码，则密码会出现混乱。如果您忘记了所设置的密码，必须对其进行重新设置。

在 UNIX 上启动 TIBCO 组件时，收到以下错误：

在 UNIX 上启动 TIBCO 组件时，将接收到以下错误：

/usr/lib/dld.sl: Call to mmap() failed - TEXT (UNIX path)

/usr/lib/dld.sl: Permission denied

例如，

/usr/lib/dld.sl: Call to mmap() failed - TEXT
/opt/tibco/tra/5.6/lib/libmaverick50.sl

/usr/lib/dld.sl: Permission denied

文件权限设置不正确时，可能发生这种情况。

要解决此问题，请使用列在 TEXT 之后的文件上的 chmod 555 命令。例如，

# chmod 555 /opt/tibco/tra/<version>/lib/libmaverick50.sl

BusinessWorks 和/或 Windchill ESI 无法连接至 EMS

如果 EMS 服务器没有正确配置，可能发生此种情况。将 EMS 服务器的名称指定为 localhost 时，该服务器只能在其正在运行的计算机上被识别。其他计算机无法与其连接。设置为 localhost 的应用程序将尝试找到正在同一计算机上运行的 EMS 服务器。如果未找到，则会出错。如果将计算机名称指定为您的服务器名称，则其他计算机可以连接到您的 EMS 服务器。

要解决此问题，请检查是否已对位于 <Tibco_Home>/ems/<版本>/tibco/cfgmgmt/ems/data/factories.conf 文件中的 QueueConnectionFactory 值和进程引擎部署中的全局变量 ESIJMS/JNDIContextURL 进行了相应的设置。

• factories.conf 文件中的 QueueConnectionFactory = tcp://<计算机名称>:7222 其中，“计算机名称”为正在运行 EMS 服务器的计算机。

• 设置 BW 引擎中的全局变量 ESIJMS/JNDIContextURL = tibjmsnaming://<正在运行 EMS 服务器的计算机名>:7222

与这个 EMS 服务器的位置无关。可以与 Windchill PDMLink 位于同一计算机上，也可以与 TIBCO 进程引擎位于同一个计算机上，或者位于另外一台计算机上。只要对上述值进行了相应设置 (并且计算机均在同一网络上)，Windchill ESI 和 EAI 组件就可以连接至正确的 EMS 服务器。

要确定连接至 EMS 服务器的计算机和用户名称，请在 TIBCO JMS 管理工具中键入以下命令：

>show connections

此命令将给出连接到服务器的用户和计算机的列表。

事务处理保持待决状态

如果没有如配置和管理 JMS 队列中所述对 JMS 服务器队列进行预订，可能会发生此种情况。

常见的根本原因为：Windchill 方法服务器启动时，JMS 服务器未处于运行状态，Windchill 适配器的 JMS 特性出现错误配置或 JMS 服务器出现错误配置。

在 Windchill ESI Services 成功预订 JMS 队列 (为接收结果消息) 后，以下信息会包含在 Windchill PDMLink 方法服务器日志中：

Thread-10: subscription to queue "com.ptc.windchill.esi.Result" successful

如果此信息未出现在日志中，则意味着 Windchill 无法成功预订上述队列。在这种情况下，所有的 Windchill ESI 事务处理都将保持待决状态。一旦 Windchill 能够成功预订队列，即会对事务进行处理。

通常，当 Windchill ESI Services 因为 JMS 服务器不可用而无法预订队列时，Info*Engine 会接收到异常信息。Windchill ESI Services 会在 Windchill 适配器事务日志中记录此异常情况。如果 TIBCO EMS 是 JMS 提供者，该消息将包含以下文本：

javax.ems.JMSException:Failed to connect to the server at tcp

作为一种检测方法，可以考虑配置监视软件来查找此文本或类似文本。要解决此问题，请确保 EMS 服务器在方法服务器之前启动，并解决 Windchill 适配器 JMS 配置和 JMS 服务器配置方面的所有问题。

为了避免此问题，请确保以下方面：

• 仅一个 WCESI 用户连接到 EMS 服务器 (可通过“EMS 管理工具”>“显示连接”查看)

• ESISYS 与 ClientID (BW-ESIMaster_JMSConnection-queue-<Application Name>-Process_Archive) 连接的数量应该与配置的 ERP 实例数相等 (可通过“EMS 管理工具”>“显示连接”查看)

• 所有的连接均来自当前测试套件中的 TIBCO 或 Windchill 服务器。没有来自先前套件或不相容计算机的连接 (可通过“EMS 管理工具”>“显示连接”查看)

• Windchill 和 Process Archive 连接到相同的 JMS 队列 (可通过“EMS 管理工具”>“显示队列”查看)

• com.ptc.windchill.esi.Result 队列仅有一个接收者 (可通过“EMS 管理工具”>“显示队列”查看)

• 任何队列中不应有消息 (可通过“EMS 管理工具”>“显示队列”查看)

• Windchill 已成功预订 DataResponse 队列。连接到 JMS 服务器并检查是否创建了 DataResponse 队列且授予文件 WCESI 用户发送 DataResponse 队列的权限。如果 DataResponse 队列名称前显示 *，这表示队列为临时队列且需要创建。如果手动部署 EAR 则会出现此问题。在“JMS 管理”窗口中运行下列命令，以解决此问题：

◦ create queue <DataResponse>

◦ setprop queue <DataResponse> secure

◦ grant queue <DataResponse> <EAI User> receive

◦ grant queue <DataResponse> <WC ESI User> send

◦ setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222

◦ commit

• Process Archive 连接到 Windchill 已预订的同一 DataResponse 队列。检查“JMS 管理”窗口，以确认 Process Archive 已预订 DataResponse 队列。手动部署时，有时会忽略此步骤。如果预订了 DataResponse 队列，请检查 TIBCO Administrator -->“应用程序管理”-->“应用程序名称”-->“配置”-->“部署名称”-->“高级”--> ESIJMS/DataResponseQueue

TIBCO BusinessWorks 进程引擎日志错误消息

TIBCO BusinessWorks 进程引擎日志包含下列消息文本：

Job terminated: Please check following 1) FilesToRead_ORA.properties exists at %TIBCO_HOME%\\esi\\bin 2) %TIBCO_HOME%\esi\bin exists in tibco.env.STD_EXT_CP path in %TIBCO_HOME%\
bw\<version>\bin\bwengine.tra

这些症状通常表明 TIBCO BusinessWorks 进程引擎在启动时未能加载 Windchill ESI 业务逻辑特性文件。这些特性文件含有数据映射中使用的交叉引用和默认值，以及日志记录中使用的文本等等。有几种原因可能导致此类问题：

1. 特性文件未正确安装在 <TIBCO HOME>\esi\bin 目录中。

2. FilesToRead_SAP.properties 文件为 Path 变量指定的值无效。变量 Path 必须指向放置文件的位置。此值在路径名末尾必须含有一个斜线。例如：例如: C:/tibco/esi/bin (Windows) 或 /opt/tibco/esi/bin (UNIX)。

3. 特性文件的安全授权不允许对 TIBCO BusinessWorks 进程引擎进行读取访问。

要解决此问题：

1. 如果 FilesToRead_ORA.properties 文件为 Path 变量指定的值无效，请输入一个正确值，保存文件，然后重新启动 TIBCO BusinessWorks 进程引擎。

2. 如果特性文件限制了读取权限，请将此权限授予 TIBCO BusinessWorks 进程引擎。有关在部署过程中配置 Windchill ESI 业务逻辑特性文件和指定类路径的详细信息，请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》)。

TIBCO BusinessWorks 进程引擎未连接至 TIBCO EMS 服务器。

如果在启动 EMS 服务器之前启动 BusinessWorks 引擎，则会发生这种情况。

要避免此问题，则始终在 BusinessWorks 引擎启动之前启动 EMS 服务器。有关检测此问题的详细信息，请参阅主题“JMS 问题”。

在 Windows 服务器上，由于存在下列错误，Adbagent 无法启动：无法在动态链接库 LIBEAY32.dll 中找到序数 3823

要解决此问题，请运行下列命令：

1. MOVE /Y <Tibco_Home>/adapter/sdk/<版本>/bin/libeay32.dll <Tibco_Home>/adapter/sdk/5.5/bin/libeay32_bk.dll

2. MOVE /Y <Tibco_Home>/adapter/sdk/<版本>/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/5.5/bin/ssleay32_bk.dll

3. COPY /Y <Tibco_Home>/tibrv/<版本>/bin/libeay32.dll <Tibco_Home>/adapter/sdk/<版本>/bin/libeay32.dll

4. COPY /Y <Tibco_Home>/tibrv/<版本>/bin/ssleay32.dll <Tibco_Home>/adapter/sdk/<版本>/bin/ssleay32.dll

Windchill ESI 无法向分布目标系统发布任何业务对象

Windchill ESI 无法向分布目标系统发布任何业务对象。错误包括业务对象总体故障、“缺失必填字段”错误等。另外，TIBCO BusinessWorks 进程引擎日志不包含任何 Windchill ESI 消息文本，如下例所示：

2003 Aug 11 18:55:31:722 GMT -4 Engine ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40012,,,, 2003 Aug 11 18:55:32:563 GMT -4 Engine
ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40013,,,, 2003 Aug 11 18:55:32:864 GMT -4 Engine
ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40016,,,,

1. 特性文件未正确安装在 <TIBCO HOME>\esi\bin 目录中。

2. FilesToRead_SAP.properties 文件为 Path 变量指定的值无效。变量 Path 必须指向放置文件的位置。此值在路径名末尾必须含有一个斜线。例如：C:/tibco/esi/ (Windows) 或 /opt/tibco/esi/ (UNIX)。

3. 特性文件的安全授权不允许对 TIBCO BusinessWorks 进程引擎进行读取访问。

要解决此问题，请进行下列验证：

1. 如果 FilesToRead_ORA.properties 文件为 Path 变量指定的值无效，请输入一个正确值，保存文件，然后重新启动 TIBCO BusinessWorks 进程引擎。

2. 如果特性文件限制了读取权限，请将此权限授予 TIBCO BusinessWorks 进程引擎。有关在部署过程中配置 Windchill ESI 业务逻辑属性文件和指定类路径的详细信息,请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》)。

TIBCO BusinessWorks 指出与以下错误之一类似的错误：

• 仅在将 LONG 值插入 LONG 列中时 ORA-01461 才能将其绑定

• [DataDirect][ODBC Oracle driver]字符串数据，右边截取。参数错误

如果您试图映射的字段在 Windchill PDMLink 中的长度超过 Oracle Applications 中允许的长度，可能会发生此种情况。最有可能出现此问题的字段是更改通告编号和位号。

应对 Windchill PDMLink 进行修改，或者采取适当的业务流程，以避免更改通告编号或“位号”的长度超过 10 个字符。关于管理系统之间字段长度差异的详细信息，请参阅 Windchill Enterprise Systems Integration Installation and Configuration Guide - Oracle Applications (《Windchill Enterprise Systems Integration 安装和配置指南 - Oracle Applications》)。

“TIBCO 管理器”因“Apache/Tomcat 404”Web 浏览器错误出现故障

如果您正在使用不受支持的 Web 浏览器版本，可能会发生此种情况。

要解决此问题，请将 Web 浏览器升级到 Microsoft Internet Explorer 版本 6.0 SP1 或更高版本。

TIBCO Adapter for Oracle Applications 日志中包含错误消息

TIBCO Adapter for Oracle Applications 日志中含有类似于以下消息的错误消息：

2004 Mar 11 14:43:20:226 GMT -5
BOMConfiguration.BOMConfiguration Error [Adapter] AEADB-700071
Duplicate agent found on DEV01MACHINE.mydomain.mycompany.com
(132.253.82.60)2004 Mar 11 14:43:20:226 GMT -5
MasterConfiguration.MasterConfiguration Info [Adapter] AEADB-
700095 Terminating agent

当多个开发人员正在同一子网上使用同一个适配器部署配置名称时，可能会发生这种情况。不能按其各自的域充分区分适配器部署配置。

要避免此问题，确保所有适配器部署配置名称在整个子网中是唯一的。

当在 TIBCO Administrator 中启动适配器实例或进程引擎时，状态始终保持为 "Starting Up"

当在 TIBCO Administrator 中启动适配器实例或进程引擎时，状态始终保持在 "Starting Up"，从未改为 "Started"。

这是 TIBCO Adapter for Oracle Applications 和 TIBCO Runtime Agent (TRA) 的已知问题。自动启动 TIBCO 服务 (按照 Windows 系统中的默认设置) 可能导致它们有时以错误的顺序启动并阻碍了“管理服务器”与 TRA 之间的正常通信。

检查组件的日志文件，确定其是否已真正成功启动 (尽管显示的状态是 "Starting Up")。多数情况下，它可能已真正启动。否则，请尝试以下步骤：

1. 关闭 TIBCO Administrator 应用程序以及所有正在运行的 TIBCO 组件和服务。

2. 手动启动 TIBCO 服务，顺序如下：

a. TIBCO Administrator <版本> (域名)

b. TIBCO HAWK Agent (域名)

3. 重新启动 TIBCO Administrator 应用程序，并尝试再次启动各组件。

TIBCO BusinessWorks 进程引擎日志中出现多个“活动超时”错误

TIBCO BusinessWorks 进程引擎日志中多次出现“活动超时”错误，但 Windchill ESI 在“企业系统事务处理日志图形用户界面”中报告的却是成功结果。

这是预期行为。Windchill ESI 用后续的 Oracle Applications 查询自动补偿某些超时事件，然后继续进行正常处理。

不需要任何操作。

分布目标表格没有显示在自定义部件的属性页面中

在数据库中创建目标之后，“分布目标”表不会显示在自定义部件 (例如 "wt.wadm.FADProduct") 的属性页面中。

如果文件 <Windchill>\codebase\netmarkets\jsp\tgt\distributionList.jsp 的默认版本设计为不会显示自定义部件的分布目标表格，会发生此种情况。

对自定义部件 (例如 wt.wadm.FADProduct) 启用“分布目标”表。

1. 打开文件：<Windchill>\codebase\netmarkets\jsp\tgt\distributionList.jsp

2. 通过添加自定义部件类型，如下修改 if 语句。

if (oid.indexOf("wt.doc") != -1 ||

oid.indexOf("wt.epm") != -1 ||

oid.indexOf("wt.part") != -1 ||

oid.indexOf("com.ptc.windchill.mpml.processplan.MPMProcessPlan") != -1 ||

oid.indexOf("com.ptc.windchill.mpml.resource.MPMProcessMaterial") != -1 ||

oid.indexOf("com.ptc.windchill.mpml.resource.MPMTooling") != -1 ||

oid.indexOf("com.ptc.windchill.mpml.resource.MPMSkill") != -1 ||

oid.indexOf("wt.wadm.FADProducts") != -1)

3. 保存文件，然后重新启动 Servlet 引擎。

其他配置问题

手动部署 EAR 时，验证下列设置：

• DataResponse 队列名称，它应附加 ESIOMAdapter/Datasource (例如 ORAPTCPROD) 的值。

• Java 最大堆大小和 Java 线程堆栈大小设置：应分别大于 512 MB 和 512 KB。

现在部署应用程序，但不要启动服务。

EMS：在“JMS 管理”窗口中运行下列命令，以配置 JMS。使用合适的值替换 <DataResponse> 和 <EAI User>。例如，com.ptc.windchill.esi.DataResponse.ORAPTCPROD 和 ESISYS 等。

• create queue <DataResponse>

• setprop queue <DataResponse> secure

• grant queue <DataResponse> <EAI User> receive

• grant queue <DataResponse> <WC ESI User> send

• setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222

• commit

现在启动服务。

服务启动错误

验证以下内容：

• <Tibco_Home>/tra/domain/<Domain_Name>/application /logs

如果没有为服务启动生成日志，且进程 id 显示 "-1"，请尝试从 <Tibco_Home>/tra/domain/<Domain_Name>/application/<Application_Name> 文件夹运行相应的 *.sh 或 *.cmd 文件。这表示发生相关性错误，而该错误本应在启动服务器之前得以解决。

从 Windchill PDMLink 发布升级请求时，会创建多个“交付生产”工作流

如果 Windchill ESI 首选项发布升级请求的值为“否”，则会出现此问题。将该首选项设置为“是”，以便在发布升级请求时创建单个 RTM 工作流。

如果将 Windchill ESI“发布升级请求”设为“否”并发布升级请求，那么得到的 RTM 工作流与升级请求中的可升级次数一样多。