Error in rule for attribute generation

Identity Security Cloud (ISC) ISC Discussion and Questions
, , , ,
1

Hello,

I’m trying to create a Google account through an access request. The email address is generated by a custom rule of type Attribute Generator.

I was able to create two users successfully, but the third attempt fails with the following error:

An unexpected error occurred: org.apache.bsf.BSFException: BeanShell script error: Sourced file: inline evaluation of: `` import sailpoint.api.*; import sailpoint.connector.*; import sailpoint.object.* . . . ‘’ unknown error: Unable to make public final java.util.Iterator java.util.HashMap$EntrySet.iterator() accessible: module java.base does not “opens java.util” to unnamed module @5889e35a : at Line: 278 : in file: inline evaluation of: `` import sailpoint.api.*; import sailpoint.connector.*; import sailpoint.object.* . . . ‘’ : if ( no_email_for_ANY_of == null ) { BSF info: Unique GoogleEmail Generator at line: 0 column: columnNo

Do you have any idea what the root cause could be?

The no_email_for_ANY_of structure is a map passed as input to the rule and it is static, meaning it is always populated with the same values. It was already populated in the first two attempts, which completed successfully.

Thanks in advance for your help.

2

Hello,

Your rule probably only hits the code path that iterates over the map (or otherwise touches entrySet().iterator()) for some identities, and the first two users didn’t trigger that path.

Avoid iterating via entrySet()/keySet() iterators in BeanShell. Instead, turn keys into an array and loop by index (no iterator reflection):

// no_email_for_ANY_of is your input Map
if (no_email_for_ANY_of != null) {
  Object[] keys = no_email_for_ANY_of.keySet().toArray();  // <-- key trick
  for (int i = 0; i < keys.length; i++) {
    Object k = keys[i];
    Object v = no_email_for_ANY_of.get(k);

    // ... your logic ...
  }
}

if you want to validate quickly you can add a debug log right before any map iteration and log the identity / branch taken, so you can confirm which code path triggers the reflective iterator access.

If you paste the relevant part of your rule (especially around line ~278 where the exception points), I can look at that section