LCE rule not triggering sometimes

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

Which IIQ version are you inquiring about?

8.4

Share all details about your problem, including any error messages you may have received.

Is it possible that the newIdentity and previousIdentity argument in a LCE Trigger rule can get corrupted during aggregation? We are seeing a pattern where for rehire LCE, it works for 95% of the cases but rarely for some users, LCE doesn’t get triggered.
I didn’t get a chance to put loggers and check it (since its PROD, it will take some time to enable loggers and see), so just wanted to get a general opinion on this.

2

It is working for 95% of users, but for some users, you can check which identity attribute it is triggering from and verify whether all users have that attribute. Adding logs and checking them is a good idea.

3

I would suggest to enable the trace level of logging and add some more loggers to find out the issue.

4

Under certain circumstances, IIQ can corrupt the previousIdentity. The previousIdentity is created by unmarshalling the ARCHIVE column in the SPT_IDENTITY_ARCHIVE table. If there’s a reference that doesn’t exist anymore, the XMLObjectFactory can give you an invalid Identity object from the IdentityArchive. You can test by doing something like this:

import sailpoint.object.Identity;
import sailpoint.object.IdentityArchive;
import sailpoint.tools.xml.XMLObjectFactory;

IdentityArchive archive = (IdentityArchive) context.getObjectById(IdentityArchive.class, archiveId);
String xml = archive.getArchive();
XMLObjectFactory factory = XMLObjectFactory.getInstance();
Identity previousIdentity = factory.parseXml(context, xml, false);

Then you can compare the previousIdentity value with the original xml from the SPT_IDENTITY_ARCHIVE.ARCHIVE column in the database and see if they differ or use the previousIdentity object from this test to see if it does what you expect when passed through your trigger rule.

The existing ETN I had my case attached to is IIQETN-9855, but that one may be slightly different than your problem since our previousIdentity values were throwing NPEs when we passed them to IdentityService to check previous Link values.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.