Backoffice Config Generator

Describe an item type's Backoffice presentation once -- get the cockpitng config XML for the explorer tree, list view, advanced search, editor area and create wizard.

🔒 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

Item type name is required.
Explorer tree parent node is required.

Item typeThe existing or new item type this config targets. PascalCase, e.g. LoyaltyPoints.Item type name is required.

Explorer tree

Parent node id

Tree label

List view columns

Advanced search fields

Editor area tabs

Generate a create wizard context

trainingcore/resources/backoffice/trainingcore-backoffice-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Backoffice (cockpitng) config scaffold for MyItem.

  cockpitng config is one of the least standardized, most version-dependent
  areas of SAP Commerce -- element/attribute names here (especially the
  explorer-tree node nesting and the advanced-search operator binding) are
  the most commonly documented forms, not a guarantee across every
  cockpitng version. Verify against this project's actual schema.

  Note on labels: rather than inventing an uncertain separate
  "<ext>-backoffice-labels_en.properties" convention, labels are emitted as
  inline <label> elements / "label" attributes directly in the contexts
  below -- this matches how most real cockpitng config XML carries labels.
-->
<config xmlns="http://www.hybris.de/cockpitng/config/hybris">

    <!-- Explorer tree: nests MyItem under the "masterCatalogsNode" node.
         The exact nesting mechanism (parent-id attribute vs a <nodes>
         wrapper) varies by cockpitng version -- verify against this
         project's platform config. -->
    <context merge-by="type" type="MyItem" component="explorer-tree">
        <explorer-tree>
            <node id="myItemNode" parent-id="masterCatalogsNode" labelI18nKey="myItem.node.label">
                <label>MyItem</label>
                <type code="MyItem"/>
            </node>
        </explorer-tree>
    </context>

    <!-- List view columns -->
    <context type="MyItem" component="listview">
        <listview>
            <list-columns>
                <!-- no list columns configured -->
            </list-columns>
        </listview>
    </context>

    <!-- Advanced search fields -->
    <context type="MyItem" component="advancedsearch">
        <advanced-search>
            <search-attributes>
                <!-- no advanced search fields configured -->
            </search-attributes>
        </advanced-search>
    </context>

    <!-- Editor area tabs/sections/attributes -->
    <context type="MyItem" component="editorArea">
        <editorArea>
            <!-- no editor tabs configured -->
        </editorArea>
    </context>

</config>

Generated scaffold. Review and test before using in production.

What is a Backoffice config in SAP Commerce?

Backoffice (cockpitng) config XML is what wires a custom item type into the SAP Commerce Backoffice administration console: where it shows up in the explorer tree, which columns its list view shows, which attributes the advanced search can filter on, and how its editor screen is laid out into tabs and sections.

This config is additive -- it merges into the platform's existing Backoffice configuration rather than replacing it, which is why most contexts use a merge-by attribute to target a specific item type without clobbering other extensions' config for the same type.

When to use it

Use it any time you add a new custom item type (or extend an existing one with new attributes) and want business users or admins to be able to find, search, view and edit it in Backoffice without writing a bespoke widget.

Skip it for types that are only ever read/written by code and never need a human-facing admin screen.

Files generated

One <ext>-backoffice-config.xml with context elements for explorer-tree, listview, advancedsearch, editorArea, and (optionally) the create wizard.
Labels are emitted inline in the XML (via <label> elements and label attributes) rather than a separate properties file -- that matches how most real cockpitng config actually carries labels.

Step-by-step: how to use the output

Copy the generated XML into your extension's resources/backoffice/ folder (create it if it doesn't exist) and make sure the extension is registered as a Backoffice config extension in its extensioninfo.xml (<backoffice/> element).
Restart Backoffice (or the whole server, depending on your setup) so the new config is picked up -- cockpitng config is generally not hot-reloaded.
Open Backoffice, find the item type under the explorer tree node you configured, and check the list view columns, advanced search fields and editor tabs/sections render as expected.
If the create wizard was generated, test creating a new instance through it -- wizard-conf structure is one of the areas most likely to need adjusting for your platform version.

Common mistakes

Forgetting merge-by="type" (or the matching attribute for other contexts) -- without it, your config can silently override rather than merge with another extension's config for the same item type.
Pointing the explorer tree node at a parent-id that doesn't exist in the current tree -- the node simply won't appear, with no obvious error.
Assuming the advanced-search operator attribute name/behavior is identical across platform versions -- it's one of the more version-dependent parts of cockpitng config and is worth checking against a known-working example in the same project.
Not restarting/rebuilding Backoffice after adding new config -- stale cockpitng config is a frequent source of "my change isn't showing up" confusion.

Frequently asked questions

Does this config replace the need for items.xml?

No -- items.xml defines the item type itself (attributes, relations, persistence). Backoffice config only controls how an already-defined type is presented in the admin UI; you need items.xml first.

Why use merge-by instead of just writing the context directly?

merge-by tells cockpitng how to combine your context with config for the same type/component coming from other extensions (including OOTB ones) -- without it you risk one extension's config silently overwriting another's instead of merging.

Can I reuse the same editor area tabs in the create wizard?

Many real projects do exactly that to avoid duplicating attribute lists, though the wizard-conf schema is less standardized than editorArea -- check your platform's documented wizard structure before assuming it matches editorArea 1:1.

Where do labels actually come from if there's no properties file?

This generator inlines labels directly as <label> elements/attributes in the config XML, which is the simpler and more common pattern. Larger projects sometimes additionally externalize labels into Backoffice-specific properties files for translation, but that's a separate, optional layer on top of this config.

Why does nothing happen after I deploy the config?

cockpitng config is typically read once at Backoffice startup, not hot-reloaded -- restart Backoffice (or the app server) after adding or changing config files.

Related tools

What should we write next? Vote