TeamcenterKnowledge

Skills

TC Query Discovery

Skill tc-query-discovery. Read Teamcenter over SOA. getProperties as the universal traversal primitive, the OOTB saved-query chain (Item Name / Item ID / General... / Dataset Name) with its parallel-array trap, type discovery, and the types that return zero from a saved query for reasons that are not absence. Use for any TC read, search, or "does this type exist here" question.

getProperties is the reliable primitive

Core-2006-03-DataManagement/getProperties

{"objects":[{"uid":"<uid>"}],
 "attributes":["object_name","object_string","object_type","owning_user"]}
  • The result's modelObjects come back at top level, not inside ServiceData.
  • Each property has uiValues (display) and dbValues (raw). Read both; a property can show a friendly ui value with an empty db value, which means nothing is actually bound. att0Uom showing each with empty db is the classic case.
  • Reference and relation properties carry related uids, so this doubles as structure traversal. See tc-relations-traceability.

It works on any object, including a relation's own ImanRelation uid.

Saved queries: the search path

Three calls, in order. There is no shortcut.

Query-2006-03-SavedQuery/getSavedQueries   -> find the query object by name
Query-2006-03-SavedQuery/executeSavedQuery -> run it (limit is REQUIRED)
Core-2006-03-DataManagement/getProperties  -> load the hits' properties

entries and values are PARALLEL ARRAYS, not an object. This is the shape that faults 214022 "JSON parsing" with no other clue if you get it wrong:

{"query":{"uid":"<query uid>","type":"ImanQuery"},
 "entries":["Item ID"],
 "values":["041390"],
 "limit":25}

Not {"entries":[{"key":..., "values":[...]}]}.

Useful OOTB queries:

Query name entries Finds
Item Name ["Item Name"] items by name, wildcards allowed (Crack Test*, *)
Item ID ["Item ID"] look up by item id, which "Item Name" will not do
General... ["Type"] every object of a business-object type
Dataset Name ["Dataset Name"] freestanding datasets

executeSavedQuery (singular) is what works. The plural executeSavedQueries rejected every shape tried, despite the Services Reference marking the singular deprecated in its favour.

Zero results that are not absence

  • UnitOfMeasure has no object_name, so General... / a type query returns 0 for it. That is not evidence the table is empty: the same site had 649 of them, enumerable only via its own site-specific ADP UOM Query saved query (fields Symbol, Description).
  • Runtime occurrence view types (Arm0RequirementElement, Arm0RequirementSpecElement, GDELine, BOM lines) return 0 because they are not persistent objects. The name is valid; you are querying the wrong store. Their uids look like SR::N::... and come from structure expands or AWC URLs.
  • A site-specific saved query may be the only enumeration path for a given population. Always list getSavedQueries on a new instance before concluding something cannot be enumerated.

Reads that lie without erroring (added 2026-08-28, from the Cameo canvass)

  • tc_query_by_type lists at most 50 objects however large the correct nFound is, and max_results does not lift the cap. Build inventories from nFound plus per-uid getProperties; a census built off the list length forced a real retraction to two sessions. (wildfire + MSP2 sessions, vm2606, 2026-08-26)
  • checked_out / checked_out_user live on the ItemRevision. Reading them off the Item master returns blank with no error, which reads exactly like "released". Resolve the revision uid first. (MSP2 session, vm2606, 2026-08-26)
  • last_mod_date does not move on a connector Publish, neither on the parent revision when Deep-Sync children land nor on the published items themselves, so timestamp comparisons against file mtimes produce false negatives by construction. Continuous checkout to one user across the window is the hard "no Check-In happened" signal. (wildfire + auditor sessions, 2026-08-26)

Type discovery

Question Call
Does type X exist here, and what are its properties? Core-2015-10-Session/getTypeDescriptions2 with {"typeNames":["X"],"options":{"typeIntentSet":["MODELOBJECTS"]}}
What subtypes are displayable? Core-2013-05-DataManagement/findDisplayableSubBusinessObjectsWithDisplayNames

getTypeDescriptions2 is on Core-2015-10-Session, not on DataManagement. Calling it on Core-2008-06-DataManagement returns a generic InternalServerException for every type name including real ones, which looks exactly like a broken feature.

A genuine "this module is not installed here" result looks like this: TC's MDConnectivity module (Mdconnectivity-2014-10-MDConnectivity/findConnectionsOnPort) matched the need perfectly by name and struct shape, but its core type Mdc0ConnectionElement did not exist per getTypeDescriptions2. That is a real negative, established by a type check, not by a fault code.

Note that tc_discover_types itself has faulted on some instances. Treat that as an instance quirk rather than a struct error.

Ground the data model without a connection

saberdatamodel.xcelerator.us hosts a real BMIDE export for Saber 2.0 / TC 2506: public/models/saber-2.0/objects.json (8,571 business objects with inheritance) and rules.json.grm (1,952 relation-type / primary-type / secondary-type rows). Reading those two files directly, rather than guessing candidate type names, is what turned domain cracks from ~50 blind attempts into first-or-second-try hits.

Offline SOA operation catalogs also exist: tc-mcp/data/soaOperations.json (1,592 operations) and this repo's data/soa_wsdl_index.json (1,464 operations with their WSDL/XSD and request struct).

Deep links

A clickable Active Workspace link to any object:

<host>/#/com.siemens.splm.clientfx.tcui.xrt.showObject?uid=<uid>

Related skills

tc-soa-session, tc-relations-traceability, tc-verify-and-cleanup, tc-soa-docs-navigation.


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