Build item types, enum types, map types, and relations visually -- get a schema-ordered items.xml and its locales properties.
🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.
trainingcore/resources/trainingcore-items.xml<?xml version="1.0" encoding="UTF-8"?>
<items xmlns="http://www.hybris.de/xsd/items"
xsi:noNamespaceSchemaLocation="items.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</items>
items.xml is the schema file that defines every custom item type, enum type, map type, and relation in a SAP Commerce (Hybris) extension -- the platform's equivalent of a database schema plus ORM mapping in one declarative file. Running an update (ant updatesystem or the Update step in Platform/System Initialization) reads it and creates/alters the underlying tables.
Sections are schema-ordered (enumtypes, then maptypes, then relations, then itemtypes), and item types declare their attributes, persistence (plain property vs a dynamic attribute handler), modifiers (optional/unique/read/write/initial/localized), and optional indexes for query performance.
Use items.xml whenever a feature needs its own persisted type -- a new domain entity, an enum of fixed values, a many-valued lookup map, or a relation between two existing types -- rather than bolting ad-hoc data onto an unrelated attribute.
Extend an existing OOTB type (extends="Product", extends="GenericItem", etc.) when the feature is naturally "a kind of" something the platform already models; define a brand-new top-level type only when it genuinely doesn't fit anywhere in the existing model.
The numeric typecode (set via <deployment table="..." typecode="..."/>) is the integer SAP Commerce stores internally to identify the item's type, used in the PK encoding. Codes below 10000 are reserved for OOTB/platform types -- pick 10000 or higher for anything custom to avoid colliding with a future platform type.
extends sets the item type's position in the type hierarchy -- the new type inherits every attribute of its parent (and its parent's parent, etc.), and instances of it satisfy FlexibleSearch/Java type checks for the parent type too. Nearly everything should extend at least GenericItem, directly or transitively.
type="property" is a normal persisted column -- the platform stores and loads the value directly. type="dynamic" computes the value on read/write via a Spring-registered AttributeHandler bean instead of storing it as its own column -- useful for derived values, but it needs that handler bean to actually exist or the attribute silently returns null.
Each side's role qualifier is the attribute name used to navigate the relation from that side's type -- e.g. a LoyaltyAccount2LoyaltyTransaction relation with target role "transactions" gives LoyaltyAccountModel a getTransactions() method. Both sides need one because the relation is navigable in both directions.
The schema requires enumtypes, maptypes, relations, and itemtypes to appear in that order because later sections can reference types defined earlier (an itemtype attribute can be typed as an enum or used in a relation) -- the platform's XML parser expects that ordering and can fail the update step if it's violated.