3. 版本兼容性矩阵分析

Teamcenter 的升级迁移之所以比一般应用复杂，根本原因在于它不是一个孤立软件，而是由应用服务器、数据库、中间件、客户端运行时、浏览器前端、CAD 集成组件和 T4x 集成框架共同组成的多层技术栈。任何一层版本不匹配，都可能在升级后表现为登录失败、BOM 打开异常、CAD 检入报错或 T4x 消息堆积。因此，在制定升级方案前，必须先建立一张“版本兼容性矩阵”，把 TC 版本作为基准，逐层锁定各依赖组件的可用版本区间。

一、兼容性矩阵的六个维度

Teamcenter 官方发布的 Software Compatibility Matrix（常简称 SCM）是唯一权威依据。它通常按 TC 主版本（如 TC 13.3、TC 14.2、TC 2312、TC 2406）列出以下六类依赖：

• 数据库：Oracle 与 SQL Server 的版本、补丁级别、字符集、RAC/AlwaysOn 支持情况；
• Java 运行时：JDK/JRE 版本（如 JDK 8、JDK 11、JDK 17）及供应商（Oracle JDK、OpenJDK、IBM Semeru）；
• 应用中间件：WebLogic 版本（12.2.1.4、14.1.1）及是否支持集群；
• 浏览器：Active Workspace 与 Web 客户端支持的 Chrome、Edge、Firefox 版本区间；
• CAD 集成：NX、SolidWorks、CATIA、Creo 等与 TC Integration 的匹配版本；
• T4x：T4x 框架版本、T4x 服务端与 TC 服务端的对应关系。

这六个维度不是并列关系，而是以 TC 版本为中心向外辐射的约束网络。下图给出一个典型的兼容性约束关系示意，帮助理解“基准版本—依赖组件—约束方向”的结构。

二、数据库与 TC 版本的匹配规则

数据库是升级中最难回退的一层，因此必须最先确认。以 TC 14.2 为例，官方支持 Oracle 19c（19.3 及以上）和 SQL Server 2019（15.x），TC 2312 起逐步要求 Oracle 19c 或 21c，SQL Server 则要求 2019 或 2022。匹配规则的核心不是“大版本号相同”，而是补丁级别与字符集：Oracle 必须使用 AL32UTF8 字符集，SQL Server 必须使用区分大小写的排序规则（如 Latin1_General_CS_AS），否则 TC 的元数据查询会出现大小写敏感错误。

实操中建议按以下顺序核对：

1. 从 SCM 中查出目标 TC 版本支持的数据库大版本列表；
2. 确认当前数据库补丁级别是否落在支持区间内，例如 Oracle 19.3 到 19.22 之间；
3. 检查字符集与排序规则是否满足 TC 要求；
4. 若使用 RAC 或 AlwaysOn，确认 TC 是否声明支持该高可用模式。

三、Java 与 WebLogic 的联动约束

Java 版本与 WebLogic 版本必须成对考虑。WebLogic 12.2.1.4 官方支持 JDK 8 和 JDK 11，而 WebLogic 14.1.1 支持 JDK 11 和 JDK 17。TC 14.2 通常运行在 WebLogic 12.2.1.4 + JDK 11 组合上，TC 2312 及以上则推荐 WebLogic 14.1.1 + JDK 17。若只升级 TC 而保留旧 JDK，可能出现类加载失败或 TLS 握手异常；若只升级 JDK 而 WebLogic 未同步，则中间件启动阶段就会报版本不兼容。

一个常见的教学示例参数如下：

TC 版本: 14.2
WebLogic: 12.2.1.4.0
JDK: 11.0.20 (Oracle JDK 或 OpenJDK)
JAVA_HOME: /opt/java/jdk-11.0.20
WL_HOME: /opt/oracle/wlserver_12.2.1.4
启动参数: -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2

核对时，先确认 WebLogic 的 java.version 输出与 SCM 一致，再检查 TC 服务端 tc_menu 或 TC_ROOT 下的 JVM 参数是否指向正确 JDK。若使用集群，还需确认各节点 JDK 版本完全一致，避免节点间通信失败。

四、浏览器与 CAD 集成的匹配要点

浏览器层主要影响 Active Workspace 和 Web 客户端。TC 2312 起，Active Workspace 通常只支持 Chrome 和 Edge 的最近两个大版本，Firefox 支持范围收窄。若企业内仍在使用 IE 模式或旧版 Edge，升级后会出现页面渲染错乱、控件无法加载等问题。建议在升级前统一浏览器基线，并在组策略中锁定自动更新范围。

CAD 集成层则更复杂。NX 与 TC 的集成版本必须严格对应，例如 TC 14.2 通常匹配 NX 1980 至 NX 2007 系列；SolidWorks 集成需确认 TC Integration 插件版本；CATIA 和 Creo 也各有独立的兼容列表。CAD 集成不匹配的典型表现是：在 CAD 中执行“检入”时提示“无法连接到 TC 服务器”或“BOM 行无法解析”。此时应优先核对 CAD 集成插件的版本号，而不是盲目调整 TC 服务端参数。

五、T4x 的版本对应关系

T4x 是 Teamcenter 与外部系统（如 ERP、MES）集成的消息框架。T4x 服务端版本必须与 TC 服务端版本保持对应，例如 TC 14.2 对应 T4x 14.2，TC 2312 对应 T4x 2312。T4x 客户端（如 T4x 连接器）可以略低于服务端，但不得高于服务端。若 T4x 版本错配，常见现象是消息队列积压、事务无法提交或日志中出现“protocol version mismatch”。

核对 T4x 时，应同时检查：T4x 服务端版本、T4x 客户端版本、TC 服务端版本、以及 T4x 使用的 JMS 提供者版本。四者需在同一兼容区间内。

六、兼容性矩阵的落地检查表

将上述规则整理为一张可执行的检查表，便于升级前逐项确认。下表为示例结构，实际字段和取值需以官方 SCM 为准。

总结来说，版本兼容性矩阵分析的核心动作是：以目标 TC 版本为基准，逐层锁定数据库、Java、WebLogic、浏览器、CAD 集成和 T4x 的可用版本区间，并在升级前完成逐项核对与差异处理。只有六层全部落在兼容区间内，升级迁移才具备可执行的技术前提。