Error in IIQ while doing changes for the identities

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Hi people,

I’m getting the below error.

  • An unexpected error occurred: org.hibernate.PropertyAccessException: Exception occurred inside getter of sailpoint.object.Application.aggregationTypes

Can someone tell me how to solve it.?

2

That error alone does not identify the root cause. Could you please share the complete stack trace, especially the deepest Caused by, along with your IIQ version and what action triggers the error?

The same Application.aggregationTypes error has occurred with different underlying causes. In one IIQ 8.3p4 case, SailPoint Support traced it to bad IDX values and the Correct IDX procedure resolved it. In another case, the underlying cause was a missing Schema object.

If your stack trace ends with a similar NullPointerException, I would then check the Correct IDX procedure. Its documented first execution runs the Support Task for Hibernate IDX in read mode without updating the database.

3

@70daadca52466159b25a266a11e514f Adding to what Harish mentioned — a few more things that might help narrow this down:

You mentioned “doing changes for the identities” — could you clarify if this happens during an identity refresh, aggregation, manual identity edit, or something else? That context will help pinpoint the issue.

Have you recently applied a patch, upgraded IIQ, or modified the Application configuration? Please do share the app xml for review.

4

Its happening during manual identity update process.

5

@70daadca52466159b25a266a11e514f Is this happening for all the users and everytime you try to edit identity from the UI? Could you please share your identity and application object config for review.

6

check if any index issue

7

I think you first try with re-import the Application XML. Export the affected application (the debug page or an iiq console export), check the schemas are sane in the XML, and re-import it. It will re-write the schemas collection with clean sequential index values and often resolves it without touching the database. If the application definition is okay and only the persisted index is corrupt, this is the cleanest way and fully reversible.

Next, the Correct IDX procedure. If re-import does not help it, or you find gaps across several applications, run the Correct IDX procedure. As Harish pointed out, first run the Support Task for Hibernate IDX in read mode first so you can see what it would change before doing a write pass. Back up the database prior to running the write pass anyway.

May be if you are provide these information would help to narrow down quickly:

  1. What is your exact IIQ version and patch level (e.g. 8.4p2), since the prior cases behaved differently across versions?
  2. What “changes for the identities” means concretely an identity refresh task, an account aggregation, a manual identity edit in the UI, or a rule/workflow? The trigger tells us where in the flow the schemas collection is being read.
  3. Have you recently upgraded, patched, or re-imported application XML? IDX corruption usually traces back to one of those, so if this started right after a patch or an import, that’s a strong signal on its own.