TC Dispatcher Requests

Skill tc-dispatcher-requests. Trigger and monitor Teamcenter Dispatcher translations. The undocumented SOA operation createDispatcherRequest, the OOTB workflow handler the Dispatcher guide says does not exist, how to read a request's state when getProperties returns nothing, the two independent preference families, and direct vs indirect translators. Use for any Dispatcher, translation, or long-running out-of-band job against TC data.

Dispatcher is Teamcenter's queued, distributed job runner. It is marketed as CAD translation, but a "translator" is any executable that reads files from a directory and writes files to a directory. That makes it the supported way to run any long-running out-of-band process against Teamcenter data, with queueing, priority, retry, state tracking and an admin console you did not build.

The value over an out-of-band script: the result is created by Teamcenter, as a first-class object, under an authenticated service account. The extract also runs plmxml_export server-side, which returns occurrence connectivity the AW/JsonRest gateway cannot.

Full background: the Dispatcher KB at tc.xcelerator.us/docs/dispatcher.

★★ Creating a request over SOA

The 2506 and 2606 admin guides devote one sentence to the SOA route and never name the operation. It is:

POST <host>/tc/JsonRestServices/Core-2008-06-DispatcherManagement/createDispatcherRequest
{"inputs":[{
  "primaryObjects":   [{"uid":"<dataset uid>","type":"<dataset type>"}],
  "secondaryObjects": [{"uid":"<item revision uid>","type":"ItemRevision"}],
  "keyValueArgs": [], "dataFiles": [],
  "providerName": "SIEMENS", "serviceName": "tozipfile",
  "priority": 1, "startTime": "", "endTime": "", "interval": -1, "type": ""
}]}

Every member from providerName through type is required by the schema, including the empty strings. The response returns the new DispatcherRequest in ServiceData.created; its object_string is the task id you will see in the Dispatcher logs and staging directories.

★ Always supply secondaryObjects. For CAD-style translations the primary is the dataset and the secondary is its item revision, and the shipped TaskPrep implementations pair them by index (secondary_objs[i] with primary_objs[i]). Primaries-only is a reliable way to get a TERMINAL you cannot explain.

⚠ keyValueArgs does NOT reach the translator as command-line options. This is proven, not theoretical: a translator whose translator.xml <Options> block uses optionkey receives empty values even when keyValueArgs is populated. The real source of per-request context is the TranslationTask XML that Dispatcher stages one level above the working directory, carrying <UserDefAttribute name="itemid|revisionid|datasetname|priobjuid|secobjuid">. Read that file. It works for every submission route including the Translate menu.

Companion operations:

Operation	Use
Internal-Core-2008-06-DispatcherManagement/queryDispatcherRequests	Find by provider, service, state, priority, primary object, task id
Internal-Core-2008-06-DispatcherManagement/updateDispatcherRequests	Modify existing requests

★★ Reading a request's state

getProperties on a DispatcherRequest returns nothing for the obvious names — current_state, provider_name, service_name, task_id do not exist as properties. Only creation_date, object_string, owning_user and priority come back. Relations and error names all return {}.

The workaround needs no property name at all: filter queryDispatcherRequests by states[] and see whether your uid comes back.

{"inputs":[{"providers":[],"services":[],"states":["TERMINAL"],"priorities":[],
            "primaryObjects":[],"taskID":["<task id>"],"type":[],
            "modifiedDate":"","unLoaded":false}]}

Binary-search the state list and you have the answer in two or three calls.

Phase	States
Initial	INITIAL
In progress	PREPARING, SCHEDULED, TRANSLATING, LOADING, SUPERSEDING
Final	COMPLETE, DUPLICATE, DELETE, CANCELLED, SUPERSEDED, NO_TRANS, TERMINAL

⚠ The 2606 docs name the queued state SCHEDULING in one table and SCHEDULED in the next. Try SCHEDULED first, then SCHEDULING, before concluding anything.

★ NO_TRANS and SUPERSEDED are successes, not failures, despite reading like errors in the console.

Where a stall points:

Stuck at	Owner	Look at
INITIAL	nothing claimed it	Is the Dispatcher Client running? Does a filter exclude this provider/service?
PREPARING	Dispatcher Client	TaskPrep: wrong source dataset type or missing named reference
SCHEDULED	Scheduler	No Module advertises that provider+service, or all Modules at max
TRANSLATING	Module	Your script. Default watchdog is ~50 min
LOADING	Dispatcher Client	DatabaseOperation: destination type / named ref / relation

★★★ Triggering from a workflow

The Dispatcher guide's claim that "no workflow action handlers or triggers are currently provided by Dispatcher" is misleading, in 2506 and 2606 alike. Dispatcher does not ship one; Process and Program Management does:

TSTK-CreateTranslationRequest
   -ProviderName=SIEMENS -ServiceName=<service>
   -Priority=1 -DatasetTypeName=<dataset type>

✅ Verified live on a TC 2506 tier via getRegisteredHandlers: this handler is really registered, alongside EPM-hold, EPM-invoke-system-action, EPM-run-external-command and DOCMGT-render-document-revision. Its real argument contract, from getSupportedHandlerArguments, is mandatory -ProviderName, -ServiceName, -DatasetTypeName; optional -Priority — a split the documentation does not state.

• Placement: the Start or Complete action.
• The target must be an item revision. The handler traverses it looking for datasets of -DatasetTypeName.
• One request per matching dataset, not one request with many primaries.
• ⚠ It refuses site-custom dataset types. If your source is a BMIDE-custom type, this handler cannot reach it. ★ Mdw0MDModel (the MagicDraw/Cameo dataset) is accepted at bind time — createOrUpdateHandler stores it and reads back clean. Whether it survives the handler's runtime type check is still unproven: see the publish blocker below.
• ☠☠ -ProviderName is compared to translator.xml's provider= attribute and Service.properties' Translator.<Provider>.<Service>.Prepare= key case-sensitively, and a mismatch fails with a message that names the WRONG half. EXERCISED 2026-08-24: a Workflow Designer edit set the argument value to Siemens (title case, easy to type by habit) while the registered provider was SIEMENS (both files, correctly, all-caps). The Dispatcher Module's own log read: Cannot find task preparation class specified by service configuration for Siemens csainttest — echoing back the WRONG, supplied value in the error, not the registered one, which makes it read like the class/jar is missing (see the KB match below) rather than a four-character casing typo. Two independent services on the same tier hit the identical failure independently of each other, and both cleared immediately on fixing the case alone, with no other change. Any "cannot find task preparation class" error: diff the handler's -ProviderName against translator.xml's provider= byte for byte before looking anywhere else.
• ☠ A Windows-service Dispatcher install snapshots its classpath into the registry at INSTALL time, and Restart-Service does not re-read it. Matches a real Siemens KB for a different symptom (missing jar for supportalorchestrationservice), same root mechanism: "when we install dispatcher client service, it generates CLASSPATH ... and stores it in the registry. So even if [you] put the jar file in the lib directory, it has no effect. The only way to regenerate classpath is to regenerate the service." EXERCISED 2026-08-24 on csainttest's brand-new Service.properties entry: Restart-Service alone did not pick it up (identical NPE before and after); removing and reinstalling BOTH services fixed it. Both DispatcherClient and Dispatcher Module ship this pattern, one script each, both taking -r (remove) then -i (install, needs Start-Service afterward — install does not auto-start):

  C:\apps\PLM\DSP\DispatcherClient\bin\runDispatcherClientWinService.bat  -r / -i
  C:\apps\PLM\DSP\Module\bin\moduleWinService.bat                        -r / -i
  

  Needs the env from tc_Vanilla_Env.bat sourced first, same as preferences_manager.exe below — neither is a bare double-click target.

⚠ Runtime end-to-end is STILL NOT proven for this handler, as of 2026-08-05, but the blocker has moved twice since the paragraph below was first written — read tc-workflow-authoring for the current, much more specific state before repeating any of this investigation:

1. (Original blocker, resolved) createOrUpdateTemplate produces a task template, which cannot start a process. Fix: build the process template in Workflow Designer directly, then script the handler onto it with createOrUpdateHandler.
2. (Second blocker, resolved) A correctly-built process template is invisible in every "start a process" UI (My Teamcenter New Process, AW Submit to Workflow) while its stage is Under Construction. Fix: Set Stage to Available in Workflow Designer (see tc-workflow-authoring for the exact click sequence and the case-sensitive-sort trap in the template picker).
3. (Current blocker, open) With the template Available, starting the process is gated by who you're logged in as: infodba is explicitly refused ("installation user account... should not be used to create Workspace Objects"), and a regular named business user was observed to see a completely empty template picker (not filtered — zero entries) despite the template being Available and visible to infodba. This looks like a group/role/BMIDE-condition visibility gate on template enumeration, distinct from the Awp0IsWorkflowTemplateAuthor authoring gate. Needs a site admin to identify the right account/condition. Active Workspace's own Submit-to-Workflow dialog was also tried as a workaround and found to have a non-functional Template: field (blank, no picker, not in tab order) for both account types — not a viable alternative path today.

★ Attribution warning, learned here. Four CapitalForward requests reached COMPLETE on the tier during the test window and it was tempting to read them as success. They were not: fnd0AllWorkflows and process_stage_list on the target revision were empty, and the result datasets' timestamps matched a run that predated the test. Before claiming a Dispatcher request came from your trigger, check that a workflow process actually exists on the target.

TCRS-Create-Translation-Request is the Rapid Start sibling and is hard-wired to printer-friendly output (cgm|hpg|jt|pdf|tif). Not usable for a custom translator.

To make the workflow wait for the result, use the Do-task pattern from tc-workflow-authoring: launch handler on Start, EPM-hold on Complete (already default on a Do task), and the translator performs the task's Complete action when it finishes. DOCMGT-render-document-revision and CAE-simulation-process-launch-handler are both built this way.

If the OOTB handler does not fit, do not reach for ITK (DISPATCHER_create_request, dispatcher_itk.h, libdispatcher) first. Since createDispatcherRequest works over plain JSON REST, a small script behind EPM-invoke-system-action replaces the entire ITK build — no compiler, no link script.

★★ The two INDEPENDENT preference families

This is the highest-value debugging fact about Dispatcher configuration. A service is configured by two preference families that do not depend on each other, and checking which half is missing is the fastest first diagnosis.

Menu family — makes the service appear in Translate. Service name is UPPER-CASED:

ETS.PROVIDERS
ETS.TRANSLATORS.<PROVIDER>
ETS.DATASETTYPES.<PROVIDER>.<SERVICE>      e.g. ETS.DATASETTYPES.SIEMENS.CAPITALFORWARD
ETS.PRIORITY.<PROVIDER>.<SERVICE>
ETS.TRANSLATOR_ARGS.<PROVIDER>.<SERVICE>
ETS.REPEATING_UI.<PROVIDER>.<SERVICE>

Extract/load family — tells basic.TaskPrep what to do. Names concatenate in literal case:

<Provider><Service>_ets_ds_types                                   e.g. SIEMENSCapitalForward_ets_ds_types
<Provider><Service>_<srcType>_ets_nr_types
<Provider><Service>_<srcType>_ets_dst_ds_type
<Provider><Service>_<srcType>_ets_dst_nr_type
<Provider><Service>_<srcType>_ets_dst_relation_type
<Provider><Service>_<srcType>_ets_dst_relation_to_src
<Provider><Service>_<srcType>_<dstNrType>_ets_dst_nr_fileext

Both conventions are confirmed live across five translators. Wrong casing fails silently.

• Menu prefs but no extract/load → launchable, dies in PREPARING.
• Extract/load but no menu prefs → fully configured but unlaunchable from the Translate menu, and completely silent about it.
• A direct translator legitimately has no _ets_dst_* at all.

★ Traps in these values, all found the hard way:

• _ets_nr_types wants the named-reference TYPE, not the file extension. For Mdw0MDModel that is Mdw0MDZIP, not mdzip. Get ground truth from Core-2007-06-DataManagement/getDatasetTypeInfo (2007-06; the 2007-01 version faults 214086).
• _ets_dst_nr_fileext needs a leading dot. The loader concatenates <sourceBaseName> + this value verbatim, so xml produces MyModelxml.
• _<dstNrType>_ets_dst_nr_fileext is not in the shipped ppttopdf sample and basic.TaskPrep NPEs without it. The sample's preference set is incomplete for 2506+.
• basic.TaskPrep honours only the FIRST value of _ets_nr_types despite the array type, so it cannot handle a source with more than one possible named reference.

★★★ SOA CANNOT WRITE SITE-SCOPE PREFERENCES. setPreferences2, setPreferencesDefinition and setPreferencesAtLocations all return 200 OK and write only the calling user's scope, or nothing at all. Use:

preferences_manager -u=infodba -p=<pwd> -g=dba -mode=import -scope=SITE \
                    -action=override -context=Teamcenter -file=<xml>

Then, in order, every time:

1. run the import and capture $LASTEXITCODE — a failed run prints absolutely nothing, identical to success
2. Administration-2011-05-PreferenceManagement/refreshPreferences — TC caches preferences per session, and a stale read returns "cannot be found" (1700) for a preference that was just created
3. getPreferences as a different user than the importer
4. only then restart the DispatcherClient

Never chain the import and a service restart with ;.

★★★ EXERCISED 2026-08-24: the full working recipe, and one step that still did NOT clear it

preferences_manager.exe (C:\apps\PLM\tc_root\bin\) needs its environment set up first, or it dies at process launch with STATUS_DLL_NOT_FOUND (exit code -1073741515) before it even parses arguments. **tem_init.bat is NOT the right script** — it only sets three env vars (TC_JRE_HOME, VAULT_TLS_ROOT, FIPS flags), no PATH. The correct one is the desktop "Command Prompt" shortcut's target, from tc-vm-operations: call C:\apps\PLM\tc_root\tc_menu\tc_Vanilla_Env.bat. Call it, then cd /d ...\tc_root\bin, then run the exe — all in one .bat file (a cmd /c "call X && cmd Y" one-liner is fragile; write the file instead).

★ -p=infodba is the literal password on this dev VM (not a secret needing DPAPI) — several prior sessions used it plainly in transcripts.

★ -name=<preference> on export is silently ignored — it dumps the entire site catalog regardless (tens of thousands of lines) and streaming that back over Get-Content from a remote session will time out a 2-minute tool call. Read the file remotely with .IndexOf/.Substring on the raw content and extract just the one <preference>...</preference> block you need.

★ Get the exact XML schema by exporting a WORKING sibling preference first, not by hand-authoring one from the docs. <preference name="..." type="String" array="true" protectionScope="Site" envEnabled="false"><preference_description> ...</preference_description><context name="Teamcenter"><value>...</value> </context></preference>, wrapped in one <category> inside <preferences version="10.0">. Confirmed correct casing pattern against a second working sibling with the identical lowercase-service-name shape (csaintscan, not just the mixed-case CapitalForward example above): SIEMENScsaintscan_ets_ds_types. So SIEMENScsainttest_ets_ds_types (all-caps provider, literal-case service, zero separator) is the right name for a service named csainttest — this is not a guess, it was diff-checked against a live, resolving sibling.

★ Write the import XML with [System.IO.File]::WriteAllText + a no-BOM UTF8Encoding, never Set-Content -Encoding UTF8 — PowerShell 5.1 on this guest adds a BOM, and this importer is one of the ones that rejects it silently (see the workspace-wide BOM trap in the root CLAUDE.md).

The import genuinely worked — confirmed three independent ways: exit 0 (not printed on failure, but present here), "The import operation has succeeded" in the tool's own stdout, and — the only ground truth that actually matters — a fresh -mode=export immediately after showed the preference in the site catalog with the right name, protectionScope="Site", and the right value. That third check is the one to trust; the first two are exactly the "reports success either way" shape this codebase's grounding rules warn about everywhere else, so do not skip the export re-check.

☠☠☠ CORRECTED 2026-08-25, same day as first written — the framing below was wrong, get the actual constraint right. Siemens product development confirmed the limitation is on which dataset/object TYPES can be a Dispatcher target via TSTK-CreateTranslationRequest — roughly six OOTB types (MISC, Text, and others; get the authoritative list before relying on this), never a custom/BMIDE-defined dataset type like Mdw0MDModel. The custom SERVICE itself (a hand-registered translator.xml/ Service.properties entry like csainttest) is fine and fully supported. This directly matches — and is the same fact as — the earlier-documented "It refuses site-custom dataset types" bullet under "Triggering from a workflow" above; it is not a new rule, just the corrected reason for why SIEMENScsainttest_ets_ds_types kept failing to resolve.

⚠ What this does NOT explain, left genuinely open: csainttest's -DatasetTypeName was MISC — one of the allowed OOTB types per this same rule — and it still never resolved, while a sibling service on the identical code path (csaintscan, also targeting MISC) resolved fine in the same log stream. So the object-type constraint is real and now confirmed, but it does not, by itself, account for why this one custom service's preference specifically stayed unresolved. Do not treat this correction as closing the mystery — it corrects the wrong half of the explanation (services vs. object types), not the actual root cause of the stuck preference. If a future session needs to actually get a custom service's Dispatcher preference resolving, the report-file lead further down (never-yet-read preferences_manager import report) is still the next concrete thing to try — it was wrongly marked moot in an earlier edit of this same section; that retraction is itself retracted.

☠☠ What follows below is the now-closed investigation trail — kept for the reasoning, not as a recipe to repeat: despite the write being provably correct at the database level, the new preference resolved as null everywhere for over 20 minutes — Core-2007-01-Session/getPreferences returned empty for both the importing user and a different user, immediately after Administration-2011-05-PreferenceManagement/refreshPreferences returned out: true; and the Dispatcher's own runtime (SoaHelper.getPreference) kept NPEing in BasicConfigHelper.getTranslationConfig, identically, through: a DispatcherClient restart alone, then DispatcherClient + Dispatcher Module + Dispatcher Scheduler all three restarted together, across three separate fresh workflow-fired translation requests. A sibling preference on an identical code path (SIEMENScsaintscan_ets_ds_types) resolved successfully in the very same log stream minutes apart, so the general resolution mechanism is not broken — something about a newly created preference name specifically does not propagate the way an edit to an existing one does. PreferenceManagement.removeStalePreferenceInstancesAtLocations (2012-09, deprecated, "no replacement... the preference manager utility has a cleanup mode that does the same thing") is the one live lead not yet tried — preferences_manager.exe -mode=cleanup or similar; -help/-? hangs the process rather than printing usage, and the flag list is not in the binary's own strings (likely a thin JVM-launcher stub), so the exact syntax needs either the admin guide PDF or a working example from a live session, not guessing. If a full tcserver pool bounce (not just Dispatcher) turns out to be what actually clears it, that is also worth confirming and recording here — it was not tried this session because reverting the shared VM's tier was out of scope for this task.

★★★ STRONGER LEAD, found straight after in the same admin-guide page (utilities_reference/preferences_manager), not yet tested end to end: -mode=cleanup turned out to be about orphaned instances with no definition ("removes all instances of all preferences that have no assigned definition") — the wrong direction for a preference that's missing, not extra. But the -mode=import doc's own report-file section names our exact symptom: "the import file contains preferences that are not yet declared at the site level. These preferences were not imported for the given users/roles/groups (and a warning was printed in the output report)."

This session's import run printed only "The import operation has succeeded" to stdout and named its report file (C:\Temp\preferences_manager_<timestamp>.log) — that report file was never actually read. If a preference needs to be declared (registered as a definition) before a plain -mode=import will actually persist an INSTANCE of it for runtime resolution, that would explain everything observed: a fresh -mode=export afterward still showed the preference (plausibly because export can reflect what an import attempted, or a partial write, without the definition being complete enough for SoaHelper.getPreference() — a different, definition-level lookup — to resolve it), while both plain-SOA getPreferences and the Dispatcher's own runtime kept returning null.

Next session: read that report file first, before touching anything else, and if it does confirm the not-yet-declared warning, look for whether -mode=import has a companion declare/define step (the doc's -mode=delete section, read partially this session, mentions "deletes preference DEFINITIONS... single or multiple definitions and THEIR instances" — implying a definition genuinely is a distinct, separately-manageable object from an instance, which the site-scope XML shape used here may not have fully created even though it looked complete by CapitalForward's own example).

★★ The transfer mode decides what CROSSES, and it cannot decide what is REPRESENTABLE

A translator whose extract is plmxml_export is shaped as much by the -transfermode as by the model. The mode names a closure rule, whose clauses say what to traverse:

<primary selector> : <secondary selector> : PROPERTY.<name> : <action> : <condition>
CLASS.ItemRevision : CLASS.Dataset       : PROPERTY.IMAN_specification : PROCESS+TRAVERSE:
CLASS.ItemRevision : CLASS.ItemRevision  : RELATIONP2S.*               : TRAVERSE_AND_PROCESS:

RELATIONP2S.* is the one worth knowing: traverse every GRM relation primary-to-secondary. Measured on one model (007146) exported ten ways, 2026-08-20:

mode	GRM relations in the output
ConfiguredDataExportDefault	0
MechatronicsFoundationDataExport, ConfiguredRequirementDataExport, forHRNExchange	0
transgde	20 (11 Seg0Allocate, 6 Seg0Satisfy, 2 Seg0Derive, 1 IAV0Verify)

Structural content was identical between them, so the mode was pure gain. Relations arrive as <GeneralRelation subType="Seg0Allocate" relatedRefs="#a #b">, and the refs are DEFINITION ids (<ProductRevision>), not occurrence ids - join on them accordingly.

⚠ But a closure rule decides what to WALK TO, never what the schema can HOLD. The same clause family cannot carry Seg0ItemFlowExchanges no matter how it is written, because PLMXML has no element for that class. Exported directly by uid against a positive control through the identical probe: the control (Uml0MLModelRevision) produced 2,861 bytes of Product / ProductRevision / AssociatedDataSet; the subject produced 410 bytes of Header and PLMXML and nothing else, while plmxml_export printed Number of target objects identified for traversal are [1]. ⇒ Found it, then emitted nothing for it. When an object will not come through, separate traversal from representation before spending a day on closure rules.

★ Acceptance check for ANY candidate mode. Exit code and file existence are both true and both uninformative. Count <GDE, <ConnectionInstance, type="connection" and <GeneralRelation in the output. On vm2606 AR_RFLP_TM, SEM_PLMXMLDataExport, ESMDefiningTraceLink and HardwareSoftwareReportExport all exited 0 and wrote ~1.5 KB containing none of them.

⚠ Authoring your own mode: tcxml_import is a silent no-op if you strip the identity. Exporting a stock mode with tcxml_export -uid=... -transfermode=AdminDataExportDefaultTM gives a correct template, but removing GSIdentity label from the objects you are renaming (to avoid updating the stock ones) makes them unresolvable. The import prints "completed successfully", exits 0, and its summary reads New 0 | Update 0 | Skip 0 | Fail 0 | Total 0. See diagnose-silent-failure.

Direct vs indirect translators

	Indirect	Direct
Connected to TC	no	yes
Input via	TaskPrep extract	downloads itself
Output via	DatabaseOperation load	uploads itself
Credentials	Service.Tc.User	its own config
translator.xml	normal	OutputNeeded="false", no .Load binding

Choose direct when the translator produces more than one result file. basic.DatabaseOperation loads exactly one file, with one type and one relation, so a Dispatcher-side load silently discards everything else.

★★★ Verified live end-to-end 2026-08-06: direct SOA trigger, no workflow needed

The workflow-launch identity gate above (item 3, "who can start the process") was still open when this ran. The direct createDispatcherRequest call is a full substitute for testing/using the translator itself — it is not a workaround, it's the documented API working as designed. Real run against CapitalForward: request reached COMPLETE in under a minute, module log showed the full dispatcher-forward-module ok payload, and the output dataset's content genuinely changed (verified — see attribution note below). Full narrative in the tc-dispatcher-kb memory, "THE GRAND CHALLENGE" section.

★★ Attribution refinement: when a translator's target dataset already existed from a prior run, check last_mod_date, not creation_date. Dispatcher reuses/updates the same dataset object across repeated runs rather than creating a fresh one each time. A dataset with an old creation_date (days or weeks earlier) can still be genuinely today's output — the tell is last_mod_date on both the dataset and its ImanFile matching the run's timestamp to the second, plus file_size matching the module log's byte count. Don't let an old creation_date alone read as "this must be stale."

★★ The failure that costs the most time

ERROR - Translation request missing primary object.
  at TranslationRequest.refreshPriAndSecObjs(...)

This does not mean the request lacks a primary object. It means refreshPriAndSecObjs re-resolved the primary inside the Dispatcher Client's own session, which runs as Service.Tc.User (default dcproxy, and Service.Tc.Group must be dba). That account could not see the object, so it resolved to null. It is an ACL failure wearing a data-shape error message.

Consequences worth internalising:

• A Teamcenter session has exactly one current project, and the Dispatcher Client holds one long-lived session (Service.Tc.ReLoginInterval=1440). So one DC Proxy User = one program is a structural constraint, not a policy choice. Multi-program means multiple clients.
• Adding the proxy user to a project requires restarting the DispatcherClient — it will not re-authenticate on its own for 24 hours.
• Do not "fix" this by setting Service.Tc.User to a normal user: that user must also be in dba, and most are not, so the client would fail to log in at all.

Verification discipline

Per tc-verify-and-cleanup, and with a Dispatcher-specific edge:

• A query returning 0 can mean ACCESS DENIED, not absence. Saved-query routes return a clean 0 with no error; Internal-Query-2008-06-Finder/findObjectsByClassAndAttributes exposes it as partialErrors code 525084. Re-run a suspicious zero as a second user before concluding the data is not there.
• Calibrating that a query works does not calibrate that your user can see the target.
• getTypeDescriptions2 throws InternalServerException on some tiers for every type including OOTB ones, so its error says nothing about whether a type exists.
• The authoritative runtime evidence is on the Dispatcher host: Logs\Dispatcher\task\<taskid>\<taskid>_dc.log (client) and _m.log (module). The Command string: line in _m.log is the fully-resolved command — copy it and rerun by hand.

In Active Workspace, Launcher → Dispatcher Console lists every request with state, provider, service and owner, and supports Resubmit / Delete / Export to Excel. Resubmit reuses the original configuration, so it will not pick up a preference you just fixed unless the client reloaded too.

Related: tc-workflow-authoring, tc-soa-payload-shapes, tc-datasets-files, tc-verify-and-cleanup.

---

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