Dispatcher: Architecture and Components

Topology

  ┌─────────────────────────────────────┐
  │ Teamcenter host                     │
  │  Teamcenter  ⇄  DispatcherClient    │
  │                      ⇅ RMI          │
  │                  Scheduler          │──── RMI ───┐
  └─────────────────────────────────────┘            │
                                                     ▼
                            ┌────────────────────────────────────┐
                            │ Worker host(s)                     │
                            │  Module ──▶ Translators/<service>/ │
                            └────────────────────────────────────┘

Scheduler and Module can be co-located with Teamcenter (all-local) or spread across many hosts of different platforms. The 2506 guide's own diagram shows one Scheduler fanning out to Modules on Windows, Itanium, AIX and Linux simultaneously, each hosting a different translator set. That heterogeneity is the point: the Module is where the translator's native tooling has to be installed.

Directory layout

Every component follows the same shape:

Dispatcher/
  Scheduler/        bin/  conf/  lib/
  Module/           bin/  conf/  lib/  Translators/  samples/
  DispatcherClient/ bin/  conf/  lib/  install/  sample/  xml/  docs/
  AdminClient/      bin/  conf/  lib/  samples/  testxml/  ui/
  Documentation/    javadocs/

Ports and RMI wiring

These four values must agree across three files or nothing connects:

Setting	File	Default
Port	Scheduler/conf/transscheduler.properties	2001
Scheduler.URL	Module/conf/transmodule.properties	rmi://localhost:2001
DispatcherServer.URL	DispatcherClient/conf/DispatcherClient.config	rmi://localhost:2001
Port (Module's own RMI export)	Module/conf/transmodule.properties	1999
Port (DispatcherClient RMI registry)	DispatcherClient/conf/DispatcherClient.config	2099
BindingName / Scheduler.BindingName	all three	DispatcherScheduler

BindingName must be identical in transscheduler.properties, transmodule.properties and DispatcherClient.config. If you run more than one Scheduler it must be unique per Scheduler, which then means updating it in every Module and Client that points at it.

Config file map

This is the whole surface. There is nothing else.

Scheduler

File	What it controls
conf/transscheduler.properties	Port, binding name, mail host/admin email, SlackTime (priority-inversion window, default 60 min), NumTasksToSubmitToModule (default 3), NumOfEventLogs (default 3 days)
conf/database.xml	Where translation data is stored
conf/TaskConfiguration.xml	Site-wide cap on concurrent tasks per provider+service. Ships empty with one commented example

TaskConfiguration.xml in full, as shipped:

<Tasks>
     <!-- Task Provider="SIEMENS" Service="tozipfile" MaxLimit="3"/-->
</Tasks>

That is the global throttle. MaxLimit here caps a service across all Modules, as opposed to MaximumTasks which caps one Module across all services.

Module

File	What it controls
module.config	Which Module configurations exist and where their conf/Translators dirs are
conf/transmodule.properties	Scheduler URL, MaximumTasks (default 3), staging dir, progress watchdog
conf/translator.xml	The translator registry. 78 OOTB service definitions
Translators/<service>/	The launch scripts

Two watchdog settings worth knowing before you debug a "hung" translation:

MaximumProgress=100
MonitorInterval=0.5

The Module samples progress every MonitorInterval minutes and kills the process after MaximumProgress non-progressing samples. Default is therefore a 50-minute ceiling on any single translation. A large job that "fails for no reason" at around 50 minutes is this, not your script.

There is also an opt-in CPU-based admission filter, commented out by default:

#SubmitFilters=com.teamcenter.tstk.server.translation.module.filters.CpuUsageSubmitFilter
#SubmitFilters.CpuUsageThreshold=0.7

Dispatcher Client

File	What it controls
conf/DispatcherClient.config	Scheduler URL, staging dir, poll interval, BadChars, preview mapping
conf/Service.properties	Per-translator Prepare / Load / Duplicate / Log class bindings. ~600 lines
conf/PostProcessor.xml	File-extension to Teamcenter-object-type mapping for direct translators
install/*_env.xml	Preference bundles to import with preferences_manager
sample/integration/	The worked custom-translator examples
xml/Task.xsd	The TranslationTask wire-format schema

DispatcherServer.PingInterval=0.25 is the poll cadence in minutes, so the client checks for new requests every 15 seconds by default.

BadChars deserves a mention because it silently rewrites your filenames. The default list replaces @ % & * # ! - . ( ) \ / , space newline tab ~ $ ^ + = " ' : ; < > ? | [ ] { }with underscores, because many translators choke on them. You can override per service with..BadChars`.

AdminClient

File	What it controls
conf/transclient.properties	Where to find the Scheduler
testxml/BatchInput.xml	Batch submission format
bin/runUI.bat, runBatch.bat, runSampleClient.bat	Entry points
samples/*.java	Programmatic submission examples

The CHANGE_ME problem

Nearly every shipped launch script and several config files contain literal CHANGE_ME placeholders. plmxmltojt.bat is representative:

set TC_ROOT=CHANGE_ME
set PERL_DIR=CHANGE_ME
set TCVIS_ROOT=CHANGE_ME

DispatcherClient.config has DB_Host, DB_Port and User set to CHANGE_ME as well, though the comments note these are unused for Teamcenter Engineering (they are Teamcenter Enterprise MUX settings). See the deployment checklist for the full inventory.

What is a Java RMI application, practically

Both Scheduler and Module are plain Java processes started by a .bat/.sh, or installable as Windows services via schedulerWinService.bat / moduleWinService.bat. They use .policy files (scheduler.policy, module.policy, client.policy) for the Java security manager. Logging is log4j2 throughout, configured per component in conf/log4j2.xml, writing under LogVolumeLocation (default ../logs).