DTO Generator

Describe a bean once -- get the beans.xml declaration and a preview of the Java class ybeangenerator would produce from it.

🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.

Extension name

Java base package

SAP Commerce version

Bean class name is required.

Bean class namePascalCase, e.g. LoyaltyAccountData. This is the class ybeangenerator will produce.

Extends (optional)Leave blank for a standalone bean, or name an OOTB/custom bean to inherit its properties.

Deprecated (adds @Deprecated to the generated class)

Properties

Enums

trainingcore/resources/trainingcore-beans.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.hybris.de/xsd/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="beans.xsd">

    <bean class="MyData" abstract="false">
    </bean>

</beans>

Generated scaffold. Review and test before using in production.

What is a DTO (beans.xml bean) in SAP Commerce?

A DTO ("Data") class in SAP Commerce (Hybris) -- things like ProductData, CartData, or a custom LoyaltyAccountData -- is never written by hand as a Java class. Instead you declare it as a <bean> in an extension's -beans.xml, and the platform build's bean-code-generator (ybeangenerator) generates the real .java class (fields, getters/setters, Serializable) into a gensrc folder at build time.

beans.xml also supports its own nested <enum> declarations, bean inheritance via extends (e.g. extending the OOTB ProductData to add a field), and generic property types like java.util.List<java.lang.String> -- all translated into equivalent Java by the generator.

When to use it

Use a DTO/bean whenever you need a plain data-carrier to move data between layers -- out of a Populator, into a Converter, across a REST controller (OCC), or as the return type of a facade method -- rather than exposing a persistence model (a *Model class) directly to a view or an API response.

Reach for extends on an existing OOTB bean (like ProductData) when you only need to add one or two extra fields to data the platform already returns, instead of inventing a parallel bean and a parallel converter.

Files generated

The <ext>-beans.xml snippet declaring the bean, its properties, and any nested enums.
A read-only preview of the Java class the platform's bean-code-generator would produce from it -- useful to sanity-check field types and getter naming, but never a file you commit or hand-edit.

Step-by-step: how to use the output

Copy the <bean> (and any <enum>) block into your extension's -beans.xml.
Run the platform build (ant build, or your IDE's equivalent) -- this is what actually invokes ybeangenerator and produces the real .java class in gensrc, not the preview tab here.
Reference the generated class by its simple name (e.g. LoyaltyAccountData) from a Populator, Converter, or controller once the build has produced it -- your IDE should pick it up after a build/refresh.
If you used extends, double check the parent bean's package/module is actually on your extension's classpath (via the owning extension's dependency), or the build will fail to resolve it.

Common mistakes

Hand-writing the .java class instead of declaring the bean in beans.xml -- any manual edits are silently overwritten on the next build since gensrc is regenerated every time.
Forgetting that generic types need the fully-qualified inner type too (java.util.List<java.lang.String>, not List<String>) -- beans.xml has no import statements, so every type reference must be resolvable on its own.
Not re-running the build after editing beans.xml and then wondering why the IDE still shows the old fields -- the generated class only updates once ybeangenerator actually runs again.
Declaring a boolean property and expecting a getX() getter -- a primitive boolean gets an isX() getter by convention; only the boxed Boolean gets getX().

Frequently asked questions

Why declare a bean in beans.xml instead of just writing the Java class myself?

beans.xml is the single source of truth the platform build reads to generate the class (and keep it consistent with extends/property changes across extensions). A hand-written class would be overwritten on the next build anyway, and you'd lose the declarative inheritance beans.xml gives you for free.

How do I extend an OOTB DTO like ProductData?

Set "extends" on your bean to the OOTB bean's simple name (e.g. ProductData) -- the generated class will extend it in Java, inheriting all of its properties, and you only declare the new fields your bean adds.

Can a property use generics, like a List of Strings?

Yes -- write the fully-qualified generic form, e.g. java.util.List<java.lang.String> or java.util.Map<java.lang.String, java.lang.Integer>. beans.xml has no import mechanism, so every segment of a generic type must be fully qualified or be a bean/enum declared elsewhere in the system.

How do enums work in beans.xml?

A beans.xml <enum> block declares a plain Java enum (not to be confused with an items.xml <enumtype>, which is a persisted platform type). It's generated the same way as a bean -- a real top-level .java enum file -- and can be referenced as a property type on any bean in the same or a dependent extension.

When does the real Java class actually get generated?

During the platform build (ant build/ant yall, or an equivalent IDE build step) via ybeangenerator, which reads every -beans.xml on the classpath and writes the generated classes into each extension's gensrc folder. The preview tab here mimics that output for a quick sanity check -- it is not what the build produces verbatim and is never meant to be committed.

Related tools

What should we write next? Vote