TC Capture AWC Calls

Skill tc-capture-awc-calls. Crack an undocumented Teamcenter capability by capturing Active Workspace's own network calls instead of guessing SOA operation names. The fetch/XHR interceptor recipe, when to reach for it, and the two wrong conclusions this method overturned. Use when an operation is not in the WSDL kit, or after two or three failed blind attempts to guess a service name or version.

When to use this

Reach for capture as soon as either is true:

• The operation is not in data/soa_wsdl_index.json. The SDK ships the public services only; every Internal-* operation the AWC uses daily is absent (Internal-ActiveWorkspaceBom-2025-06-OccurrenceManagement/addObject5, Internal-IcsAw-2019-12-Classification/findClassificationInfo3, AttrTargetMgmtAW/importParameterExcel, Internal-AWS2-*).
• You have made two or three blind tc_call attempts at a service name or version string and are still getting 214085 or 214086.

Guessing operation and version strings for a UI-only capability is a low-yield trap. One documented run burned roughly 50 attempts across wrong service names, wrong domains and wrong version strings, and produced two confidently wrong conclusions along the way. The capture that replaced it worked in one shot.

The recipe

1. Open the Active Workspace client in a browser you can run JavaScript in.
2. Inject an interceptor that wraps window.fetch and XMLHttpRequest.prototype.send, pushing {url, method, body} for any /RestServices/ call into a global array.
3. Perform the real action in the UI.
4. Read the captured payloads back.

The AWC hands you the exact operation name, version, and body it uses.

window.__cap = [];
(function () {
  const f = window.fetch;
  window.fetch = function (input, init) {
    try {
      const url = typeof input === "string" ? input : input.url;
      if (url && url.includes("/RestServices/")) {
        window.__cap.push({ url, method: (init && init.method) || "GET",
                            body: init && init.body });
      }
    } catch (e) {}
    return f.apply(this, arguments);
  };
  const s = XMLHttpRequest.prototype.send;
  const o = XMLHttpRequest.prototype.open;
  XMLHttpRequest.prototype.open = function (m, u) {
    this.__m = m; this.__u = u; return o.apply(this, arguments);
  };
  XMLHttpRequest.prototype.send = function (body) {
    try {
      if (this.__u && this.__u.includes("/RestServices/")) {
        window.__cap.push({ url: this.__u, method: this.__m, body });
      }
    } catch (e) {}
    return s.apply(this, arguments);
  };
})();

Then read JSON.stringify(window.__cap, null, 1).

Any surface that can evaluate JavaScript in the page works: browser devtools, or an automation tool's javascript_tool. When a UI-only recipe needs cracking and DevTools is not reachable from your automation surface, this is the method.

What it produced

The Requirements Manager authoring path, in one capture:

Core-2016-09-DataManagement/createAttachAndSubmitObjects          (create the item)
Internal-ActiveWorkspaceBom-2025-06-OccurrenceManagement/addObject5  (place it in the spec)

The item-create leg was then independently replayed through a raw SOA client (created REQ-002883 headlessly, re-verified via getProperties, then cleaned up). The structure-attach leg has not been independently replayed.

Always mark which legs you have replayed. A captured payload is evidence the call exists; only a replay is evidence you can make it.

The two conclusions this method overturned

Both were drawn from fault codes and both were flatly wrong. They are recorded here so nobody repeats them:

1. 214085 on Requirementsmanagement/createOrUpdate was read as "the RM service is not activated on this server, escalate to an admin." It actually meant the AWC never uses that operation at all. 214085 means "wrong service, keep looking", not "give up."
2. "This server only exposes the 2006-03 SOA generation" was false. The live UI uses Core-2016-09, Core-2015-10, Internal-AWS2-2024-12, Internal-ActiveWorkspaceBom-2025-06 and more. The 214086s came from wrong domain/operation combinations, not from a version-pruned server.

If the UI can do it, the call exists. A fault code is a hint about where to look next, never proof that a capability is impossible.

Do not escalate prematurely

Do not report a Teamcenter authoring task as "service not available" because generic createItems faulted or a guessed app-level operation returned 214085. Capture first. Escalate only for genuine gaps: a missing BMIDE type, a workflow transition that has no SOA route, or an account/permission decision that is not yours to make.

Related skills

tc-soa-payload-shapes, tc-soa-docs-navigation, tc-object-authoring.

Deep-linking INTO Active Workspace, and finding AWC when the obvious paths 404

Deliverables improve sharply when an item id becomes a clickable link into the live object, so this is worth the five minutes. EXERCISED on the Saber 2.0 tier 2026-09-01.

1. AWC may be at the GATEWAY ROOT, not /awc

/awc, /tc and /gateway all returned 404 on that host, and that got written down as "the AWC URL on this gateway is unknown". It was served at / the whole time. Three misses on sub-paths is not a search: try the root before concluding anything.

Identify it from the HTML rather than by guessing: AWC's index carries <meta name="msApplication-ID" content="...ActiveWorkspace"> and loads bundles named kit-loginPage and kit-tcGatewayPage.

curl -s http://<host>:<port>/ | head -c 800

2. Read the route table out of the deployment's own JS

Do not assume the standard deep-link pattern applies to the build in front of you: confirm it. The client ships its route table in a dynamic-config bundle listed in that index HTML.

curl -s http://<host>:<port>/ | grep -o 'static/js/[A-Za-z0-9~.-]*\.js'      # list bundles
curl -s http://<host>:<port>/static/js/dynamic-config.<hash>.js > awc-config.js

Search it for the location definition. On TC 2506 it reads:

com_siemens_splm_clientfx_tcui_xrt_showObject: {
  params: { ..., uid:{type:"any"}, ... },
  view: "AwShowObjectLocation", type: "location",
  url: "/com.siemens.splm.clientfx.tcui.xrt.showObject", parent: "root" }

That gives all three facts you need and each is checkable: the route path, that it is parent:"root" (so it hangs off the hash root), and that uid is a declared parameter.

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

Both item and revision uids work. The same table lists the other locations and their params, so it is the cheapest way to build any AWC link, not just showObject.

3. Say which half you verified

An HTTP probe cannot validate a deep link: AWC is a single-page app, so every hash route returns the same 200 index, and an unauthenticated visit redirects to login whatever you asked for. So the honest claim is "the host serves AWC, and this build declares the route and the uid param", not "the link works". Confirming it renders the object needs one human click, and asking for that click is cheaper than implying a verification you did not do.

⚠ A deep link embeds a HOST. Links built for one tier are dead on another, and a deck that outlives a demo environment will quietly fill with broken links. Keep the base URL in one constant so it can be repointed in a single edit.

---

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