Email Generator

Describe an email once -- get the process XML, EmailContext class, Spring beans, subject/body Velocity templates, the ImpEx that wires up the CMS EmailPage, and the event/listener that triggers 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

Email name is required.
Process name is required.
Site / content catalog id is required.

Email nameUsed for the EmailContext class, templates, and the triggering event.

Process nameBecomes OrderConfirmationEmailProcess -- the item type driving the send.

Site / content catalog idScopes the generated EmailPage/content slot ImpEx to this content catalog.

Languages (comma-separated ISO codes)One localized properties file is generated per language.

Context attributes

Values the email needs -- populated onto the process, read by the EmailContext, and used as the event's fields.

trainingcore/resources/processes/orderConfirmationEmail-process.xml

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="http://www.hybris.de/xsd/processdefinition"
                     name="orderConfirmationEmailProcess" start="start">

    <start name="start">
        <transition name="OK" to="generateEmail"/>
    </start>

    <action id="generateEmail" bean="generateOrderConfirmationEmailAction">
        <transition name="OK" to="sendEmail"/>
    </action>

    <action id="sendEmail" bean="sendOrderConfirmationEmailAction">
        <transition name="OK" to="removeSentEmail"/>
    </action>

    <action id="removeSentEmail" bean="removeSentOrderConfirmationEmailAction">
        <transition name="OK" to="success"/>
    </action>

    <end name="success" state="SUCCEEDED"/>

</process-definition>

Generated scaffold. Review and test before using in production.

What is an Email in SAP Commerce?

A transactional email in SAP Commerce (Hybris) -- order confirmations, registration emails, password resets -- is driven by a small business process (extending StoreFrontCustomerProcess) whose actions generate the email content from a Velocity template, send it, and clean up afterwards. The content side is a CMS EmailPage: a RendererTemplate per Velocity file, wired together by an EmailPageTemplate and EmailPage, with the page's content slots scoped to a content catalog.

An EmailContext class (extending AbstractEmailContext, or CustomerEmailContext for order-related emails) populates the Velocity model from the running process instance, so the templates can reference e.g. $context.get("orderCode") without any Java-side string building.

When to use it

Use this generator for any customer-facing transactional email that needs to be triggered by a domain event -- order confirmation, shipment notification, account registration, password reset, and similar one-shot notifications tied to a business process.

If the email doesn't need its own process (e.g. a one-off marketing blast sent from a campaign tool), most of the scaffolding here -- the process XML, the event, the listener -- isn't needed; just the EmailContext/Velocity/ImpEx pieces apply.

Files generated

The process-definition XML wiring start -> generateEmail -> sendEmail -> removeSentEmail -> end(SUCCEEDED).
An items.xml snippet for the process type, extending StoreFrontCustomerProcess.
The EmailContext class populating the Velocity model from the process instance.
A Spring XML registering the process-definition resource, the three email actions, the EmailContext bean, and the event listener.
Subject and body Velocity templates (.vm) using $context.get("...") placeholders.
ImpEx creating the RendererTemplate, EmailPageTemplate, EmailPage, and content slot rows, scoped to your content catalog.
The triggering event class and its listener, which starts the business process.
Localized properties (<ext>-locales_<lang>.properties), one file per language.

Step-by-step: how to use the output

Copy the process XML into <extension>/resources/processes/ and merge the Spring beans into your extension's -spring.xml.
Copy the EmailContext, event, and listener Java classes into their packages under <extension>/src/, and merge the items.xml snippet into your extension's -items.xml, then run an update.
Copy the two .vm templates into <extension>/resources/email/<name>/ and import the ImpEx via HAC > Console > ImpEx Import (or a SystemSetup) to create the RendererTemplate/EmailPage rows.
Publish the event from the code path that should trigger the email (e.g. after an order is placed) via eventService.publishEvent(...) -- the listener starts the process, which generates and sends the email.
Verify the rendered email in HAC's email preview (or by triggering a real send in a sandbox) before enabling it in a live environment.

Common mistakes

Forgetting to scope the ImpEx to the right content catalog/catalog version -- the EmailPage and its slots must exist in the same content catalog the storefront is actually reading from.
Leaving the email action beans without the collaborators they need (emailService, modelService) -- GenerateEmailAction/SendEmailAction/RemoveSentEmailAction won't work with defaults alone; verify the exact property names against the acceleratorservices version installed.
Hardcoding the subject/body text in the Velocity template instead of resolving it from the localized properties file -- it defeats the point of generating one properties file per language.
Not adding the context attributes as items.xml attributes on the process type -- without them, the EmailContext's process.getXxx() calls generated here won't compile.

Frequently asked questions

Why does the process type extend StoreFrontCustomerProcess instead of plain BusinessProcess?

StoreFrontCustomerProcess (via CustomerProcess) already carries a reference to the customer and base site, which almost every transactional email needs (to know who to send to and which storefront's branding/content to use) -- extending it means the Email generator doesn't have to redeclare those attributes.

What's the difference between AbstractEmailContext and CustomerEmailContext?

AbstractEmailContext is the generic base that any process type can extend to populate a Velocity model. CustomerEmailContext adds order/customer-specific convenience accessors and is the usual choice when the triggering process is order-related; this generator defaults to AbstractEmailContext and flags that choice as something to verify against your project's acceleratorservices version.

Do I need a custom process type for every email?

Yes in the OOTB pattern -- Backoffice's process monitoring and the generateEmail/sendEmail/removeSentEmail actions all operate on a concrete process instance, so each distinct email needs its own process type (even if, like here, it's a thin one with just a couple of extra attributes).

How do I actually trigger the email from my own code?

Inject EventService and call publishEvent(new <Name>RequestedEvent(...)) with the context attribute values. The generated listener catches that event, creates and starts the process, and the process's actions take care of generating and sending the email.

Why generate one properties file per language instead of one shared file?

SAP Commerce resolves localized properties by file suffix (-locales_en.properties, -locales_de.properties, etc.), so each language needs its own file -- this mirrors exactly how a real multi-language storefront extension is laid out.

Related tools

What should we write next? Vote