DS PACKAGESPECIALIZATION PACKAGEDEPLOYMENT PACKAGE

Data Model Customization (DMC) App — Reading Material

Source: Services Customization Guidelines, 3DEXPERIENCE R2022x — Lesson 4, Topic 1 (Data Model Customization Practices)

Contents

1. Where DMC Fits
2. What the DMC App Is
3. Core Terminology
4. Deprecation, Not Deletion
5. Constraints and Limitations
6. Golden Rules
7. Collaborative Spaces Control Center
8. Hands-On Exercise Walkthrough
9. Policy Customization
10. One-Page Recap

1. Where DMC Fits

Data Model Customization = configuring the OOTB Data Model and/or building new Data Model on top of it. There are two underlying data models on the platform, and different tools serve each:

Data Model	Applies to	Tools
IRPC (Instance Reference Port Connection)	Native Apps (CATIA, etc.)	Data Model Customization App, Collaborative Spaces Control Center App
ER (Entity Relationship)	Web Apps (3DSpace)	Data Model Customization App, Collaborative Spaces Control Center App, MQL/TCL, Spinner

Licensing / roles to know

• TXO license required to use the Data Model Customization app.
• Platform Managers role → access only to the Collaborative Spaces Control Center app (not full DMC).
• Spinner is not part of OOTB — needs a separate purchased license.
• MQL/TCL customization requires deep command + data-model knowledge — misuse risks data corruption.

2. What the DMC App Is

The Data Model Customization app (aka TXO) is DS's OOTB, unified framework for customizing the 3DEXPERIENCE platform's Data Model across all PLM applications.

Key features

• Single, common customization technique across all 3DEXPERIENCE apps (no more per-app inconsistency).
• Ships with a new generation of customization consoles that are simple to use and support instantaneous testing and deployment.
• Adds new modeling capacities: depth in hierarchy, discipline as Type.
• Works in both Baseline and CSE environments.

Why it replaced the old mechanism

The former Type customization approach was less restrictive (no declaration of which Types could be extended) and less protective (DS Types could be directly modified via the Business Modeler) — this caused upgradeability issues. DMC fixes this by formalizing what can/can't be touched.

Capability matrix (Baseline vs. capability level)

	Security Context	Can customize
Data Model Specialization	Role: Domain Expert; Context: Domain Expert.CompanyName.Default	Specialization Types (+ Attributes), Specialization Extensions (+ Attributes), Customer Extensions (+ Attributes), Unique Keys
Data Model Administration	Role: PLM Administrator; Context: VPLMAdmin.CompanyName.Default	Everything above + Deployment Extensions (+ Attributes)

• A PLM Administrator has everything a Domain Expert has, plus more.
• Domain Expert is typically used in CSE (finer organizational granularity needed).
• PLM Administrator is sufficient for all Baseline customization needs.

3. Core Terminology (memorize this)

Package — a group of Types/Extension Types bundled by domain.

• DS Package: DS-delivered Types/Relationships/Extensions. Read-only.
• Specialization Package: created by a Domain Expert; contains Specialization Types, Customer Extensions, Unique Keys.
• Deployment Package: created by a PLM Administrator; contains Deployment Extensions, Unique Keys.

Type

• DS Type: shipped by the application (e.g., VPMReference).
• Specialization Type: sub-type created by a Domain Expert, inherits (directly/indirectly) from a DS Type.

Extension

• DS Extension: shipped by the application.
• Specialization Extension: sub-extension by a Domain Expert, inherits from a DS Extension.
• Customer Extension: defined by a Domain Expert, does not inherit from a DS Extension — user must manually choose the object to apply it to.
• Deployment Extension: defined by a PLM Administrator, does not inherit from a DS Extension — gets applied automatically whenever a matching Business Object is created.

Unique Key — a set of Attributes used to uniquely identify objects.

Worked example (from the deck)

DS Package
 └─ Part Design (DS Type)
     └─ Part Design Electrical (DS Extension Type, +Attribute 'Capacity')

Specialization Package
 ├─ My BV Part Design Electrical (Specialization Extension Type, +Attribute 'BVSize')
 ├─ WHEEL (Specialization Type, +Attribute 'Diameter')
 └─ Customer Extension Type  → Domain Expert defines it; user manually applies it to an object

Deployment Package
 └─ Deployment Extension → PLM Administrator defines it; applied automatically on object creation

4. Lifecycle Management: Deprecation, Not Deletion

• Once a Package/Type/Extension/Attribute has been used to create objects, it cannot be deleted.
• To retire it, use Set Deprecated — hides it from native and web UIs without destroying data.
• Deprecated objects remain visible in the Specialize Data Model / Administrate Data Model modules, so you can later Undo Deprecated.
• Applies to Packages, Types, Extensions, and Attributes; you can deprecate several Packages in one operation.

Gotcha

A Package must have been deployed at least once before you can deprecate it (or any of its items).

5. Constraints and Limitations (trick-question territory)

UI constraints

• Cannot define a Customer Extension applied to Types that belong to 2 different Packages.
• Cannot create custom Dimensions.

Infrastructure constraints

• Cannot define a Deployment Extension that spans both Web app Types and Native app Types.

Naming / hierarchy constraints

• A Specialization Type/Extension cannot locally redefine an Attribute with the same name as one on its parent Type/Extension.
• Cannot apply an Extension whose Attribute name collides with an Attribute already on the object (from its Type or another Extension).
• Cannot apply two Extensions that share part of their hierarchy.

Once a Package is imported, you CANNOT:

• Remove a specialized type
• Change type hierarchy
• Remove an extension
• Change an attribute's type/name
• Remove an attribute

You CAN (after import):

• Add attributes

6. Golden Rules of DMC (interview favorites)

1. To restrict use of a custom Type/Attribute — Deprecate, don't delete.
2. Never remove an Attribute from a Type.
3. Never add an Attribute directly on a DS Type. Instead: create a Specialization Type (or apply an Extension) via the DMC app and add the attribute there.
4. Never delete Types/Attributes via MQL (backend tool).
5. Never modify the MQL properties Specializable / CustomerExtensible on OOTB Types/Instances.

7. Related App: Collaborative Spaces Control Center

Distinct from DMC — this is the one-stop configuration app, with two widgets:

• Collaborative Spaces Control Center widget: list/create Collaborative Spaces, transfer ownership, define who can create spaces, related settings.
• Collaborative Spaces Configuration Center widget: configure content behavior — naming/revision rules, lifecycles (Policy/Maturity Graph), access rules, automation, Attributes.

This is the tool Platform Managers (not full DMC users) use — and it's also where Policy/lifecycle customization happens in Baseline mode (see §9 below).

8. Hands-On Exercise Walkthrough

Goal: create a Specialization Package → Type → Attribute → deploy → add translation.

1. Log in to 3DSpace as a user with role Domain Expert (context: Domain Expert.CompanyName.Default).
2. Compass → Data Model Customization app → Specialize Data Model → New (Package):
   • Parent Package: EBOM
   • Name: EngineeringPackage
   • Prefix: SVC
3. Under Types, select Part → New (Type):
   • Parent Type: Part
   • Name: EngineeringComponent
   • Abstract: false
4. Open the new Type → Attributes tab → New Simple Attribute:
   • Name: ComponentSupplier, Type: String, Default Value: Public
5. Deploy Package command → confirm all alerts. (Nothing is live until deployed.)
6. NLS Translation (separate step, as admin_platform): Compass → DMC app → Manage NLS → Edit → key in translations (at least English) → Save → Reload Cache from Home.

Takeaway for interviews

DMC customization is a create → deploy two-step process, and it's always done through the app UI, never directly via MQL, and role/context matters (Domain Expert vs. PLM Administrator vs. admin_platform for NLS).

9. Policy Customization (same Lesson topic)

A Policy is a mandatory Administrative Object that:

• Controls a Business Object (every object needs exactly one governing Policy at a time, though a Type can have many possible Policies)
• Governs Access, Approvals, Lifecycle, Revisioning
• Defines States, Transitions, and Access Rights (Persons/Roles/Groups/Associations) per state
• Signatures control approvals between states — increasingly replaced by Routes (more flexible, web-controlled, support non-linear/branching lifecycles)

Access Flow order: User check → Policy check → then Rules (which can restrict specific Attributes/Programs/Relationships).

Baseline vs. CSE for Policy

	Baseline	CSE
Tool	Collaborative Spaces Control Center app	MQL/TCL, Spinner
Existing OOTB Policies	Configure only, not customize	Fully customizable (not DS-guaranteed)
New Policies	Cannot create	Can create
# states / maturity	Cannot increase	Fully customizable
Access control	Based on Baseline Roles	Can use CSE Roles

Recommendation: stay in Baseline and shape OOTB Policies within its constraints; CSE customization is a last resort and not guaranteed by DS to survive upgrades.

Configuring OOTB Policy in Baseline (Maturity Graph)

Via Collaborative Spaces Control Center → Configuration Center widget → Maturity Graph, a Platform Manager can:

• Rename states (changes NLS value; classic web apps auto-update after Reload Cache; native apps need local NLS file updates + app restart)
• Remove a state — only if it has no lock; removes its transitions too
• Restore a previously removed state (then must reconnect transitions)
• Add/remove Transitions between states
• Add/remove Transition Controls (rules) — e.g., block promotion unless a condition holds (checks can be scoped to specific Types even though the state itself is shared across all Types governed by the Policy)
• Rename transitions

Limitations: cannot add a brand-new state; only a limited set of OOTB Policies are configurable this way at all.

Rule of thumb for a valid graph

Every state except the first must have ≥1 incoming transition; every state except the last must have ≥1 outgoing transition.

Configuring Policy in CSE

• New Policies created via MQL (add policy ... with state clauses) or via Spinner spreadsheets:
  • SpinnerPolicyData_ALL.xls — Policy name/params (Registry Name, Description, Store, etc.)
  • Policy Access Files — per-state access definitions
  • SpinnerPolicyStateData_ALL.xls — states + their data
  • SpinnerPolicyRuleMappingData_ALL.xls — Rule access-constraints per state/Policy

One-Page Recap

• Two data models: IRPC (Native Apps) vs. ER (Web Apps); DMC app covers both.
• DMC app = TXO, needs TXO license, unifies customization, works Baseline + CSE.
• Domain Expert (Specialization) vs PLM Administrator (Specialization + Deployment) — Admin is a superset.
• Package/Type/Extension each have DS / Specialization / Customer / Deployment variants — know which role creates which, and which apply automatically vs. manually.
• Deprecate, never delete. Never touch DS Types directly. Never use MQL to delete schema.
• Exercise pattern: create → deploy → (optionally) translate.
• Policy = mandatory governance object (states, transitions, access, signatures/routes). Baseline = configure only (Maturity Graph tool); CSE = full customization via MQL/Spinner, at your own upgrade risk.

3DEXPERIENCE R2022x — Services Customization Guidelines — Lesson 4, Topic 1 ↑ back to top