TeamcenterKnowledge

Skills

Cameo TC Diagram Images

Skill cameo-tc-diagram-images. Get Cameo/MagicDraw diagram images into Teamcenter and make Active Workspace preview them. Covers what the connector actually produces (a JPEG picture plus an SVG that is NOT a picture), the AWC_defaultViewerConfig.VIEWERCONFIG entry that decides which one the viewer serves, the diagram-type filter that silently skips most diagrams, and the site-preference write mechanics including a payload that faults on a null member and a write that returns HTTP 200 and changes nothing. Use for "SVGs from Cameo to Teamcenter", any Seg0Diagram preview problem, blurry diagram previews, or any Teamcenter site-preference write.

Run status: EXERCISED on vm2606 (TC 2606) 2026-08-20, HCLTech Cameo Connector for Teamcenter v2506, against item 007224 blockInstanceDemo. Every claim below came back from a call or a downloaded file.

The one thing that surprises everyone

The SVG the connector sends is not a picture. It is a geometry-only hit-map. Here is a complete real one, 1,524 bytes, pulled out of the volume:

<svg ... xmlns:diagram="http://www.eclipse.org/sirius/diagram/1.1.0" fill="black" stroke="black" ...>
<g>
<rect x="5" y="5" width="475" height="137" fill="none"
      diagram:semanticTargetId="_2024x_3_62f021a_1787234016841_673377_3690" .../>
<rect x="28" y="98" width="226" height="24" fill="none"
      diagram:semanticTargetId="_2024x_3_62f021a_1787234020843_371526_3718" .../>
<rect x="28" y="49" width="228" height="24" fill="none"
      diagram:semanticTargetId="_2024x_3_62f021a_1787234029401_930627_3744" .../>
</g>
</svg>

No text, no fills, no labels. Every rect carries diagram:semanticTargetId pointing at a model element, in the Eclipse Sirius diagram namespace. It is a click-to-element coordinate overlay meant to sit on top of the JPEG.

The install guide's line "this format is currently usable only by certain downstream applications in Teamcenter" is saying exactly this, and it is easy to read as a licensing or maturity caveat instead.

Turning on SVG therefore cannot improve a preview, and pointing the image viewer at the SVG makes the preview render as empty outlines. If someone asks for SVG export to fix a blurry diagram, that is the wrong lever, and this skill is the place to say so before anyone changes a preference.

What actually lands in Teamcenter

Each Cameo diagram becomes one Seg0Diagram dataset (displayed as "Modeling Diagram"), attached to the Uml0MLModelRevision by TC_Attaches. The .mdzip itself lands separately as Mdw0MDModel on IMAN_specification.

Named references come from FileMap entries in the connector's integration definition (MAGICDRAW_BHMIntegrationDefinition_TC<rel>.xml, in the Seg0 ObjectMapping):

<FileMap fileExt="jpg" tcNameReferencedType="Seg0JPEG" isText="false"/>
<FileMap fileExt="svg" tcNameReferencedType="Seg0MISC" isText="false"/>

Read them back with tc_get_properties on the dataset, attributes ref_list,ref_names. ref_names is the list of named-reference types and ref_list the filenames, positionally paired.

Note Seg0MISC is a generic bucket, not an SVG-specific reference. Anything else miscellaneous on the same dataset shares it.

Two connector settings, and the filter that eats most diagrams

In <Cameo>/plugins/CameoTCIntPlugin/conf/cameotcIntegration.properties (the Cameo Connector Config switcher exposes both on its "Diagram images" page):

Key Effect
ENABLE_SVG_CREATION false means no SVG is produced at all
DIAGRAM_TYPES_FOR_SVG_CREATION comma-separated diagram type names; only listed types get an SVG

The filter is the usual reason "only some diagrams got an SVG". Observed on 007224: four diagrams, three Block Definition Diagrams and one Internal Block Diagram, and only the IBD had an SVG, because the list contained SysML Internal Block Diagram and not SysML Block Definition Diagram. An empty list means every type.

The type strings must match what Cameo declares in <Cameo>/data/defaults/data/diagrams/*/descriptor.xml (the type attribute). A type Cameo does not know is never matched and simply produces nothing, with no error anywhere.

The preference that decides what the preview shows

AWC_defaultViewerConfig.VIEWERCONFIG, a Site-scope string array. The relevant element:

Seg0Diagram.Awp0ImageViewer=Seg0JPEG,Seg0MISC

Format is <DatasetType>.<Viewer>=<namedRef>[,<namedRef>...], and the viewer serves the first named reference it finds. Proven by flipping the order and watching the AWC preview header change from ..._3690.jpg to ..._3690.svg and back.

Leave it as Seg0JPEG,Seg0MISC. That is the correct order, because the JPEG is the only one of the two that contains a rendering.

Two useful facts about this preference:

  • Awp0ImageViewer really does render SVG. The same array ships Crf0ScalableVectorGraphics.Awp0ImageViewer=Crf0ScalableVectorGraphics OOTB. So a blank SVG preview is the file's content, not a viewer limitation.
  • SE_DiagramViews.<view>.Uml0MLModelRevision is a different thing (it governs the Architecture diagram tab, not the image viewer) and is easy to reach for by mistake. On vm2606 it is not even defined.

Reading the header beats judging by eye

The AWC preview pane prints the filename, extension included, next to the diagram name. When both a .jpg and a .svg exist on one dataset, that string is the only reliable way to tell which one is being served. "It looks fuzzy" is not, and it also cannot distinguish "the viewer chose the JPEG" from "no SVG was ever generated for this diagram".

Writing a Teamcenter site preference (generalises beyond diagrams)

Administration-2012-09-PreferenceManagement/setPreferencesAtLocations:

{"setPreferenceIn": [{
   "location": {"location": "Site"},
   "preferenceInputs": {"preferenceName": "<NAME>", "values": ["...", "..."]}}]}

Traps, all hit for real:

  1. Do not send "object": null in location. The XSD declares PreferenceLocation as an object member plus a location attribute, so a null object looks correct. It returns fault 214022, "An error has occurred during the JSON parsing". Omit the member entirely and it returns 200.
  2. A non-DBA account no-ops silently. As an ordinary Designer the identical write returned ok: true, HTTP 200, empty partialErrors, and changed nothing. Connect as the DBA account for site-scope preference writes.
  3. The write replaces the whole array. There is no append. Read, mutate one element programmatically, write the full array back. Never retype it.
  4. On the read side, getPreferences takes includePreferenceDescriptions, plural. The singular spelling faults 214022.

Two sessions can see different values for the same site preference

Observed on vm2606, and it cost a lot of time: infodba read Site as Seg0MISC,Seg0JPEG while ed read Site as Seg0JPEG,Seg0MISC, in the same minute, with no User/Group/Role override on either (confirmed via getPreferencesAtLocations at the User location, which returned no value).

One site preference cannot have two values. The cause is a stale tcserver preference cache: pooled tcserver processes read site preferences at startup, and a change does not propagate into already-running ones. Sessions pinned to different tcservers therefore disagree, indefinitely.

Consequences worth carrying:

  • A "the preference did not change" report may be false. Reconnecting does not help if the new session lands on the same stale server. Cross-check with a second account before concluding a write failed.
  • This also explains an AWC UI that ignores a correct preference. The fix is to recycle the tcserver pool, not to edit the preference again.
  • A read that has never been observed to change is not a proven instrument. Get a known-good control (write something and watch it move) before reporting a negative.

Verify a preference write by diffing, not by reading

before = read()                      # capture first
new = list(before); new[i] = ...     # mutate programmatically
write(new)
after = read()                       # FRESH session
assert len(after) == len(before)
assert [j for j in range(len(after)) if after[j] != before[j]] == [i]

Also compare the value sets (sorted(a) == sorted(b)), not just positions. The Teamcenter preferences UI re-appends the element you edited to the end of the array, so a hand edit legitimately changes many positions while losing nothing. Position-only diffing reads that as damage.

Image quality: there is no lever

The connector config has 34 keys total and none control resolution, DPI, scale, or JPEG quality. The docs have none either. The -Dsun.java2d.uiScale=1 line in the install guide is a workaround for the embedded Active Workspace browser panel, not for image export.

Measured output (JPEG pixel dimensions read from the SOF marker of files pulled out of the volume):

Diagram Pixels
Internal Block Diagram 485 x 147
Block Definition Diagram 532 x 750
Block Definition Diagram 372 x 163

The SVG hit-map gives the IBD's logical canvas as 475 x 137, and its JPEG is 485 x 147. So the connector renders 1:1 with the diagram's own canvas plus about a 5px margin. Nothing is downsampled. Blurriness is Active Workspace upscaling a small image, so the only certain remedy is a physically larger diagram in Cameo. Untested: whether the exporter honours Cameo's own image-export scale setting.

Pulling a dataset file out to look at it

The fastest way to settle "is this file what I think it is". Note the service version, which is the one that trips people up:

Core-2006-03-FileManagement/getFileReadTickets with {"files": [{"uid": "<ImanFile uid>", "className": "ImanFile", "type": "ImanFile"}]}. (FileManagement-2007-01-... does not exist and faults 214086.)

The response is data.tickets, a two-element parallel array: [0] the objects, [1] the ticket strings. Download with the live session cookies:

GET <host>/fms/fmsdownload/?ticket=<urlencoded ticket>

Get the ImanFile uids from the dataset's ref_list property. See tc-datasets-files for the write direction.

Order of investigation that works

  1. Read the dataset's ref_names / ref_list. Does an SVG even exist?
  2. If not, it is ENABLE_SVG_CREATION or the diagram-type filter. Stop here.
  3. If it does, read the AWC preview header for the extension being served.
  4. Only then look at AWC_defaultViewerConfig.VIEWERCONFIG.
  5. If the preference looks right but behaviour disagrees, suspect the stale tcserver cache and re-read as a second account.

Generated from skills/cameo-tc-diagram-images/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.