Skip to main content
Matrix42 Self-Service Help Center

Marketplace Naming Conventions


Configuration-Item (CI), formerly called Type, is the data model container for Data-Definitions. The instance of a Configuration-Item is called an Object or SPS-Object.

Data-Definition (DD), formerly called Class, is the data model container for Attributes. The instance of a Data-Definition is called a Fragment, or in a database context a Data-Row.
Special Data-Definitions that carry named enumerated values are called Pickup-Data-Definitions or Pickup-Classes.
Data-Definitions that are included within a Configuration-Item with a >1 cardinality as well as their multiple instances within an SPS-Object are usually referred to as Multi-Fragments.

Attribute, when referenced outside a database context sometimes called Field,is the representation of an individual value. The instance of an Attribute is called (Attribute-)Value, or in a database context a Data-Cell. An Attribute that represents a connection to another Data-Definition is called a Relation, and the instances are also called Relations. The Cardinality of a Relation defines how often a Relation can be instantiated.

Configuration-Items, Data-Definitions, and Attributes are collectively called Schema or simply data model. The parts of the schema that are used to create the backbone of the ESM, such as storing the schema and master data that is necessary for basic functionality (e.g. accounts, users, roles, applications, navigation-items, grids, dialogs, wizards) form the Infrastructure. The parts of the schema that are used to create the operational features as well as moving data of the ESM are the Payload (e.g. incidents, assets, contracts). The infrastructure and payload that form a meaningful thematic entity within the ESM form the Functional schema. The infrastructure and payload that was added to the ESM to satisfy particular customer requirements are called Configurations if all done manually, or Customizations if additional code has been deployed in assemblies (DLLs). The distinction of configurations from customization is blurred and often used interchangeably.

Schema files are used to transport Configuration-Items, Data-Definitions, and Attributes, as well as payload data from one ESM installation to another, either per executable installer or per Configuration-Package. Schema files are usually collected into a folder or zip-archive and come with an index file (*.xml) that contains SchemaScript entries, that get stored in the target database upon import to an ESM system.

The naming of Configuration-Items, Data-Definitions, and Attributes, as well as payload data is the subject of this article.

Schema / data model

General prefixes and infixes are used to distinguish the context in which a Configuration-Item, Data-Definition, or individual Attribute/Relation exists. There are prefixes for functional distinction as well as distinction by originator. An interpretation as to the purpose of a component just based on the prefix is only partially possible. Unfortunately, in many environments, especially those that have existed for many years, a mixture of prefix usage can be found.
The main purpose of prefixes added by developers, consultants, or customers is to distinguish entities from those delivered within the ESM standard.

There are three prefixes that indicate a deviation from the deployed standard, which are:

Ud_ is the prefix used by customers and consultants for customer-specific extensions to the data model. This is the prefix usually enforced when working with the UI.

CUST is the prefix for specific extensions provided by the Marketplace team (Pollux, Custom-Dev). If created for a named customer, the prefix will be followed by an infix that is the shorthand for the customer name.

MPL is the prefix for common extensions provided by the Marketplace team.

When naming entities, multiple prefixes are to be avoided (e.g. CUSTUd_ or Ud_CUST). This includes adding Attributes without prefixes to a Data-Definitions that already has a prefix.
When working in a customer environment it may be advantageous to edit the SPSCustomizingOptionPickup and add specific prefixes and then select one of them in the Global Settings for immediate use.

When naming new Configuration-Items, usually a -Type suffix is used. Usually a similarly named Data-Definition is used as the main one with in the Configuration and then carries a -ClassBase suffix. Further Data-Definitions use a -Class- suffix/infix that expresses their purpose.

As an example, CUSTM42CoffeeType may contain CUSTM42CoffeeClassBase and CUSTM42CoffeeClassVendor.

Please mind that in Simple-Configuration-Items, the schema defines the CI and its main DD, however in the database only instances of the DD are stored, as none of the CI are needed.

Standard prefixes

Within the schema for standard entities the functional prefixes are listed below.

ACA SkyTap Integration Functional
ASM Asset Management Functional
BasicSchema Matrix42 Internal Schema Infrastructure Infrastructural
CHANGEINCIDENT Change & Incident Management Project-related
CHC Matrix42 Channel Support Functional
CLIFF, CLIFF_ Matrix42 Professional Services Project-related
COLOR Platform Color Management Functional
CR Compliance Rules Infrastructure Functional
CTM Contract Management Functional
CUST Marketplace General Infrastructure Project-related
CUST9AG Neun AG Product Project-related
CUSTACADEMY Matrix42 Trainings Management Project-related
CUSTISS Matrix42 Internal Service-Store Project-related
CUSTM42 Matrix42 General Infrastructure Project-related
CUSTM42PSO Matrix42 Professional Services Project-related
CUSTMPL Marketplace Product Project-related
DWP Matrix42 Workspace Platform Functional
EMP Empirum Integration Functional
FILECLASS Marketplace Platform Infrastructural
GDI, GDIE Data Import Functional
ITSM Matrix42 ITSM Platform Functional
LCM License Management Functional
LIS License Intelligence Service Functional
M42 Matrix42 internal development Project-related
MATRIX42 Matrix42 Product Project-related
MPL Marketplace Project-related
PDR Matrix42 UUX Infrastructure Infrastructural
PL Platform Infrastructural
PLBA PlBa Infrastructural
PLBE Platform Business Engine Infrastructural
PLCV Platform Convenience Functional
PLRE Platform Reporting Engine Infrastructural
PLSC PlSc Infrastructural
PLSL Platform Service Layer Infrastructural
PLST PlSt Infrastructural
PLSTS Platform Security Token Infrastructural
PLTO Platform Transport Operations Functional
PLWE Platform Workflow Engine Infrastructural
PSO Matrix42 Professional Services Project-related
SAL Sales Administration Project-related
SCCM Microsoft SCCM Integration Functional
SCHEMA Schema Infrastructure Infrastructural
SLM Software License Management Functional
SPS Software Provisioning System Functional
SVC Service Catalog Functional
SVM Service Management Functional
U4U Matrix42 Internal Infrastructure Infrastructural
U4UQA Matrix42 internal Quality Assessment Infrastructural
UD_ Customer-specific Integrations Project-related
WS Platform Infrastructural

Customer-specific prefixes

Over the years in many customer environments, dedicated extensions and customizations have been introduced. To identify those, specific prefixes have been defined, as listed below. When defining new specific prefixes for a customer, the customer should be asked if there is an already known and used abbreviation for their company or department.

Customer Prefix/infix/suffix formerly used prefix/infix/suffix
Phoenix Contact CUSTPxC  
Deutsche Flugsicherung CUSTDFS  
Matrix42 CUSTM42  
R+V Allgemeine Versicherung CUSTRUV CUSTCLMS, CUSTZISS
Magna Powertrain CUSTMPT  
Magna Regioportal CUSTMRP  
Akquinet CUSTAKQ  
Thüringer Energie AG CUSTTEAG  
Main-Kinzig-Kreis CUSTMKK  
Raiffeisen Rechenzentrum Bregenz CUSTRRZ CUSTRBGV
Mediengruppe Pressedruck CUSTMPD  
Osiandersche Buchhandlung CUSTOBU  
Landratsamt Karlsruhe CUSTLRAKA  
Hochland CUSTHL  
Hohenstein CUSTHOH  
Energiewerke Nord CUSTEWN  
Georg Fischer CUSTGF  
Landeshauptstadt Erfurt CUSTLHE  
Rhenus CUSTRHS  
Sparda-Bank CUSTSPB  
Koch, Neff und Volckmar CUSTKNV  
Mittelbayerische Zeitung CUSTMZ  
Kanton Luzern CUSTKLU  
FutureDat CUSTFDAT  
P3 Group Ingenieurgesellschaft mbH CUSTP3G  
Rheinisch-Westfälische Technische Hochschule Aachen CUSTRWTH  
Otto Dunkel CUSTODU  
MSH Medien System Haus GmbH & Co. KG, Stuttgart CUSTMSH  
Kassenärztliche Vereinigung Bayerns CUSTKVB  
Operational Services CUSTOS  
Jenoptik SSC GmbH CUSTJEN  
Jenoptik AG CUSTJOAG  
Randstad Deutschland GmbH & Co. KG CUSTRSH  
IBM Deutschland Aviation Industry Workplace Services GmbH CUSTIBM  
IBM Deutschland Aviation Industry Services GmbH CUSTIBMCHN  
Matrix42 Marketplace Utility MPLUtility CUST.Utility
ADK GmbH für Gesundheit und Soziales CUSTADK  
Windmöller & Hölscher CUSTWNDM  
Salzgitter Flachstahl GmbH CUSTSGFS  
Landgard Service GmbH CUSTLG CUSTLGS

Schema Files

The naming of files used in indexed imports by various tools, including the upload of Configuration Packages, follows a pattern that ensures that said files can be uniquely identified in any ESM environment.
The schema files deployed by the Marketplace team do follow this naming conventions, while those from other sources may not.

The general setup of file names follows this pattern:

<major>-<minor>-<build> <context><customer>_<infix>_<name>.<extension>

e.g. 02-70-6013

<major> Major versioning, always 02
<minor> Minor versioning, taken from prodcut version 10.2.x ➡ 102
<build> incremental versioning, usually starting at 5000 for customizing projects and increasing either per file or batch
<context> either prefix by origin or taken from the Customer-specific prefixes
<infix> abbreviated symbol to indicate the content kind, see table below
<name> naming for the content, either for CI, DD, or Object. This can be a compound of several elements, e.g.  <classname>_<attributename>
<extension> file-system indicator for basic content, see table below

For the most commonly used infixes and extensions assigned to the respective content kind, please use this list.

Kind Context Extension Infix Types
Prerequesite SQL Payload *.pre    
Pickup Data-definition Data-model *.pickup    
Pickup Data values Data-model *.dat _Pic_  
Data-definition Data-model *.class    
Configuration-item Data-model *.type    
Attribute Data-model *.class    
Relation Data-model *.relation    
Configuration-item update Data-model *.type    
Transport Item-Kind Infrastructure *.dat _TIK_ PLTOItemKindType
Transport Selection-Descriptor Infrastructure *.dat _TSD_ PLTOSelectionDescriptorType
MPL Project Settings Infrastructure *.dat _MPS_ MPLProjectSettingsType
User Role Infrastructure *.dat _Role_ SPSSecurityTypeRole
Engine Infrastructure *.dat _Eng_ PLBEEngineTypeCustom
Engine Activation Infrastructure *.dat _EngAct_ PLBEActivationType
Service Payload *.dat _Srv_ SPSArticleTypeGroup
Workflow Activity Infrastructure *.dat _WFC_ PLSLBinaryComponentType
Workflow Descriptor Infrastructure *.dat _WFD_ PLSLXamlComponentType
Workflow Configuration Infrastructure *.dat _WFDC_ PLSLWorkflowConfigurationType
Change Template Infrastructure *.dat _CHT_ SVMChangeTemplateType
Script Definition Infrastructure *.dat _Scr_ SPSScriptDefinitionType
GDIE Definition Payload *.dat _GDI_ GDIEImportType
Compliance Rule Payload *.dat _CR_ SPSComplianceRuleType
Services Host Infrastructure *.dat _Host_ PLBEHostType
Services Catalog (portfolio) Payload *.dat _Clg_ SPSPortfolioType
Location Payload *.dat _Loc_ SPSLocationType
Organization Unit Payload *.dat _OU_ SPSOrgUnitType
Cost Center Payload *.dat _CC_ SPSCostCenterType
Web Service Infrastructure *.dat _WS_ PLSLServiceTypeWCF
Web Service Operation Infrastructure *.dat _WSO_ PLSLWebServiceOperationType
UUX Control-Descriptor UUX UI *.dat _CD_ PDRControlDescriptorType
E-Mail Descriptor UUX UI *.dat _ED_ PDRContentWidgetTypeEmail
UUX Data-Query UUX UI *.dat _DQ_ PDRDataQueryType
UUX Widget Template UUX UI *.dat _CWT_ PDRContentWidgetTemplateType
UUX Dialog UUX UI *.dat _WDlg_ PDRContentWidgetTypeDialog
UUX Widget Template View UUX UI *.dat _CWV_ PDRContentWidgetTemplateViewType
UUX Content Widget UUX UI *.dat _CWB_ PDRContentWidgetTypeBase
UUX Application UUX UI *.dat _App_ PDRApplicationType
UUX Content-Structure UUX UI *.dat _CStr_ PDRContentStructureType
UUX Landing-Page UUX UI *.dat _WLP_ PDRContentWidgetTypeLandingPage
UUX Dataset View UUX UI *.dat _WLs_ PDRContentWidgetTypeList
UUX Preview UUX UI *.dat _WPrv_ PDRContentWidgetTypeObjectDetails
UUX Wizard UUX UI *.dat _WWz_ PDRContentWidgetTypeWizard
UUX Data-Query Filter UUX UI *.dat _DQF_ PDRDataQueryFilterType
UUX Action UUX UI *.dat _Act_ PDRActionType
UUX Navigation-Item UUX UI *.dat _Nav_ PDRNavigationItemType
UUX Migration History UUX UI *.dat _MgH_ PDRMigrationHistoryType
UUX Theme UUX UI *.dat _Thm_ PDRThemeType
Any data Payload *.dat    
Widget data Payload *.dat    
Configuration-item auto-numbering Data-model *.type    
Object Deletion Payload *.del    
Binary Component Payload *.bin    
Post SQL Payload *.post    
Post SQL Localization Payload *.post    
Files-Table Entry Payload *.bin    
Reference-Mapping Descriptor Legacy UI *.dat _RMD_  
Reference-Mapping Descriptor Legacy UI *.dat _RMD_  
Columns settings (grid-layout) Legacy UI *.dat _Grid_ SPSContentTypeGridLayoutEx
Legacy Structure Legacy UI *.dat _Struct_ SPSContentTypeStructureStatic
Tabulator Legacy UI *.dat _Tab_ SPSContentTypeSearchTab
Workspace Legacy UI *.dat _WKS_ SPSContentTypeWorkspace
Legacy Workflow Descriptor Legacy UI *.dat _WFL_ PLWEWorkflowDescriptorType
Legacy Wizard Legacy UI *.dat _Wiz_ SPSWizardTypeWizard
Legacy Wizard Page Legacy UI *.dat _WizPg_ SPSWizardTypeWizardPage
Alert Legacy UI *.dat _Alert_ SPSAlertDescriptorType
Event Handler Legacy UI *.dat _EvtHdl_  
Legacy Action Group Legacy UI *.dat _ActionGr_ SPSTaskGroupType
Legacy Action Legacy UI *.dat _Action_ SPSActionTypeTask
Legacy Object-dialog page Legacy UI *.dat _DialogTab_ SPSContentTypeObjectDialogTab


Developers usually follow the coding conventions that are widely accepted for respective languages such as C# or JavaScript. Hungarian notation is strictly recommended against.
When defining entities that derive from the data model of the database, either Pascal-case or Camel-case should be used, depending on context. In automatically generated code, the database prefixes are usually kept while the case is adjusted (ASM > Asm, CR > CoRu, CTM > Ctm, EMP > Emp, GDIE > Gdie, LCM > Lcm, LIS > Lis, PLBE > PlBe, PLBA > PlBa, PLRE > PlRe, PLSC > PlSc, PLWE > PlWe, PLSL > PlSl, PLST > PlSt, SCCM > Sccm, SLM > Slm, SPS > Sps, SVC > Svc, SVM > Svm, GDI > Gdi, CUSTM42 > CustM42, CUST > Cust, Ud_ > Ud, MPL > Mpl, PDR > Pdr, and so forth).
When writing code that could potentially be seen by customers, as in JavaScript expressions within dialogs or wizard pages, using meaningful and explanatory variable names is recomemnded, so that a reader can easily grasp the context and purpose of the code.

  • Was this article helpful?