Dispatcher: Live Configuration Evidence

Read over the JSON REST SOA surface against a real Teamcenter 2506 tier with Dispatcher deployed (Siemens Pre-Int, site "Saber 2.0"), 2026-08-03. This is the first page in this section grounded in a running system rather than shipped files.

Everything here is a preference read back from the live instance. Nothing was written.

★ The casing rule is confirmed

The zero-Java recipe warns that the two preference families use different casing conventions. Verified live across five separate translators:

Menu family (service UPPER-CASED)	Extract/load family (literal case)
ETS.DATASETTYPES.SIEMENS.TOZIPFILE	SIEMENStozipfile_ets_ds_types
ETS.DATASETTYPES.SIEMENS.CATIAV5TOJT	SIEMENScatiacoexist_ets_ds_types
ETS.DATASETTYPES.SIEMENS.NXDWGTOTIF	SIEMENSnxdwgtotif_ets_ds_types
ETS.DATASETTYPES.SIEMENS.CMMCADTONX_DIRECT	SIEMENSCapitalForward_ets_ds_types

The last row is the clincher: a CamelCase service name survives verbatim in the extract/load preference. Get this wrong and the preference simply does not exist, which reads as a silent misconfiguration rather than an error.

★★ The two families are genuinely independent

This deployment proves it, because one translator has each half and not the other.

CapitalForward has the extract/load half and no menu half. Every ETS.DATASETTYPES / ETS.PRIORITY / ETS.TRANSLATOR_ARGS / ETS.REPEATING_UI lookup for it returns cannot be found (error 1700), in both upper and CamelCase spellings. It is registered in ETS.TRANSLATORS.SIEMENS, so it is a known service, but it cannot be invoked from the Translate menu. Either it is driven programmatically, or the configuration was never finished.

cmmcadtonx_direct has the menu half and no extract/load half. SIEMENScmmcadtonx_direct_ets_ds_types does not exist, while ETS.DATASETTYPES.SIEMENS.CMMCADTONX_DIRECT lists 17 CAD dataset types.

That second case is not a mistake, it is the direct translator pattern. As the shipped Service.properties states, direct translators store results in Teamcenter themselves and specify no Load class, configuring file mapping in PostProcessor.xml instead. So they need the menu preferences and never touch the extract/load ones. Live confirmation of a distinction the admin guide makes only in passing.

Practical rule: when a translator misbehaves, check which family you are missing before checking anything else. Missing menu family means it will never appear to a user. Missing extract/load family means either it is direct, or the load will fail.

A complete live custom translator

CapitalForward is the interesting one: a CamelCase name in a list where every Siemens service is lowercase, and it is absent from the 78 services in the shipped translator.xml. Its full configuration:

ETS.TRANSLATORS.SIEMENS                                     includes CapitalForward
SIEMENSCapitalForward_ets_ds_types                        = MdwAWMDModel
SIEMENSCapitalForward_MdwAWMDModel_ets_nr_types           = mdzip
SIEMENSCapitalForward_MdwAWMDModel_ets_dst_ds_type        = Text
SIEMENSCapitalForward_MdwAWMDModel_ets_dst_nr_type        = text
SIEMENSCapitalForward_MdwAWMDModel_ets_dst_relation_type  = IMAN_specification
SIEMENSCapitalForward_MdwAWMDModel_ets_dst_relation_to_src = false

Read that as a sentence: take an MdwAWMDModel dataset, pull its mdzip named reference, run the translator, and attach the result as a Text dataset with a text named reference, related to the source item revision by IMAN_specification.

This is the zero-Java recipe, deployed. Six preferences, one registration entry, no Java. It is the strongest available evidence that the preference route documented in this KB is the real production pattern and not merely a sample.

Two details worth noticing:

• The preference description is a copy-paste artifact. The description on SIEMENSCapitalForward_ets_ds_types reads "Specifies the datasets that the Siemens tozipfile service can translate." Whoever created it cloned the tozipfile preference and did not update the text. That is what hand-authoring looks like, and it is exactly the workflow this KB recommends (copy the sample XML, search and replace).
• _ets_nr_types holds a single value here, mdzip. Consistent with Siemens KB PL8058970, which reports the generic TaskPrep only honors the first value anyway.

⚠⚠ A source dataset type with no instances

Chasing whether that translator could ever fire turned up a second, independent reason it could not: its configured source type has no instances on the tier. The MBSE models it was clearly built for are stored under a completely different type prefix.

Worth checking on any translator you inherit: _ets_ds_types naming a type that does not exist, or exists with zero instances, is invisible in every config file and produces no error anywhere. It simply never fires.

⚠⚠⚠ A query returning zero can mean ACCESS DENIED

The most expensive trap on this page, and it produced two wrong conclusions before it was caught.

Searching as a restricted service account returned a clean 0 found for the objects in question. Not an error. Not a warning. Zero. The natural reading is "this data does not exist," and that reading was wrong: the objects were there the whole time, and the account was simply ACL-filtered from them.

What makes this vicious is that the usual calibration does not catch it. Verifying that the query mechanism works (search a type you know is populated, get hundreds of hits) proves only that the query works. It says nothing about whether your user can see the specific objects you are asking about.

The tell exists, but only on one route:

Route	Behaviour when denied
OOTB General... / Item Name saved queries	Clean 0. No error. No hint.
Internal-Query-2008-06-Finder/findObjectsByClassAndAttributes	Empty result plus partialErrors with code 525084 "Access denied"

So when a zero surprises you, re-run it through findObjectsByClassAndAttributes and look for 525084, and re-run it as a second user with broader rights before concluding anything is absent.

Practical rule for Dispatcher work specifically: the account you browse with is usually not the account Dispatcher runs as. A translator can be perfectly configured against data you cannot see, and data you can see may be invisible to the Dispatcher service account, which fails the extract at PREPARING for reasons no config file explains. Check both directions.

Category is not enforced

Dispatcher preferences on this tier live in three different categories:

Category	Example
Dispatcher	most of them
General	ETS.DATASETTYPES.SIEMENS.CMMCADTONX_DIRECT, ETS_trans_rqst_referenced_dataset_types
ADP.NXCatiaCoexistence	SIEMENScatiacoexist_ets_ds_types

The lookup is by preference name, not by category. Do not rely on category to find them, and do not assume a preference is missing because it is not filed under Dispatcher.

What this tier actually offers

ETS.TRANSLATORS.SIEMENS lists 70 services. Most map to the shipped catalog, but several are not in the shipped translator.xml at all:

CapitalForward, cmmcadtonx_direct, cmmcadtonx1_direct, cmmcadtonx2_direct, cmmcadtonx3_direct, cmmcadtonxpsd_direct, catiacoexist, catiav5tojtdirect, nxdwgtotif

Some of those are add-on product content rather than site customization (catiacoexist sits in an ADP. category, suggesting it arrives with a solution template). The point stands regardless: the shipped 78-service catalog is a floor, not a ceiling, and the live ETS.TRANSLATORS.<provider> preference is the only authoritative list for a given tier.

Other settings read live:

Preference	Value
ETS.PROVIDERS	SIEMENS only. No custom provider registered
DISPATCHER_CLIENT_INSTALLED	true
TCM_DISPATCHER_CLIENT_TIMEOUT	15
DISPATCHER_rqst_on_specific_dataset_revision	false
TC_tms_use_dispatcher_for_async_operation	false
ETS_trans_rqst_referenced_dataset_types	16 CAD and Office dataset types

ETS.TRANSLATORS.SIEMENS is the only Dispatcher preference seen with protectionScope: Site and isEnvEnabled: true; the rest are User scope.

✅ Settled at the host level

The SOA reads above could not tell us whether anything had ever run. Two queries returned zero and neither was evidence of absence (DispatcherRequest and MdwAWMDModel via the OOTB General... saved query; getTypeDescriptions2 also throws InternalServerException for both type names, and a zero from that saved query is a known non-result).

Resolved by reading the Dispatcher host directly, same day:

Question	Answer
Is Dispatcher deployed?	Yes. All three components installed as Windows services, version 2506.0004
Are they running?	No. All three Stopped, with StartMode: Auto
Has anything ever run?	Yes, extensively. 2,715 task log directories spanning four months
Has the custom translator run?	Never. Zero occurrences in any task log

So: a heavily-exercised Dispatcher installation, currently stopped, carrying one fully-plumbed custom translator that has never been invoked because its menu preferences were never created.

StartMode: Auto with State: Stopped is worth internalising. A service list proves deployment and nothing more. Only -ping or a fresh log timestamp proves operation.

The host also had 16 translators marked isactive="true", against the shipped default where only tozipfile is active. Enabling is per-site and the live file is the only authority.

Full detail on what a working one looks like, including the per-task log triplet and the real translator.xml attributes a tuned deployment uses: Anatomy of a working custom translator.

How this was read

Ordinary SOA, no Dispatcher-specific API:

Administration-2012-09-PreferenceManagement/getPreferences
  { "preferenceNames": [...], "includePreferenceDescriptions": true }

Missing preferences come back as partialErrors with code 1700 and the message The preference "X" cannot be found, while present ones populate response[]. That makes a single call an efficient probe: batch the six extract/load names plus the four menu names for a service and the shape of the reply tells you immediately which half is configured.

includePreferenceDescriptions: true is worth setting. The descriptions carry the authoritative semantics, and as CapitalForward shows, they also reveal provenance when someone has cloned a preference without editing the text.