The hAC Power User Guide: Consoles, Diagnostics, and the Tricks Support Uses

Every SAP Commerce node ships with the Hybris Administration Console, and most developers use a tenth of it: run a FlexibleSearch, import an ImpEx, restart when confused. The other nine tenths are where production incidents get diagnosed, so this guide is a tour of hAC as the people who live in it use it, with the platform facts that make each screen meaningful. On CCv2 the same console is there behind the appropriate endpoint (locked away from the public internet, per the web architecture guide); everything below applies to cloud and on-premise alike, aspect differences noted where they bite.

The Consoles#

FlexibleSearch console (Console > FlexibleSearch) runs both FlexibleSearch and raw SQL, shows the translated SQL for any FlexibleSearch query, and that translation view is its most underused feature: it is the fastest way to understand what the type system actually generates, which table a localized attribute lives in, and why your join multiplies rows. Habits worth forming: check the execution time it reports against the same query parameterized differently (cache effects are visible), use session user and language switches to see visibility rules applied (restrictions change results, which is a feature and a debugging trap), and remember result rows are PK-hydrated live, so a 500k-row select in production hAC is a self-inflicted load test. The FlexibleSearch mastery guide covers the language; the console is where you interrogate it.

ImpEx import and export consoles run scripts interactively with validation modes (strict versus relaxed), legacy mode toggle, and a dry-run habit you should enforce on yourself in shared environments: Validate only first, read what it says, then import. Export deserves more love than it gets: it answers "what does this data actually look like" faster than Backoffice, and an export script per core entity belongs in the team's snippet library for support tickets and environment comparisons (the ImpEx reference guide goes deep on syntax).

Scripting console (Console > Scripting Languages) executes Groovy (plus BeanShell/JavaScript) with full Spring context access: any bean, any service, live. Two facts govern its safe use. First, the commit toggle: in rollback mode (default) your script runs in a transaction that is rolled back, which makes it a free experiment; in commit mode it is a production data change with no undo. Second, scripts run as the session you hold, on the node you hit, with the node's classloader: what works here is real, which makes it the sharpest debugging tool the platform has and also the reason auditors ask who has hAC access. The responsible pattern for anything mutating: write it as a rollback-mode probe printing what it would change, review output, then flip to commit once.

// probe first: what would we touch?
def flexibleSearchService = spring.getBean("flexibleSearchService")
def query = "SELECT {pk} FROM {Cart} WHERE {modifiedtime} < ?stale AND {user} = ?anon"
def result = flexibleSearchService.search(query,
    [stale: new Date() - 30, anon: userService.getAnonymousUser()])
println "would remove ${result.count} anonymous carts"
// only after review, in commit mode: modelService.removeAll(result.result)

Platform and Diagnostics Screens#

Cache (Monitoring > Cache) exposes the region caches with live hit ratio, fill, and eviction counts per region, plus a clear-cache action per region and cluster-wide. This is where the persistence and caching guide's numbers come from when you do not have Dynatrace attached. Reading it under load beats reading it idle: an entity region at 99% fill with rising evictions during the morning peak is a sizing conversation; the same numbers at 3 a.m. are noise. Clearing caches in production is occasionally legitimate (after out-of-band data surgery) and always a customer-visible latency event; know why before you click.

Cluster (Platform > Cluster) shows node membership and lets you verify what the clustering guide assumes: every node visible, broadcast working (there is a ping). After any topology or networking change, this screen is your first stop; a node missing here explains "stale data on some requests" mysteries instantly.

PK analyzer (Platform > PK Analyzer) decomposes any PK into its type code and creation metadata, and resolves it to the item. When a stack trace, a log line, or a foreign key in the database hands you a bare PK, this turns it into "ah, a PriceRow created during last night's import". The reverse lookup (type code to type) also settles deployment-table questions from the type system guide without opening items.xml.

Extensions (Platform > Extensions) lists every loaded extension with its webroot. Two operational uses: verifying what actually deployed (manifest debates end here), and the security sweep from the hardening guide (sort by webroot, justify every web module you see; VJDBC and friends have no business in production).

Update/Initialize (Platform > Update) runs system updates with per-extension control over essential data, project data, and localizations. Production rule: the update screen is part of your deployment procedure, not an ad hoc tool, and the initialization half is why system.unlocking.disabled=true exists (an unlocked production initialize button has erased at least one estate you have heard of). The lock is one property; set it everywhere above dev.

Support and licenses: the support screen bundles logs and configuration for SAP tickets; the license screen answers audit questions (including the cache-entry threshold tied to the high-performance license on-premise).

Logging and JDBC Tracing at Runtime#

Log levels change live (Platform > Logging): pick a logger (your package, de.hybris.platform.servicelayer, whatever), set DEBUG, reproduce, set it back. No restart, per node, temporary by design since it does not persist. This is the correct answer to "add more logging and redeploy" in most incidents; the logging guide covers making the good levels permanent.

JDBC logging (Monitoring > Database > JDBC logging) records every statement with timings to a dedicated log, which turns "the database is slow" into a named query with a stack of evidence. The discipline: enable, reproduce the slow flow once, disable, analyze offline (the log is verbose enough to hurt a busy node). Combined with the FlexibleSearch console's SQL translation, you can go from symptom to offending FlexibleSearch to missing index in one sitting; the query tuning guides take it from there.

Thread dumps and JVM state (Monitoring > Threads, Memory): a hung request investigation starts with three thread dumps ten seconds apart, from the affected node. hAC gives you that without shell access, which on CCv2 is exactly what you have.

Benchmarks: Trust, then Verify the Infrastructure#

Under Monitoring > Performance live the Linpack and SQL micro-benchmarks referenced in the on-premise guide, and their real value is comparative: run them idle, per environment, and store the numbers. A staging environment scoring half of production's SQL average explains a "staging is slow" ticket before anyone blames code; a production node diverging from its peers flags an infrastructure problem to raise with your provider. Interpret with the documented caveat: SQLMax exercises writes without the platform's prepared-statement tuning, so it validates connectivity and relative health, not real-world throughput.

hAC in Anger: Three Recipes#

• "Some users see old prices." Cluster screen (is a node missing broadcasts?) then Cache screen per node (entity region hit ratios diverging?) then, if a node is isolated, recycle it and file the networking question. Minutes, not hours, once the path is habitual.
• "Checkout got slow at 14:00." Logging screen: DEBUG on your checkout facade package on one storefront node; JDBC logging one reproduction long; thread dumps if requests hang rather than crawl. Correlate with the cronjob screen in Backoffice for the 14:00 sync somebody scheduled (see the clustering guide's placement rules).
• "What is this PK in the error log?" PK analyzer, then FlexibleSearch console on the resolved type with the modifiedtime nearby, then the audit trail if the type carries one. You now know what the data was, when it changed, and which import touched it.

The console rewards fluency the way any diagnostic surface does: the team that tours these screens on a calm Tuesday is the team that looks calm on a bad Friday. Put hAC literacy in onboarding, restrict who holds it in production, and treat the scripting console's commit toggle with the respect you give a loaded tool.