Dispatcher: Building a Multi-Stage DevSecOps Pipeline

Status. This page describes a design, not a shipped capability. The mechanics it's built on (a workflow-triggered Dispatcher translator, checking its own artifacts into Teamcenter) are proven end to end, see Grand Challenge: live end-to-end run. The generalized multi-stage framework this page describes is architecture only: no router, no parallel-check topology, no gate stage has been built or run yet. Nothing here is screenshotted for that reason. Update this notice when that changes.

Dispatcher is a queued, distributed job-execution system with no CAD-specific assumptions baked in (see Overview). A "translator" is any executable that reads a staging directory and writes files back. That makes it a plausible substrate for CI/CD-style stages: scan, build, test, sign, gate, publish, each running as a translator, triggered from a Teamcenter workflow instead of a source-control webhook.

What this is for

A stage in this pipeline is a piece of governance or transformation work that has to run against real Teamcenter data, produce a real artifact, and be auditable: a modeling-rules check on a released assembly, a coverage gate on a generated export, a signed build of a deliverable. Doing this as a Dispatcher-triggered workflow instead of an external CI server means the work runs where the data already lives, under Teamcenter's own access control, with the resulting artifacts checked in as native, typed, related objects rather than files in an external build server nobody in Teamcenter can see.

Architecture

 ItemRevision (the thing under test)
   │
   │  attach a marker before starting a run
   ▼
 ┌─────────────┐        Start action, per stage task:
 │ MISC marker │◀───────  EPM-attach-related-objects  (pulls the marker onto the task)
 │  dataset    │◀───────  EPM-invoke-system-action     (records the task's uid)
 └─────────────┘◀───────  TSTK-CreateTranslationRequest (fires the stage's own ServiceName)
        │
        ▼
 Dispatcher Module ──▶ router executable ──▶ stage script
        │                                        │
        │                                        ▼
        │                                 checks in its own output,
        │                                 writes a result object
        ▼
 router completes the held task, using the uid captured at Start

Five parts, each with one job:

• The marker. A stock-typed (MISC) dataset, distinctively named, attached to the target ItemRevision ahead of a run. TSTK-CreateTranslationRequest can only match stock dataset types (it silently creates nothing against a custom type, see Triggering Translations from Workflow), which is why the marker exists at all: it's a matchable placeholder, not a payload. Its content is never read by anything downstream, only its existence, type and name matter, and exactly one exists per revision at a time.
• The router. One translator.xml service per stage, each carrying its own stage name, all pointing at the same executable (see Zero-Java Custom Translator for the underlying pattern). It checks the stage's output in via import_file, addressed by -itemRevUid specifically, never -item/-revision (the latter pair can report exit 0 on the identical failure that -itemRevUid reports correctly).
• Result objects. One per stage per run, holding a state (running/passed/failed/ inconclusive), a fingerprint of the tool that produced it, and the task uid it completes. Never shared or co-written across parallel stages, and never trusted as evidence a stage ran just because the object exists, downstream consumers verify the object against the run they're expecting, not just its presence.
• The gate. Compares against a persistent baseline (not the marker, not a per-run result object), reconciles its finding count against a source of record the stage itself never produced, and reports which specific hop lost content rather than a bare number mismatch. A baseline comparison that can't run reports as its own outcome, never as a silent pass.
• Parallel stages. Several checks (say: quality, conformance, spelling, modeling rules, program plan) run as separate task nodes, each on EPM-hold, each releasing independently once its own result object is written. A join task reads all of them before deciding whether to proceed.

Why a task's own "success" is never trusted alone

This is the load-bearing design rule, and it isn't hypothetical. TSTK-CreateTranslationRequest has a documented, correct-by-design path where zero matching datasets produce zero requests and a clean process completion, no error anywhere. If a stage's dataset type is ever wrong (see the constraint above), the wrapping workflow task reports success while nothing ran. The only reliable signal a stage actually executed is its own result object, addressed by the run's own id, never the task's or the Dispatcher request's reported state on its own.

The proven precedent this generalizes

The CapitalForward translator is one instance of this shape already running end to end: a workflow-triggered stage that extracts, transforms, and checks its output back into Teamcenter, with a working coverage gate keyed by occurrence rather than by name (name produced false findings in an earlier version, since it isn't unique). See Grand Challenge: live end-to-end run for the real proof. The multi-stage framework on this page is a generalization of that one proven stage into several, not a different mechanism.

Related

• Triggering Translations from Workflow — the handler this pipeline's trigger is built on, including the ordinary-business-user launch path.
• Zero-Java Custom Translator — the direct-pattern shell every stage script uses.
• Anatomy of a Working Translator
• Grand Challenge: live end-to-end run