简介：面向Teamcenter平台SOA服务端开发者的入门参考资源，围绕SOAOperation主题，提供一个可直接借鉴的核心工具类实现。压缩包共1个Java文件，大小约7KB，代码封装了Teamcenter SOA常用操作，包括创建item、创建folder、查询对象属性等典型方法，并演示如何基于WSDL定义生成客户端代理、调用Teamcenter服务，有助于理解SOA服务端开发流程与接口调用方式。已有851人学习下载，适合具备Java基础、正在从事Teamcenter二次开发或PLM系统集成的工程师。借助这份精简示例，初学者可快速上手服务封装套路，有经验者也可作为代码结构对照模板；可在此基础上扩展业务功能，服务于系统集成与业务流程自动化场景，是一份实用的小型参考代码。
1. Teamcenter SOA 开发：不是配个 URL，而是把业务能力封装成可调用的服务操作
接到这样一个活：外部 MES 系统要实时读取 Teamcenter 里的物料和 BOM，催了好几次，说再不开放接口产线就得停。你打开 Teamcenter 一看，客户端是胖客户端，数据库不能直连，REST 接口又没现成文档。这时候你意识到，能走的路只有一条：Teamcenter SOA。这个标题里的 SOAOperation、soa 开发，说的就是把 Teamcenter 的业务能力封装成 SOA 操作，让第三方系统用标准方式去调用。它解决的是跨系统集成、权限收敛、业务流程复用这些事儿。这篇文章写给做 PLM 集成的开发者和实施顾问，照着能把环境准备、第一个操作落地，以及后续避坑串起来。新手能跟步骤走，熟手也可以直接跳到相关参数和踩坑对照。
2. 动手前先吃透 Teamcenter SOA 的三层模型：服务端、客户端和凭证生命周期
很多新人在 Teamcenter SOA 上翻车，不是因为代码写错，而是脑子里没建立三层模型。你在做 SOA 开发时，实际是在跟三个东西打交道：服务端注册好的服务接口、本地跑着的 Java 客户端、以及连接时的凭证状态。这三层各有各的时间点，先理清再写代码，后面所有问题都能归位。
2.1 服务端：SOA 操作不是“URL”，而是一组注册在 TC Server 上的服务方法
Teamcenter 不是把所有功能暴露成一个万能接口，而是按业务域拆成若干个服务接口，每个接口里有多个方法。常见的有 SessionService（会话管理）、ItemService（物料对象操作）、StructureService（BOM 结构操作）、QueryService（查询器操作）等等。每个服务接口都有自己的版本号，客户端调用时告诉服务器“我要哪个版本的服务”，服务器再决定怎么处理。这种设计在升级时优势很明显：新版本服务可以和老版本共存，只要客户端不换，行为不变。
有人问，为什么不能直接拿数据库连接让 MES 去查？因为 Teamcenter 的核心逻辑并不在数据库表里。物料的状态、被哪个 workflow 锁定、哪些用户有权限、属性映射规则，都在业务层计算。SOA 操作真正有价值的不是数据搬运，而是每次调用都会经过 Teamcenter 的权限校验和状态校验。举个例子，你用 SOA 的 ItemService 去读一个 Item，读到的结果不光是数据库里那几行，还有基于用户组、角色、项目上下文过滤之后的视图。这是裸 SQL 永远做不到的安全边界。
服务端怎么知道你是谁？靠登录时建立的会话。会话不是简单的用户名密码校验，而是一个被服务端认可的凭证。凭证绑定着用户组、角色和当前的应用上下文。所以你在写任何 SOA 操作之前，先得明确调用者是谁、用什么组、什么角色登录。这三个参数在 Teamcenter SOA 里是绕不过去的前置条件。很多初级集成项目把凭证写死在配置里，开发期没问题，上线后一换域账号就全崩，原因就是没理解凭证绑定权限这件事。
2.2 客户端：用 Java 客户端做最小粘贴验证
Teamcenter 官方客户端开发最常见的方式是 Java。你对着一堆 jar 包不用慌，核心思路是：建立连接、拿凭证、登录、发请求。下面这个代码块是我在本地跑通的最小连接示例，去掉一切业务操作，只验证能不能连上服务端。
import com.teamcenter.soa.client.Connection; import com.teamcenter.soa.client.CredentialManager; import com.teamcenter.services.strong.core.SessionService; import com.teamcenter.services.strong.core._2008_06.Session.LoginResponse; public class TcSoaMinimalConnect { public static void main(String[] args) { // 用于登录的用户组和角色，这组参数直接决定后面所有操作的数据权限 CredentialManager credentialManager = new CredentialManager(); credentialManager.setUserName("infodba"); credentialManager.setPassword("change_me"); credentialManager.setGroup("dba"); credentialManager.setRole("dba"); // 连接参数：服务器 IP、SOA 端口、协议前缀 // Teamcenter 11 到 13 的常见端口是 28080，实际以安装时配置为准 Connection connection = new Connection("10.10.20.30", 28080, credentialManager); try { // SessionService 是所有 SOA 操作的入口，先拿一个会话 SessionService sessionService = SessionService.getService(connection); LoginResponse loginResponse = sessionService.login(); if (loginResponse.shouldRetry()) { System.out.println("需要重新认证：" + loginResponse.getError()); } else if (loginResponse.getOperationReceiver() != null) { System.out.println("登录成功"); } else { System.out.println("登录失败，检查凭证和网络"); } } catch (Exception e) { e.printStackTrace(); } } }这段代码逻辑很简单，但值得说明几个参数。CredentialManager里的用户名、密码、组、角色是 Teamcenter 认证体系的四大件，你不要只填用户名密码，组和角色一旦为空，很多服务会返回“没有权限”的异常，而且这种异常不是报错，是返回一个空对象。Connection的端口是 SOA 服务的端口，不是 Web 端口，也不是 Teamcenter 胖客户端的端口。我用 28080 做示例，你实际项目里如果连不上，先去看tc_server的配置，别盲目改系统防火墙。
这段代码的用途是验证：JDK 版本对不对、jar 包齐不齐、网络通不通、凭证模型认不认。如果它跑通了，下一章的操作只是在这个基础上堆方法而已。
2.3 凭证模型：为什么你总是先拿到一个“票据”才能干活
Teamcenter SOA 的登录不是简单的发一个请求带用户名密码。服务端登录成功后，会生成一个票据，后续每个 SOA 操作都带着这个票据去走权限。这个设计最大的好处是：一次登录，多次操作，服务端不需要每次都查数据库里的用户表。开发时最常见的错误是，把login()写在每个业务方法里，导致每个操作都新建连接，登录开销全压在服务器上。
我一般会把连接和登录做成单例，或者用一个静态初始化块只在进程启动时执行一次。CredentialManager的生命周期也值得注意，它不是线程安全的，如果你在并发场景中多个线程共用同一个CredentialManager，可能互相覆盖用户名。常见做法是每个线程持有自己的凭证副本，或者用连接池。
凭证还有一个容易被忽略的属性：票证有效期。Teamcenter 默认的会话可能在空闲一段时间后失效。你测试时感觉没问题，但挂一个定时任务跑一晚上，第二天早上一看全是登录超时。解决办法不是拉长超时时间，而是在每次任务开始前检查会话状态，失效就重新登录。这是从“能跑”到“能上线”的分水岭。
3. 开发自己的 SOA 操作：从查询 Item 到创建 Item 的可复现步骤
上一章做完连接验证，这一章我们开始干正事。这里的核心是：不要贪多，先把一个操作跑通，再批量复制。聪明的做法是先实现一个只读查询，确认模型映射，然后再实现创建类操作。创建操作会带出更多属性，容易踩权限和必填字段的坑，放到下一章再讨论。
3.1 搭建客户端工程的四个文件：jar、classpath、配置和启动参数
Teamcenter SOA 开发环境不需要装额外的 IDE 插件，用普通的 Eclipse 或者 IntelliJ 都行。关键是工程里要引对 jar 包。不同版本的 Teamcenter 客户端库目录略有差异，但通常你会见到这几个角色：tcsoaclient.jar（包含连接和会话管理）、tcsoaservices.jar（包含具体服务接口）、tcsoacommon.jar（公共模型类）。千万不要把整个client目录的 jar 全拖进去，会造成类冲突。我一般只拉这三个核心包，加上你依赖的第三方库。
classpath 里还需要一个配置文件，通常是teamcenter.properties，里面配置服务地址、连接超时、语言等。文件内容大致如下：
# 服务端地址，多个服务端可以用逗号分隔 tc.soa.server=http://10.10.20.30:28080/tcsoa # 连接超时，单位毫秒，注意这里不是请求超时 tc.soa.connect.timeout=15000 # 字符集，特别是有中文属性时不要改成 UTF-8 以外的值 tc.soa.charset=UTF-8 # 日志级别，开发阶段用 DEBUG，生产环境用 INFO tc.soa.log.level=INFO文件名和 key 在不同版本里有差异，但你要搜的就是这几个单词。tc.soa.connect.timeout是建立连接的超时，不是业务请求超时，别把它调成大数字去等慢查询。请求超时有另一个参数，一般叫request_timeout。你可以在启动参数里用-D覆盖配置文件，例如-Dtc.soa.server=...，这样同一套代码可以切换测试和生产环境。
搭建环境时最容易翻车的是 jar 版本和服务端版本不一致。服务端升级 Service Pack 后，旧客户端一般还能跑，但如果服务端大版本升级（比如从 Teamcenter 11 升到 13），客户端的协议版本就对不上了。你在测试环境验证过，不代表生产环境可以跑，发布前一定要确认客户端 jar 包版本产品和服务器一致。这个版本不一致经常不爆错，而是返回一个“找不到服务”的 FaultString，下面避坑章会专门讲。
3.2 第一个 SOA 操作：查询 ItemRevision 并打印属性
查询 Item 和 BOM 是所有集成项目覆盖最多的场景。下面的代码演示通过 ItemService 创建一个查询，按 Item ID 找到对应的 ItemRevision，并打印版本号。这段代码看着长，但已经是缩到最短的可运行版本。
import com.teamcenter.services.strong.item.ItemService; import com.teamcenter.services.strong.item._2010_06.ItemWithOwners; import com.teamcenter.services.strong.item._2010_06.Specification; import com.teamcenter.services.strong.item._2010_06.WorkspaceObject; import com.teamcenter.services.strong.core.DataManagementService; import com.teamcenter.services.strong.core._2010_06.GetResponse; public class QueryItemDemo { public static void main(String[] args) throws Exception { // 复用上一章的连接初始化流程，这里假设 connection 已经创建 // Connection connection = initConnection(); ItemService itemService = ItemService.getService(connection); // 构造一个按 ItemID 精确匹配的查询条件 Specification spec = new Specification(); spec.setFilter(ItemService.FilterType.ITEM_ID); spec.setFilterValue("000123"); // 限制结果数量，避免数据量大时拉回整个库 spec.setResultCount(1); ItemWithOwners[] items = itemService.findItems(spec); if (items == null || items.length == 0) { System.out.println("未找到对应的 Item"); return; } // findItems 返回的是 Item，不是 ItemRevision，要拿到版本信息需要再读一次 DataManagementService dataService = DataManagementService.getService(connection); GetResponse response = dataService.getObjects(items[0].getUid()); WorkspaceObject target = response.getObjects()[0]; // 这里是粗粒度打印，实际项目中你会用属性名去取 System.out.println("对象 UID = " + target.getUid()); System.out.println("对象类型 = " + target.getTypeName()); } }这段代码体现了一个重要观念：Teamcenter SOA 不像 SQL，你不能在一个方法里把所有关联数据全部拿出来。findItems只负责定位对象，拿到 UID 之后，还要用DataManagementService.getObjects去取完整对象。两个方法之间是有网络往返的，如果你在循环里这么写，性能会很差。后面性能章我会讲怎么合并请求。
参数说明：FilterType.ITEM_ID是精确匹配 Item ID，如果你想模糊查询，得用QueryService配合命名查询，不要用findItems自己做 LIKE。setResultCount(1)是一个很重要的习惯，很多新手不设置这个参数，直接把全库匹配结果拉回来，几十万对象瞬间把内存打爆。你拿这个代码做模板时，一定要根据业务限制结果集大小。
这里还有一个容易忽略的点：WorkspaceObject是业务对象的根类型，Item、ItemRevision 都是它的子类。打印属性时你拿到的永远是基类引用，要取出具体业务属性，需要先判断类型然后强转。最稳妥的方式是用getObjects加载后，通过TypeService获取属性定义，再按属性名取值。很多集成框架的所谓“万能读取器”就是干这件事的。
3.3 参数怎么设：凭证、组角色、locale 是前三个必调项
每个 SOA 方法都会有多个可调参数，但根据我的经验，优先检查永远是三个参数：凭证上下文、组角色和 locale。
先说凭证和组角色。Teamcenter 的权限是基于用户归属的组和角色来算的。同一个用户，用dba组登录和用manufacturing组登录，看到的对象范围可能完全不同。代码里的itemService调用其实是无状态的，每次请求都会自动带着连接里的凭证信息去服务端匹配权限。所以如果你的查询结果为空，先不要怀疑服务端数据没有，你先自查是不是当前凭证对目标对象没有读权限。
再说 locale。Teamcenter 里的属性名和值是分语言存的，你如果不在连接参数里指定 locale，服务端默认返回服务器的 locale。常见现象是，你输入英文属性名能取到值，切到中文属性名就取不到，或者返回的值变成???。正确做法是在 CredentialManager 里设置 locale，或者在请求头上指定语言。代码里可以这样设置：
credentialManager.setLocale(Locale.SIMPLIFIED_CHINESE);第三个必调项是结果集的排序。Teamcenter 的findItems虽然支持设置排序字段，但不同版本排序写法有差异。我不建议在 SOA 调用里做复杂排序，宁可拉回有限数据后在客户端排序。SOA 是业务接口，不是查询优化器，你指望它在服务端做大数据量的分组排序，回报率很低。这一章把读路径打通就够了，下一章我们进入写操作，这是集成项目真正的高风险区。
4. 把创建 Item 变成可复用的 SOA 操作：方法、参数表和错误码定位
只读查询跑通后，下一步要面对的是创建类操作。创建 Item 看起来简单，实际上牵扯必填属性、命名规则、类型扩展、状态初始化和权限检查。很多项目在“能创建”和“能上线”之间差着十万八千里。这一章用一个创建 Item 的完整例子，把写操作的关键点拆开。
4.1 创建 Item 的 SOA 调用：从对象映射到数据模型
创建 Item 的入口是ItemService.createItems，注意是复数，它支持一次创建多个。创建时不直接给 Item 赋值，而是先构造一个Item对象模型，也就是所谓的“bean”。下面这个例子创建了一个最简单的 Item，并且设置了 ID、名称和初始类型。
import com.teamcenter.services.strong.item.ItemService; import com.teamcenter.services.strong.item._2010_06.CreateItemRequest; import com.teamcenter.services.strong.item._2010_06.CreateItemsResponse; import com.teamcenter.services.strong.item._2010_06.Item; public class CreateItemDemo { public static void main(String[] args) throws Exception { ItemService itemService = ItemService.getService(connection); Item newItem = new Item(); newItem.setItemId("MOTOR-001"); newItem.setDescription("异步电机样件"); newItem.setType("MOTOR_Item"); // 这个类型名必须在 BMIDE 中已定义 CreateItemRequest request = new CreateItemRequest(); request.setItems(new Item[] { newItem }); CreateItemsResponse response = itemService.createItems(request); if (response.getResponse()[0].getServiceData().isPartialError()) { System.out.println("部分失败: " + response.getResponse()[0].getServiceData().getError()); } else { System.out.println("创建成功，UID = " + response.getResponse()[0].getItem().getUid()); } } }这个例子的参数很少，但每个都有讲究。Item.setType("MOTOR_Item")指定的是你在 BMIDE 里扩展的类型，不是默认的Item。如果你用默认类型，ID 命名规则、版本规则都会用默认配置，别人改了类型导致数据一致性出问题。创建前要确认这个类型已经部署到目标环境，测试环境有但生产环境没有，是集成上线最常见的翻车点。
CreateItemsResponse是复数响应，因为一次可以创建多个对象，所以返回结构里套了一层数组。你要习惯从response.getResponse()[0]去取每个对象结果。每个结果里都有一个ServiceData，里面放着错误码和错误信息。这里有个经验：不要只看isPartialError()，还要看getServiceData().getError()的具体错误码。错误码是 Teamcenter 定位写操作问题的唯一可靠线索。
4.2 常用服务操作对照表：哪天不用为了一个查询重写客户端
SOA 开发到后期会发现，大部分业务操作是几个服务的排列组合。下面这张表是我常用的服务快速对照表，按集成场景分好，评审方案时可以当作检查清单。
| 服务类 | 典型方法 | 适用业务场景 | 注意事项 |
|---|---|---|---|
| SessionService | login/logout | 连接建立、会话注销 | 凭证和组角色必须提前设置 |
| ItemService | findItems/createItems | 物料查询、创建 | 创建时 type 必须匹配 BMIDE 定义 |
| DataManagementService | getObjects/setProperties | 对象加载、属性更新 | 大对象列表要分批，单次不要超过 500 个 |
| StructureService | createRevision/revise | BOM 版本升级 | revise 操作受状态和权限双重约束 |
| QueryService | getSavedQueries/executeQuery | 运行命名查询 | 查询器结果集默认有上限，要处理分页 |
| WorkflowService | getTaskList/performAction | 审批任务处理 | 特别注意状态变更后的权限 |
| FileManagementService | importFile/exportFile | 附件和数据集文件 | 文件服务与对象绑定，注意临时文件清理 |
这张表不是让你背的，是让你写代码之前先做“服务对应”。业务需求里只要涉及读对象，就优先看DataManagementService；涉及创建物料，就选ItemService；涉及 BOM 层级，用StructureService。一旦找到对应服务，不要每个方法都从零写连接，而是封装成一个公共调用层，把连接、凭证、异常处理全部放进一个工具类里。第三、四章的代码可以整合进这个工具类，后面新增操作只加方法，不动基建。
4.3 把多个 SOA 操作编排成一个业务操作：事务边界和一致性
实际集成的业务操作往往不是单点调用，而是“创建 Item、创建 Dataset、挂在 BOM 下”这样的组合。Teamcenter SOA 对写操作有一套事务控制策略。默认情况下，单个服务方法可能是一个独立事务，跨服务的方法则没有一个全局事务开关。你需要自己定义事务边界：哪些操作必须一起成功，哪些允许部分成功。
常见做法是，把多个 SOA 操作编排在一个业务服务里，先做前置检查，再执行写操作，最后统一提交。Teamcenter 的写操作通常不需要显式 commit，只要方法返回没报错就算生效。但如果你先创建了 Item，然后创建 BOM 行时失败，前一个 Item 并不会自动回滚，需要你自己调用删除方法把脏数据清掉。这就是 CAx 集成项目里所谓的“补偿逻辑”。
我在设计 SOA 操作时，会为每个组合操作定义一个“最小成功单位”。例如“创建一个物料并挂到 BOM”的最小成功单位是“BOM 行成功创建”，在创建 BOM 行之前即使 Item 已建好，也要在异常分支做回滚删除。这个补偿逻辑看起来多加了几行代码，但能救你于数据不一致的水火之中。除了补偿，还要留意操作返回的ServiceData，一个组合操作里任何一步出现partialError，都要立刻中断后续操作，别存侥幸心理。
5. Teamcenter SOA 开发避坑指南：现象、原因和一次性解决方法
写 SOA 客户端最耗时间的不是写业务代码，而是排查那些“第一次见、第二次就懂”的问题。下面的坑都是我在不同项目里真实碰过的。每条按现象、原因、解决三步写，你可以直接把代码里的习惯对着改。
5.1 登录时抛 NullPointerException：凭证没进 CredentialManager
现象：调用login()或SessionService.getService()时，直接在CredentialManager内部抛出NullPointerException，堆栈指向getUserName()返回 null。
原因：CredentialManager实例创建之后，用户信息是通过 setter 放进去的，但你在多环境切换时，可能在启动流程里漏调了setGroup()或setRole()。Teamcenter 的凭证类对缺失参数的处理很粗暴，不会提示“用户名不能为空”，而是直接空指针。
解决：用一个初始化方法把凭证四项集中填好，并且在一个地方写断言。代码里加一个简单的检查，例如在调用登录前判断四人组是否齐全。这个习惯能让你在接入 SSO 单点登录时不被一堆空指针淹没。
5.2 调用任何服务都返回 FaultString “Service not found”：客户端和服务端版本不在一条时间线
现象：连接正常，登录也正常，但每次调用ItemService.getService(connection)之后，一执行方法就抛FaultString: Service not found。
原因：服务端已经升级了 SOA 服务版本，而客户端的服务接口 jar 还是旧版本，或者反过来。Teamcenter 的 SOA 服务是有命名空间和版本号的，客户端请求的服务路径在服务端不存在，就会返回这个错。
解决：先去服务端安装目录下的installed_services里查当前服务版本，然后把你本地的tcsoaservices.jar换成与服务端匹配的版本。不要用“测试环境正常”来判断生产环境没问题，服务端小版本不一致时，登录接口还可能兼容，业务接口往往直接找不到。
5.3 中文属性读出来是问号或者乱码：字符集没固定成 UTF-8
现象：创建记录时传入的中文描述在客户端显示正常，但另一套系统通过 SOA 读出来变成了???，重启后又恢复部分正常。
原因：Teamcenter 服务端和客户端之间的字符集协议不匹配。客户端默认可能用自己的系统编码，服务端按 UTF-8 解码，两边不一致就会在传输层丢失数据。
解决：在连接初始化时显式设置credentialManager.setLocale(Locale.SIMPLIFIED_CHINESE)，并且环境变量里固定JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8。另外要检查配置文件里的tc.soa.charset，不要相信服务器默认值。
5.4 本地能连上，测试环境也连上，生产环境连不上：防火墙和 hosts 双面夹击
现象：代码在开发环境跑得好好的，部署到生产网络的 Linux 服务器上，报ConnectException: Connection refused或超时。
原因：SOA 服务端口没有在生产防火墙放通，或者生产服务器/etc/hosts里没有把 Teamcenter 服务器主机名解析到实际 IP。很多生产环境禁用了 DNS 反向解析，你拿开发环境的主机名去访问，会解析到 127.0.0.1。
解决：先用telnet 生产服务器IP 28080测试端口通不通。能通再看 hosts。如果端口不通，找网络找防火墙策略；如果 hosts 不对，在应用环境变量里直接指定目标 IP，不要依赖主机名。这个坑最容易在发版当天遇到，提前做好端口放行检查可以少熬一次夜。
5.5 查询成功但结果集为空：权限模型比你想得更严格
现象：同一套查询代码，用管理员账号能查到数据，用业务账号查不到，或者查到的结果少了很多。
原因：Teamcenter 的对象权限是由 ACL（访问控制列表）决定的。SOA 客户端会继承登录用户的组和角色，如果你的业务账号只被授予了部分数据权限，它看不到其他部门创建的记录。
解决：不要认为“登录成功就是有权限”。在集成项目里，明确每个 SOA 操作的服务账号应该归属于哪个组，并且在权限矩阵里验证结果。最容易漏的是“组”这一项，很多实施顾问只关注角色，忽略了组也是权限过滤的一部分。你在上线前把所有接口账号的组、角色、权限范围列一张表，让业务负责人签字，能避免上线后扯皮。
5.6 批量循环调用越来越慢：连接和会话没有复用
现象：用 for 循环调用 1000 次findItems，前 100 次很快，后面越来越慢，最后甚至超时。
原因：很多初学者在循环里重新创建Connection和SessionService，导致每次迭代都进行一次网络握手和登录。服务端的会话表被打满，旧会话还没有释放，新连接就开始报超时。
解决：把连接、凭证、服务对象提到循环外面，只保留一个全局会话。如果业务确实需要分批处理，每批之间加适当的 sleep 或者使用线程池而不是 for 循环。连接复用是 SOA 客户端性能的第一条铁律。
6. 最后一公里：连接复用、批量调用和验证日志
SOA 客户端能跑通只是第一步，上生产的稳定程度取决于三个细节：连接怎么复用、批量请求怎么合并、问题怎么定位。
连接复用的做法很简单，就是把Connection和SessionService做成进程级单例。Teamcenter SOA 的服务对象本身是轻量的，但连接背后的凭证状态是重量的。一个 Java 进程里维护一个长连接，比每次任务重建连接要快一个数量级。如果你有定时任务，建议用ScheduledExecutorService去管理任务周期，任务内部所有操作共用一个连接，每次开始前检查会话是否过期。
批量调用是最容易偷懒的地方。比如要读取 500 个对象的属性，新手会写一个循环，每个对象调用一次getObjects，这样会带来 500 次网络往返。正确做法是把 UID 拼成一个数组，一次调用getObjects(uidArray)，让服务端一次返回。Teamcenter 的批量方法不是摆设，createItems支持批量创建，getObjects支持批量读取，连findItems也支持多条件批量。你在设计接口参数时，尽量把输入设计成数组，而不是单个 ID。
验证日志是生产环境下唯一能救命的东西。开发阶段不要只System.out.println，应该用统一的日志框架，打印三个信息：请求的服务名、输入参数的 UID 列表、返回的ServiceData错误码。我在集成项目里会专门写一个日志过滤器，把所有 SOA 请求和响应按 traceId 串起来。这样一次业务操作涉及多个 SOA 方法时，你能通过 traceId 在日志里把整条链拉出来。不要小看这一步，生产环境的诡异问题，十有八九是靠这种日志链定位的。这个习惯我踩了两年才固化下来，希望帮到你。
本文还有配套的精品资源，点击获取
