Describe a process as actions, wait nodes, and end states -- get the process-definition XML, action classes, Spring beans, items.xml, and localized properties, plus a live flow diagram.
🔒 Your code never leaves your browser — everything is generated locally from templates, no AI, no server round-trip.
trainingcore/resources/processes/myProcess-process.xml<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="http://www.hybris.de/xsd/processdefinition"
name="myProcessProcess" start="start">
<start name="start">
<transition name="OK" to="???"/>
</start>
</process-definition>
A Business Process in SAP Commerce (Hybris) is a state machine defined in an XML process-definition: a graph of actions, wait nodes, and end states, wired together by named transitions. The platform's process engine persists which node a running instance is on, so a process can span hours or days (e.g. waiting on a payment gateway callback) and survive a server restart.
Each action node delegates to a Spring-managed Java class (an AbstractSimpleDecisionAction for branching logic, or an AbstractProceduralAction for a single linear step), and the process itself is backed by a custom item type extending BusinessProcess so Backoffice's Business Process Monitoring can track running instances.
Use a Business Process for any multi-step workflow that needs to pause and resume -- order fulfillment, returns/cancellation flows, approval chains, or anything that waits on an external event (a payment confirmation, a warehouse callback) before continuing.
If a task is a single, self-contained unit of work with no branching or waiting, a CronJob is usually simpler. Reach for a Business Process once the workflow needs multiple steps, a decision point, or a wait on an asynchronous event.
Inject BusinessProcessService, call createProcess(processCode, processDefinitionName) to get a ProcessModel, set any context attributes on it, then call startProcess(process). Typically this is done inside an AbstractEventListener's onEvent() in response to a domain event.
AbstractSimpleDecisionAction branches: executeAction() returns Transition.OK or Transition.NOK and the process-definition needs both transitions wired for that action. AbstractProceduralAction is a single linear step -- executeAction() returns void and calls setTransition(Transition.OK) once it's done, so only one outgoing transition is needed.
A wait node pauses the process until a matching process event is received. Something elsewhere in the system (often an event listener) looks up the waiting process instance and publishes the named event to it, which resumes the process along the wait node's "then" transition.
Yes for anything beyond the most trivial process -- a type extending BusinessProcess is what Backoffice's Business Process Monitoring cockpit tracks, and it's where you'd add any context attributes (like a cancellation reason) the process needs to carry between actions.
Changing the XML only affects processes created after the change -- a running instance keeps following the definition it was started with. Plan schema/flow changes with that in mind, especially for long-running processes.