Dispatcher: Grand Challenge — Live End-to-End Run

Everything on the other pages in this section is either shipped documentation or a single piece of live evidence read in isolation. This page is the first one that chains every piece together against a real system, start to finish, with independent proof at each hop: a Cameo model check-in, an automatic Dispatcher translation, two Teamcenter subscriptions catching it, and the result landing in Capital Systems Architect.

Target: item 042780 (InvertedFlightFuelSystem), a Uml0MLModel with a Uml0MLModelRevision, on the same Pre-Int tier documented throughout this section.

The chain, and what proved each link

1. Cameo check-in

A model checked out and re-checked-in through the HCL Cameo–Teamcenter connector. Confirmed independently of the connector's own "success" dialog: read the revision back over SOA and its checked_out flag cleared and last_mod_date moved to the check-in time.

Trap worth recording here, because it produced several minutes of "nothing is happening": the connector's own Teamcenter login dialog was popping up every time an operation was attempted, and being silently dismissed by an Escape keypress before it could be seen. Its Is user logged in: true log line is not evidence of anything — it prints after failed and cancelled logins too. The real success markers are Login Successfull (sic) immediately followed by a clean loginToTeamcenter(): Finished, with no ERROR line between them.

2. Dispatcher runs CapitalForward, unattended

Triggered directly over createDispatcherRequest — see the note on the workflow-trigger page about why this run used the direct call rather than a workflow. Primary object was the item's Mdw0MDModel dataset, secondary the item revision.

The request reached COMPLETE in under a minute. The module log (_m.log) carried the full dispatcher-forward-module ok payload: a 474,250-byte capital.xml, 8 components, 2 pathways, and a conservation check reading "PASS with 1 reported reduction(s) - legitimate skips only, no component lost." — then Module completed uploading result files → Completed successfully!.

A refinement to the attribution discipline this KB already teaches (see Live Configuration Evidence): when a translator's output dataset already existed from an earlier run, check last_mod_date, not creation_date. Dispatcher reuses the same dataset object across repeated runs rather than minting a new one each time, so an old creation_date proves nothing about whether this run produced it. The tell is last_mod_date on both the dataset and its underlying file matching the run's timestamp to the second, with file_size matching the module log's byte count.

3. Subscriptions catch it — on both levels

Two Teamcenter subscriptions were set up beforehand: Check-In and Attach, each subscribed at both the item level and the revision level (four subscriptions from two event types, doubled). The result answered a real open question:

Attach fired independently on the item and on the revision — both, not one or the other. A consumer subscribed at only one level would still have caught this particular event, but that isn't something to assume in general. Cover both levels when the notification matters.

The sequence, read straight off the subscription app's activity log: Check-In at the model's check-in time, then Attach (twice — item and revision) at the module's output-upload time, roughly a minute later, fired by the Dispatcher's own service account rather than the modeling engineer — itself independent proof the translation ran unattended, not manually.

4. Capital import

The translated capital.xml was pulled off the Teamcenter dataset and imported into a fresh Capital Systems Architect project via Files → Import Project & Generate Diagrams. Real, populated structure landed: Analysis, Harness, Logic, Topology, and Function categories under the project's Build Lists — not an empty shell.

One UI trap worth flagging for anyone repeating this: the project tree does not auto-refresh immediately after a successful background import. An apparently-empty tree and a blank import log for a couple of minutes look exactly like a failed import; they weren't. Force a refresh (collapse and re-expand the top-level node, or reopen the project) before concluding anything failed.

What this run does and does not settle

Settled:

• The zero-Java CapitalForward translator documented elsewhere in this section is not just configured, it runs correctly against real model data and produces a correct, conservation-checked Capital import.
• The two-family preference model, the direct-translator pattern, and the createDispatcherRequest API all behave exactly as documented under real load, not just in isolated reads.
• Attribution discipline (checking who and when a result actually came from) holds up as the right practice — the run needed it in a new form (last_mod_date over creation_date) that the earlier pages didn't cover.

Still open, unchanged by this run:

• Who can launch the workflow is a separate, unresolved question. This run deliberately used the direct SOA trigger instead of the workflow path, so it demonstrates the translator and the notification chain, not a resolution to that gate.
• The exact SOA shape for downloading a file back out of Teamcenter (getFileReadTickets) wasn't cracked under time pressure here; the file was moved off the host through an RDP clipboard bridge instead. That's a legitimate one-off workaround, not a documented recipe — worth solving properly if this becomes routine.

Related pages

Submitting requests · Live Configuration Evidence · Anatomy of a working translator · Triggering translations from workflow