Dispatcher: Overview

Dispatcher is Teamcenter's queued, distributed job-execution system. Teamcenter creates a DispatcherRequest object, and Dispatcher extracts the referenced files out of the volume, hands them to an external program on some other machine, and loads whatever that program produced back into Teamcenter as real datasets with real relations.

It is marketed as a CAD translation system, and most OOTB services are indeed nxtopv, catiav5tojt, proetojt. But nothing in the architecture is specific to CAD. A Dispatcher "translator" is any executable that takes files in a directory and writes files to a directory. That makes it the supported, governed 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 have to build.

Why it matters

Per the 2506 admin guide, Dispatcher lets you:

• Asynchronously distribute jobs to machines with the capacity to run them.
• Reduce web-tier load by moving resource-intensive work off the server.
• Schedule high-CPU or high-memory jobs for off-hours.
• Generate lightweight visualization data attached alongside the raw data.

The part that matters for automation work: the result lands in Teamcenter as a first-class object, created by Teamcenter itself, not by an out-of-band script holding a session. That is the difference between a demo and something an enterprise will run.

The five components

Component	Runs where	Job
Dispatcher Client	Beside Teamcenter	Polls the DispatcherRequest table, extracts source files from the volume, loads results back
Scheduler	One per site (typically)	The queue. Distributes tasks across Modules over RMI, tracks which Module has which translator
Module	One per worker machine	Executes translators. Plugs in any executable via config
Translators	With the Module	The actual programs. Siemens-supplied, third-party, or yours
Dispatcher request admin console	Rich client / AW	View, resubmit, delete requests

Scheduler and Module are both plain Java RMI applications. There is no application server involved, no ORB, no message bus.

The one-paragraph mental model

Teamcenter writes a request row. The Dispatcher Client picks it up, stages the files on disk, writes a TranslationTask XML file describing the job, and hands that to the Scheduler. The Scheduler picks a Module that advertises the requested service and gives it the task. The Module runs your script with the staged directory as input. Your script writes output files. The Module reports completion. The Dispatcher Client maps those output files back to Teamcenter objects and commits them. The request goes COMPLETE.

Every one of those steps is configurable, and three of them are extension points.

Where to go next

• Architecture and components for the topology, ports and config-file map.
• Request lifecycle and states for the state machine you will be reading in the admin console.
• Levels of custom translator for an honest difficulty assessment before you commit to anything.
• Zero-Java custom translator is the recipe most people need and almost nobody finds.
• Triggering translations from workflow for the OOTB handler the Dispatcher guide says does not exist, and how to make a workflow wait for the result.
• Working in Active Workspace for the Dispatcher Console and for authoring the trigger in AW Workflow Designer.
• Anatomy of a working translator for a real one, read off a live host and run end to end.
• Support Center field notes for the places where observed behavior diverges from the shipped docs.

Provenance

Three sources, in descending order of trust:

1. The Dispatcher SDK as shipped (Dispatcher.zip, DispatcherClient_wnt.zip, DispatcherTranslators.zip in the ITK toolkit). Config contracts read out of these files are reliable: they are the files the software loads. See Local kit inventory.
2. The 135-page Dispatcher — Deployment and Administration guide, v2506. Authoritative on intent; its runtime claims are claims.
3. The Siemens Support Center Knowledge Base. Where it contradicts the other two, it wins, because it describes observed behavior. Every such correction is indexed in Support Center field notes.
4. Configuration read back from a live tier. The strongest evidence available: Live configuration evidence records a Teamcenter 2506 instance with Dispatcher deployed, 70 registered services, and a complete custom zero-Java translator in place.

A custom translator has now been run end to end from this KB, producing real Teamcenter objects on a live tier — see Anatomy of a working translator. Configuration contracts are confirmed live. Where a page still rests only on the shipped documentation it says so.

Already corrected: the _ets_nr_types preference does not implement the AND semantics its own description promises; the presence of the Translate menu is not evidence that Dispatcher is deployed; and — the big one — the Dispatcher guide's claim that "no workflow action handlers or triggers are currently provided" is contradicted by an OOTB handler documented in the Workflow Handlers guide of the same release. See Triggering translations from workflow.

Already confirmed live: the preference-casing split, the independence of the menu and extract/load preference families, and the zero-Java route as a real production pattern.