TeamcenterKnowledge

Skills

TC SOA Docs Navigation

Skill tc-soa-docs-navigation. Find the truth about a Teamcenter SOA operation in the local Help Server documentation set (WSDL/XSD schemas, Services Reference javadoc, SDK samples, help server at localhost:51000). The WSDLs are the ground truth the javadoc and the samples are not. Use when you need the real service name, version, required members, or deprecation status of an operation.

Everything below is on this machine. No network, no Support Center login.

First: pick the right release kit

★ Two kits are installed side by side, deliberately. 2506 for the cloud tier and most existing work; 2606 for the local Hyper-V VM (TC2606 / SIEMENSDC). Grepping the wrong one produces confident, wrong answers.

2506 (default for existing work) 2606 (the local VM)
WSDL + XSD soa_client_wntx64\soa_client_wntx64\wsdls\ tc2606_SOA_Client_wntx64\soa_client\wsdls\
Services Reference docs-teamcenter-2506-services_reference\ docs-teamcenter-2606-services_reference\
Javadoc docs-teamcenter-2506-javadoc\ docs-teamcenter-2606-javadoc\
Product help PDFs collections\...\PL20241125556497283\en-US\tc_help\ collections\...\PL20251212545240207\en-US\tc_help\

All paths are relative to D:\Siemens\Help Server\. 989 xsd in the 2606 set against 983 in 2506. The PDF collection IDs are opaque, so confirm a release from a PDF's title page rather than the folder name. The prebuilt indexes in data/ below were built from the 2506 kit.

The rest of this skill uses 2506 paths in its examples. Substitute the 2606 column when the target is the VM. See tc-vm-operations.

What Where What it is actually good for
Help Server app http://localhost:51000 Browsing the product help
WSDL + XSD schemas D:\Siemens\Help Server\soa_client_wntx64\soa_client_wntx64\wsdls\ The wire contract. Ground truth for required vs optional members
Services Reference D:\Siemens\Help Server\docs-teamcenter-2506-services_reference\services_reference\ Prose per operation, and deprecation notices with named successors
Java API javadoc D:\Siemens\Help Server\docs-teamcenter-2506-javadoc\javadoc\ Java-side types and classes
SOA Client SDK samples D:\Siemens\Help Server\soa_client_wntx64\soa_client_wntx64\{java,cpp,net}\samples\ Real end-to-end client flows (WireHarness, FileManagement, Classification, HelloTeamcenter, OAuth variants)

Use the prebuilt indexes first

Grepping ~1,960 WSDL files per lookup is slow enough that agents skip the step and start guessing payloads instead, which is exactly how the expensive failures happen. Two indexes in data/ remove the excuse:

python scripts/soa_lookup.py createOrReConfigureBOMWindows   # route + deprecation + required members
python scripts/soa_lookup.py --grep bomwindow                # find an operation by fragment
python scripts/soa_lookup.py --struct CreateWindowsInfo3 --xsd Cad1906StructureManagement.xsd
  • data/soa_wsdl_index.json: 1,464 operations across 214 service classes, each mapped to its JSON REST route, its .wsdl, its .xsd, and its request struct.
  • data/soa_deprecations.json: 174 deprecated operation names, 92 with an explicitly named successor, extracted from the Services Reference HTML.

Rebuild either after a Help Server update:

python scripts/build_soa_index.py
python scripts/build_deprecations.py

Why the WSDLs are the decisive resource

The javadoc gives you a field's Java type and a prose description. Only the XSD gives you the thing that actually breaks calls: minOccurs. An <xsd:element> with no minOccurs attribute is required, which for a ModelObject field means sending the NULLTAG sentinel explicitly rather than omitting the key.

None of the three SDK samples surface this, because all three still call an older, looser, deprecated sibling operation. WireHarness in Java, C++, and .NET all call createBOMWindows, which has been a silent no-op since Teamcenter 12.2. The samples are useful for flow, not for correctness.

Worked example, straight out of Cad1906StructureManagement.xsd, where the schema documentation literally says so:

CreateWindowsInfo3
  REQUIRED  bomWindow   : ModelObject   "Must be NULLTAG when creating a new window."
  REQUIRED  item        : ModelObject   "or NULLTAG if itemRev is specified"
  REQUIRED  itemRev     : ModelObject
  REQUIRED  bomView     : ModelObject   "or NULLTAG to use the default view"
  REQUIRED  revRuleConfigInfo
       REQUIRED  props : RevisionRuleEntryProps  (@unitNo, @date, @today all required)
  REQUIRED  activeAssemblyArrangement : ModelObject
  REQUIRED  configContext             : ModelObject
  REQUIRED  @clientId

File naming, and the additive-version trap

WSDL/XSD files are named <Package><YYMM><ServiceName>.{wsdl,xsd}, for example Cad1906StructureManagement.xsd for the cad._2019_06 interface.

Teamcenter's SOA schema is additive per version. An operation appears only in the file for the version it was introduced at, not in every later release's file. So grep the version file matching the java package name (_2019_06 becomes 1906), not the deployment's own release number. Looking in Cad2506StructureManagement.xsd for a 2019 operation finds nothing and reads like "the operation does not exist on 2506."

The true service identity is the .xsd's targetNamespace, not the filename: http://teamcenter.com/Schemas/Cad/2019-06/StructureManagement becomes the route Cad-2019-06-StructureManagement. Multi-segment packages work the same way: .../Schemas/Internal/Administration/2007-06/Authorization becomes Internal-Administration-2007-06-Authorization.

Searching for an operation whose owning service you do not know

Grep the operation name across every .xsd/.wsdl, not just the package you would guess from the docs index. That is what found getTypeDescriptions2 living on Core-2015-10-Session rather than on DataManagement, in under a minute, after it had looked like a broken feature.

grep -l "getTypeDescriptions2" "D:/Siemens/Help Server/soa_client_wntx64/soa_client_wntx64/wsdls"/*.xsd

Services Reference paths

services_reference/
  java_loose/   <- read this one
  java_strong/
  net/
  soa/          <- Doxygen C++ client doc, NOT the wire protocol

Page path pattern:

java_loose/<Template>/com/teamcenter/services/loose/<domain>/_<YYYY_MM>/<Service>.html
e.g. java_loose/Foundation/com/teamcenter/services/loose/cad/_2019_06/StructureManagement.html

<Template> is the deployment template that ships the service (Foundation, AttrTargetMgmt, Cla0classification, SystemsEngineering, Hrn, ...), and it is not predictable from the domain name: cad lives under Foundation. Find it with a path search rather than guessing:

find "D:/Siemens/Help Server/docs-teamcenter-2506-services_reference/services_reference/java_loose" \
     -path "*loose/cad/_2019_06*" -name "*.html"

Read the method-detail section, not just the summary table. Deprecation notices and the exact required/optional prose per parameter are there.

What the kit does NOT contain

The SDK ships the public services only. Active Workspace's own internal operations are real, in daily use by the AWC, and absent here: Internal-ActiveWorkspaceBom-2025-06-OccurrenceManagement/addObject5, Internal-IcsAw-2019-12-Classification/findClassificationInfo3, AttrTargetMgmtAW/importParameterExcel, Internal-AWS2-*, and others.

"Not in the WSDLs" is not evidence the operation does not exist. For those, capture the call from Active Workspace itself: see tc-capture-awc-calls.

Related skills

tc-soa-payload-shapes, tc-capture-awc-calls, tc-bom-structure.

Generated from skills/tc-soa-docs-navigation/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.