15.1 Leveraging the Debug Pages for Debugging
Key Takeaways
The Debug pages are reached through the wrench menu or http://host:port/identityiq/debug and require the System Administrator capability; from 8.4, a Debug Pages Read Only Access capability can be granted.
The Object Browser is the most-used page: it views and edits the XML of any object and exposes many console-style actions in the UI.
About shows the host, IdentityIQ version, schema version, locale, time zone, and Java properties; Threads, Memory, Call Timings, Database, and Connections help diagnose performance.
Saved Debug-page edits have no rollback, so export or check out an object, change a copy, and import it instead.
Enable the Debug Object Browser Change audit action to record who changed what class through the Debug pages.
Leveraging the Debug Pages for Debugging
Objective 6.4 asks you to leverage the debug pages for debugging. The Debug pages give administrators direct access to the XML of every object and to live information about the running server.
Access
- Use the wrench icon menu, if shown, or go straight to
http://<host:port>/<context>/debug, for examplehttp://localhost:8080/identityiq/debug. - Normally only users with the System Administrator capability can use them.
- From IdentityIQ 8.4, administrators can grant the Debug Pages Read Only Access capability. Read-only users can open the Object Browser and the other pages. They can view, copy, or download XML but cannot save, upload, or run actions such as Run Rule or Run Garbage Collector, which appear disabled. Finer-grained read-only rights can be grouped into custom capabilities, for example database pages only for a DBA.
- The documentation warns that read-only users can still see every object, including sensitive data. Grant access with care.
- Users without either kind of access get Access Denied.
The Pages
| Page | What it shows or does | Typical debugging use |
|---|---|---|
| Object (Object Browser) | Lists objects by class and shows or edits their XML. Many console actions are also available in the UI. | Inspect an identity, Link, workflow case, application, or configuration exactly as stored |
| About | Server host, IdentityIQ version and schema version, client locale and time zone, Java system properties | Confirm patch level after patching (section 3.2), and check time zones |
| Memory | Free, total, and maximum JVM memory | Spot memory pressure during large tasks |
| Caches | Buttons to manage the Hibernate caches | Clear stale cached configuration |
| Count | Object counts by class | Sanity-check data volumes, for example after an aggregation |
| Beans | JMX beans registered with the application server | Advanced runtime inspection |
| Threads | All Java threads and their states | Diagnose hangs and slow tasks, alongside Administrator Console stack traces |
| Call Timings | Time spent on certain database activities | Find slow persistence operations |
| Logging | Views or changes the path to the Log4j properties file | Confirm which logging configuration is in effect (section 14.1) |
| Database | Basic connection-pool information | Check pool configuration |
| Connections | Connections the server is currently using from the pool | Detect pool exhaustion or leaks |
| ActiveMQ Monitoring | Broker information, connectors, statistics, destinations, subscriptions | Message-broker checks for Data Extract and Access History setups that use one |
Using the Object Browser Well
- Choose a class (for example Identity, Link, Application, Workflow, WorkflowCase, RequestDefinition, Configuration, or UIConfig) and search by name.
- Open the object to read its XML. This is the fastest way to answer questions such as what attributes did aggregation actually store on this Link?, which step is this workflow case waiting on?, or what is
maxThreadson the Aggregation Partition request definition? - Several documented procedures happen here, for example editing RequestDefinition objects to set hosts and maxThreads (section 2.1), adding an AccountIconConfig to UIConfig (section 2.3), and reading a Capability's
RightRefs(section 3.3).
Why Direct Edits Are Risky
The documentation is explicit: there is no rollback for edits saved in the Debug pages. The recommended practice is to export or check out the object, edit a copy, test it, and import it. That also keeps the change in source control (section 3.1). Treat a direct Debug-page save as an emergency fix that you must also copy back into the build. Otherwise the next deployment will overwrite it.
Worked Example: A Workflow Stuck in Approval
A requester says their access request has shown "pending" for a week, and the approver says there is nothing in their inbox.
- Object Browser > WorkflowCase: find the case for the request and read its XML. The current step is Manager Approval, and the approval owner resolved to an identity that is now inactive.
- Object Browser > WorkItem: confirm the open approval work item exists and is owned by that inactive manager.
- Fix the cause, not just the symptom. Forward the work item in the UI to the right approver. Then fix the workflow's owner resolution, for example with a fallback approver (section 4.3), and add or check the inactive user work item escalation rule (section 10.2).
- Do not hand-edit the WorkflowCase XML to "skip" the step. Direct edits have no rollback, and a corrupted case is harder to recover than a forwarded work item.
This pattern of reading the stored state in the Debug pages and then correcting it through supported UI actions is what the exam expects.
Auditing Debug Changes
Turn on Global Settings > Audit Configuration > General Actions > Debug Object Browser Change. Each save is then audited with the date and time, the source (who), and the target class (such as identity or bundle). The audit record does not show what changed, so use your own versioning for content. Find these records with Advanced Analytics > Audit, action DebugObjectBrowserChange, and export them as PDF, CSV, or CEF.
Debug Pages vs. the Console
| Need | Debug pages | Console |
|---|---|---|
| View or edit one object's XML | Easy, in the browser | get, checkout, checkin |
| Server internals (threads, memory, pool) | Yes | threads, about, properties |
| Bulk operations and scripts | Limited | source, -f, piping |
| Available remotely without server login | Yes | No, needs server access |
| Read-only access for developers (8.4+) | Yes | No, requires System Administrator |
After applying a patch, an administrator wants to confirm the running IdentityIQ version and schema version. Which Debug page shows this?
About
Count
Caches
Beans
A developer needs to read object XML in production to troubleshoot, but must not be able to change anything. What does IdentityIQ 8.4 and later provide?
The System Administrator capability with auditing enabled
Access through the console with the -c option only
The Debug Pages Read Only Access capability, which allows viewing and downloading XML but not saving or running actions
A copy of the database restored to the developer's laptop
Why does SailPoint advise against editing objects directly in the Debug pages?
Edits there are not saved to the database.
The Debug pages only support read access.
Saved edits have no rollback, so the safer practice is to export or check out, edit a copy, test, and import.
Edits there require an application server restart.
Security wants a record of who changes objects through the Debug pages. What must be enabled, and what will the record contain?
Syslog at WARN level; it records the full before-and-after XML.
Provisioning Transaction logging; it records the changed attribute values.
Access History; it records every Debug page view.
The Debug Object Browser Change audit action; it records the date and time, who made the change, and the object class, but not the details of the change.
Sections you finish are checked off in the contents.