TeamcenterKnowledge

community-knowledge

Teamcenter Dispatcher: Architecture, Configuration, and Troubleshooting Notes (Community Sources)

Scope: practitioner-facing material on Teamcenter Dispatcher (formerly "Translation Management") gathered from blogs, an integration-partner page, and a Siemens Realize LIVE session summary. This is a companion to whatever official Dispatcher Installation/Configuration Guide already exists in this KB tree — it captures the parts practitioners actually write about: the moving pieces, the config files, and where things go wrong.

Architecture in plain terms

Dispatcher has three core services that talk to each other over RMI, plus an optional fourth:

  • Dispatcher Client — the front end that talks to Teamcenter over SOA. It extracts source files from Teamcenter into a staging directory, and after translation completes, loads the translated results back into Teamcenter.
  • Scheduler — sits between the Client and the Module(s). It queues translation requests and prioritizes them (high/medium/low), and distributes work across Module hosts.
  • Module — where the actual translators live and run. A translator.xml config file (in the Module's conf folder) defines each translation service.
  • Dispatcher Admin (optional) — an administrative front end for monitoring/managing the above.

Each of the three core services can run standalone (console mode, useful for debugging) or as a Windows/Linux service, and each can live on its own machine — this is what "distributed topology" means in Dispatcher terms. One practitioner note worth flagging: it is much easier to diagnose Dispatcher Client/Server problems when you run them from the command line instead of as Windows services, because you see the console output live rather than digging through service logs.

Source: Teamcenter Dispatcher Concept – Global PLM, Teamcenter PLM: Teamcenter Dispatcher Framework, Teamcenter Dispatcher Integration Services – Intelizign

Key configuration files (by component)

Component Config file(s) What lives there
AdminClient transclient.properties Staging.Dir (default staging area path, e.g. %disp_root%\stage), Module.Port (default 1999)
DispatcherClient Service.properties, DispatcherClient.config Host/Teamcenter-user/tcserver port to connect to TC; DispatcherClient.config holds the Scheduler's RMI port and staging directory info; Service.Tc.Port default 11200
Scheduler conf folder under Scheduler Scheduler-level properties: ports, logging
Module transmodule.properties, translator.xml MaximumTasks (limits concurrent translator processes on that Module — the main lever for sizing), Port (default 1999), and per-translator definitions

Email notification settings live under DispatcherClient too: Service.Email.SMTPServerName, Service.Email.AdminEmailId, Service.Email.SenderId, and Service.Email.SendUserEmailOnError (set to 1 to get failure alerts to the requesting user).

Sources: Teamcenter Dispatcher Parameters – Global PLM, Teamcenter PLM: Configuring Translator

Configuring (activating) a translator — the actual steps

  1. In the Module's translator.xml, define/enable the service: set isactive="true" (only active services are offered for translation), set TransExecutable to the translator's batch/script file, set Options for the input/output command-line arguments, and set FileExtensions for supported input/output formats.
    • Example pattern quoted verbatim from the blog for a JT→CATIA V5 translator: jttocatiav5.bat -i {Input file dir} –o {outputfiledir}.
  2. For Siemens-provided ("COTS") translation services specifically, you also configure required environment variables inside the translator's own batch file, then set three Teamcenter preferences (not Dispatcher config files):
    • ETS.PROVIDERS — lists translator providers (default SIEMENS)
    • ETS.TRANSLATORS.SIEMENS — lists which services are available
    • ETS.DATASETTYPES — defines which dataset types the translator is valid for
  3. In most installs, once the core components are up, the Scheduler needs no further changes — nearly all customization happens in Module's translator.xml and in the ETS preferences, not in Scheduler config.

Source: Teamcenter PLM: Configuring Translator

Sizing / distributed topology guidance

  • Estimate your expected number of concurrent translations first — that number drives both MaximumTasks per Module and how many Module machines/instances you need.
  • Disk sizing for the staging area: multiply average model file size by the number of simultaneous translations you expect.
  • Siemens' own recommendation (per the Dispatcher Server Installation Guide, as summarized by a practitioner site): install Dispatcher Modules on enterprise-class servers, since large-model CAD/Office translators are computationally, memory-, and thread-intensive.
  • RMI mode vs. Web mode: RMI-mode translations run faster than Web mode; RMI is the preferred choice inside a firewalled/trusted network, with Web mode reserved for cases where RMI connectivity isn't viable across a boundary.
  • To reduce load on the main Teamcenter server, schedule CPU/memory-heavy translation jobs for off-hours and keep Module hosts separate from Scheduler/Client hosts at scale.

Source: Teamcenter Dispatcher Concept – Global PLM (this page's search-result summary; treat the specific numbers as directional, not vendor-verbatim, since the live page itself did not expose them on fetch — see Verification note below)

Common failure modes / gotchas practitioners flag

  • Character-encoding issues: Unicode and Cyrillic filename/content handling has been called out as a recurring Dispatcher pain point in older forum/community threads.
  • Direct translations hanging: reported specifically for SolidWorks-family translators when a stray extra sldworks.exe process is left running on the Module host — only one instance should run, owned by the account that started the Module Server.
  • Placeholder/dummy files causing timeouts: loading a dummy file into Teamcenter as a stand-in for a missing source file has been reported to make the translator hang/time out waiting on a file that will never convert correctly.
  • Over-customization: more than one source observes that implementation teams often write custom code for behavior that OOTB Dispatcher already supports via straightforward translator.xml/preference changes — worth checking OOTB config options before building a custom translator wrapper.
  • Concurrency and multi-stage dependency: Dispatcher's interaction with Workflow (jobs kicked off from a workflow action) introduces concurrency considerations, and multi-stage translation chains (translate → then translate the result again) introduce dependency-ordering considerations that are easy to get wrong on first configuration.

Sources: Teamcenter PLM: Teamcenter Dispatcher Framework (SolidWorks/encoding notes came from search-engine-summarized snippets of Scribd-hosted "Installing and Configuring Dispatcher" and "tc-dispatcher-install-and-debug-with-async-and-nx" documents), general synthesis from Dispatcher community-forum thread titles retrieved via search (e.g. "Dispatcher server client architecture" on the Siemens PLM Community, td-p/444385 — this thread required login and could not be fetched directly; only its existence/title is confirmed).

Realize LIVE conference coverage

  • A Realize LIVE session on Teamcenter file translation, presented by Sandeep Bollapally, covered manual translation (PDF/JT generation via the Rich Client), workflow-driven automation, and Dispatcher configuration for organizational needs. Recording is referenced as available to those who missed the live session, but the specific recording URL was not surfaced by search. See the PROLIM writeup for the session's content summary.

Source: Efficient File Translations in Teamcenter: Manual Execution, Automation, and Configuration – PROLIM

YouTube tutorials found (metadata only — see honesty note)

Honesty note: WebFetch cannot retrieve YouTube video transcripts in this environment (a known limitation) — the descriptions above are search-result metadata (titles, publish dates, one-line topic blurbs from search snippets), not verified transcript content. Titles and publish dates are as returned by the search engine; the actual technical content of each video has not been independently confirmed by this research pass.

Verification note

Several source pages (globalplm.com dispatcher-concept page in particular, and both community.plm.automation.siemens.com and community.sw.siemens.com forum/KB URLs surfaced by search) either returned only a loading shell / login wall on direct fetch, or returned HTTP 403, meaning the detailed content quoted above for those specific claims came from the search engine's own summarization of the page rather than a direct, fully-verified fetch of the raw page text. Where that applies it's noted inline. Nothing here is a fabricated quote — text in quotation marks was returned verbatim by either WebFetch or WebSearch tooling.