Please share any images or screenshots, if relevant.
Share all details about your problem, including any error messages you may have received.
Our Delta Account Aggregation is failing with error “Required string attribute ‘authorizationType’ is not defined.” However, we have defined this attribute within our domain settings (note: we have two domains one parent one child, e.g. dc=child,dc=acme,dc=com and dc=acme,dc=com), both using strong.
And I have double checked our Account and Group schema do use “distiniguishedName” as identity attribute.
And still we are getting the exception only for delta account aggregation while normal account aggregation runs successfully. In addition, the delta account aggregation somehow run longer than the full aggregation. (e.g. delta runs 1 hour, and full runs only 10 mins) Any advise is welcome here.
Out of curiosity, have you tried creating a new AD application in the UI with the same settings as this one and testing? We’ve had problems with the config becoming corrupted in the past that threw this error message.
First, try clearing the cache from the Object Browser by going to Configuration Objects and then Reset Configuration Cache.
If you’re using Tomcat, restart the application server by deleting temp and work folder to clear the cache. Note: You MUST stop the Tomcat server before deleting these folders content. While the temp and work folders in Tomcat can generally be deleted safely, stopping the server beforehand is crucial to prevent corruption or issues.
After that, take a look at the Application configuration and the Task Definition in both the UI and the Object Browser.
This process might give you some insight into what could be causing the corrupted configuration.
unfortunately, this only occurs on Production, the lower environment does not have this issue. As it’s on production, we normally not using the UI, instead during each release we reimport the artifacts.
this sounds interesting, but do you know what’s the reason here, do you mean the tomcat temp and work folder somehow cache it ?
Another information is that, this problem happens after we upgrade to 8.4p2, we are using SSB deployment (means we built new package for 8.4p2 with SSB and replace the old 8.4p1 identityiq/ on tomcat)
For others to reference the purpose for both folders:
Folder
Purpose
Safe to Delete?
When to Delete
/temp
Runtime temp files (uploads, caches, temp data)
Yes (when stopped)
To clear old uploads, free disk space, or reset temp state
/work
Compiled JSPs, cache, serialized sessions
Yes (when stopped)
To force JSP recompilation, fix corrupted cache, or clean space
This might be a solution to go, but it’s interesting, because … on both UI and Object Browser (DB) the configuration looks all correct. Therefore, I am assuming some 8.4p1 complied JSPs or cache still persistent under tomcat. I will ask operation team see if we can proceed this solution on production thanks!
Are you able to compare the configs in the actual identityiq.SPT_APPLICATION table in the database? I’ve had issues where XMLObjectFactory didn’t know how to parse a part of the application config, so it just decided to not show that part in debug. When I checked the object in the actual database table, there was a reference to an invalid object that the xml serializer was hiding from the debug UI. It’s a long shot, but there could be something wrong or different with the application config that you just can’t see in debug.
yes, I can request that, but while comparing this with other lower environment (which does not have this issue) the file mostly the same, I will try the tomcat /temp and /work folders clean up first and then come back to your suggestion later But thanks a lot for your hints!
Thanks for the response. I liked your comment and the information about the temp and work folders.
In the IT software field, the fix is often a restart (of services or the system) or clearing the cache when everything looks good on the UI. We may not know what’s happening behind the scenes, but errors may or may not provide clues. Still, these tricks are worth trying out as one time solution.
If you are able to consistently replicate this behavior, it would be best to submit a ticket to the SailPoint team. They will be able to provide guidance on how to handle the specific scenario of clearing the cache without restarting the application server.
Try out with clearing the caches etc , in case it don’t get fixed , enable the logger for Aggregator API and see what exactly is going on internally . It might give some idea.
Yes (when stopped)
But thanks a lot for your hints!