Error - provisioning rule causing all names to appear "NULL, NULL" in application

[colsmith (Cole Smith)]

We’ve created a provisioning rule to get the name of an identity’s manager and populate the preferred name of the manager in the application information. However, we’ve come across the following error:

“Maximum refresh exceptions reached
BeanShell script error: bsh.EvalError: Sourced file: inline evaluation of: import sailpoint.object.Identity; import sailpoint.object.Application; impor . . . '' : illegal use of null value or 'null' literal : at Line: 41 : in file: inline evaluation of: import sailpoint.object.Identity; import sailpoint.object.Application; impor . . . ‘’ : ; BSF info: NM_Rule_NM_SNOW_Manager_Change at line: 0 column: columnNo”

For some reason it’s throwing an illegal use of null values on the line of the code where imports start.

Please see:

Now it’s populating thousands of Manager’s names with “NULL, NULL” and though we think that it’ll eventually cascade down with our hourly aggregation tasks, we’re trying to figure out why it’s happening in the first place.

[markearnest]

I’m not 100% sure the rule in the screenshot is the problem. The error refers to code that starts with an “import sailpoint.object.Identity” statement and this code starts by importing sailpoint.api.IdentityService.

One thing I would do is wrap your code in a <![CDATA[ ]]> tag.

[colsmith (Cole Smith)]

Apologies Mark,

I had the incorrect rule posted. I just updated it with the one that’s throwing the errors. We tested these for a couple use cases (Manager name) being one of them and had no issue, but we can’t even run the Adhoc Identity Sync task for Cubes without it throwing the above error.

[colsmith (Cole Smith)]

We also confirmed that the java is wrapped in CDATA tags - so that shouldn’t be the issue. I posted the correct code SS in the original post.

[brian_weigel]

@colsmith - What type of rule is this? Can you scroll up and show the full rule signature as well? It looks like it could be a provisioning form FieldValue rule, or could be an attribute sync IdentityAttributeTarget rule as well.

I would also suggest rerunning the rule with trace logging set for your rule’s logger and include that as well. The beanshell error output isn’t always the greatest - your actual error could be elsewhere in the code and not with the imports.

[colsmith (Cole Smith)]

This rule is being used for our Service Now connector to update Manager’s names. We’ve got Identity Attributes in our Mapping that’s pulling in preferred_first from our HR system.

But for some reason it’s just filling them with “NULL, NULL” - when we run the Adhoc Identity Refresh it fixes it, but if we run the refresh again on the fixed cube it will go back to NULL, NULL - so it’s oscillating between the two.

[brian_weigel]

Thanks! I’m not sure if it will totally fix your issue, but I do have some suggestions to try and hopefully make it a bit more resilient…

1. Instead of keying off the value arg input (which can be finnicky at times), leverage the input Link arg. So instead of this:
   
   
   
   you can resolve the Identity and Manager identity via:

Identity idt = link.getIdentity();
Identity mgrIdt = null;
// Note the use of the 'instanceof' operator to botn null-check and type-check the result...
if (idt instanceof sailpoint.object.Identity) {
   logger.trace("Got Identity: " + idt);
   mgrIdt = idt.getManager();
}

Note: You could also just use the identity input as well:
Identity mgrIdt = identity.getManager();

The next couple of notes are regarding this code block:

2. You can simplify getting the Application object by using the following instead:
   Application app = link.getApplication();
3. Before iterating your snowLinks List, I would add in a null-check and a not-empty check:

if (snowLinks instanceof java.util.List && !snowLinks.isEmpty()) {
   logger.trace("Have " + snowLinks.size() + " SNOW links");
   // Insert the 'for' loop here...
}

4. This if condition shouldn’t be necessary given how you’re resolving the Applications and Links via the IIQ API instead of needing to compare to a hard-coded value. And the method-chaining used is more likely to result in a NPE than any actual failed validation.
   

   

5. Generally speaking, a void return (return;) tends to work better than a null return (return null;) in these rules.
   

6. From a technical perspective, the link.getAttribute(String key) method’s return is a generic Object. You can avoid potential class cast exceptions if you use something like the sailpoint.tools.Util class to explicitly convert the return to a String object (to help ensure consistency). So this…
   

   
   
   Would become something like this:

String managerFirstName = Util.otoa(managerAppLink.getAttribute("first_name"));
String managerLastName = Util.otoa(managerAppLink.getAttribute("last_name"));

Note that it’s still possible for either of those to be null, so I’d also suggest doing a null/empty check to ensure they’re properly resolved and populated.

As a final note - you mentioned that one refresh results in the error and bad behavior, but another seems to fix it. If that’s the case, I’d suggest adding a Beanshell namespace dump at the start of the rule (just after your imports) and compare the namespace dump from the run that works as expected to the one that doesn’t. See: https://community.sailpoint.com/t5/IdentityIQ-Articles/Dumping-the-Beanshell-Namespace-in-a-Rule/ta-p/80909

Good luck!