Update to the Rule Developement Kit and supporting documentation

[philip-ellis]

We have shipped an update to the Rule Development Kit along with a refresh of the Java documentation that supports it. Here is what changed and what you may need to do.

IdnRuleUtil now identifies sources by ID

The IdnRuleUtil methods you use to look up accounts, attributes, and entitlements previously took an application name. That parameter is now documented as a source ID, and the internal application name is no longer front and centre in the public API. Parameters that used to read applicationName now read sourceId.

Your existing rules keep working. The account lookup methods still resolve a source name passed in place of an ID, so nothing breaks. New rules should pass the source ID.

A few methods do require the ID specifically - the ones that read entitlement data, source configuration, or searchable account attributes. The class-level documentation on IdnRuleUtil spells out which.

While we were in there, we also documented some API that had been available but missing from the docs:

• findManagedAttributes(...) for querying entitlements on a source, with the ManagedAttributeProperty and FindOperation enums and the TYPE_ENTITLEMENT / TYPE_PERMISSION constants

• Conversion and comparison helpers you can call directly on idn, including otoa, otob, asList, nullSafeEq, nullSafeCaseInsensitiveEq, nullSafeCompareTo, and dateToString

• getDisplayableName() on ManagedAttributeDetails

The Java docs have been rebuilt, and now have search

The documentation at developer.sailpoint.com/docs/extensibility/rules/java-docs has been regenerated with a modern toolchain. The most useful addition is a search box in the top right of the navigation bar — start typing and it will match against packages, classes, and individual methods. It is considerably faster than scrolling for what you need.

The layout is also cleaner and works properly on smaller screens.

Where the class list went

The old left-hand sidebar that listed every class is gone. It relied on HTML frames, which modern Java documentation tooling no longer produces.

To get the same list, use Index → All Classes and Interfaces in the navigation bar, or go straight there:

All Classes and Interfaces

Feedback

If you hit anything unexpected in the docs or the kit, reply here or open an issue on the Rule Development Kit repository. If there is a class or method you expected to find documented and did not, we would like to know.

[KevinHarrington]

So, does this mean that we need separate versions of rules for Sandbox vs PROD since the source ID’s will change between environments? And does that further mean that since the rules will contain different code, they will need to go through the review process for each environment to ensure that there are no other changes? And does it also mean that we effectively cannot migrate cloud rules using Configuration Hub anymore because of those changes?

[efreny (Oscar Yanez)]

One possible approach I see for improving portability is to derive the Source ID dynamically from an existing Identity Link. For example, after identifying the Source by name, Link.getApplicationId() can provide the corresponding Source ID. However, this only works when the Identity already has a Link for that Source. It does not solve cases where the Rule needs to reference another Source that is not yet linked to the Identity.

I could not find an officially supported IdnRuleUtil method to resolve an arbitrary Source/Application ID directly from its Source name without requiring an existing Identity Link. Would this be something SailPoint could consider as an enhancement? For example, providing a supported way to resolve Source Name → Source ID would make Rules that use sourceIds much easier to keep portable across tenants.

More generally, could this capability be exposed through the Rule Development Kit independently of the specific Rule type? This would allow a Rule to resolve a Source/Application ID by its unique Source name regardless of whether it is an IdentityAttribute Rule, Account Profile Attribute Generator, or another Rule type, without depending on an existing Identity Link.

I believe this would be particularly useful now that Source IDs are required by several Rule APIs, as it would provide a supported way to avoid hardcoded tenant-specific IDs while keeping Rules portable across Sandbox and Production.

[harshag]

As a workaround we are passing the tenant id from as an input. This will still require different transform between TEST and PROD. But it removes dependency on SailPoint to migrate code between TEST AND PROD.
String SOURCE_ID = "ete".equalsIgnoreCase(tenant) ? ETE_SOURCEID : PROD_SOURCEID;

[harshag]

“Your existing rules keep working.”

Unfortunately, that is not what we are experiencing.

The problem is that newly created sources no longer follow the naming convention that our rules depend on. I created a source on August 12, and its name was generated as appName [source-<id>] instead of the previously documented appName [source] format. As a result, our rules do not work for newly created sources.

The documentation still not updated (Aug 20), we had to identify the root cause hard way after spending many hours troubleshooting, which ultimately impacted our delivery timelines.

Wish SailPoint would focus a little more on the ISC developer experience. For external developers, the platform lacks the bare minimum tools, visibility, and documentation required for us to do our jobs.

[kirkkenton]

WHY? WHY do you always want to make this more difficult for customers to built Rules between a Sandbox and Prod environment. i finally found a solution this year to create a custom source named Global_Configs and created a single account in both prod and sandbox with the same name. This in Rules allows me to get this config source by name which is the same in both environments and lookup the account by name which is the same and then on that account create attributes for all my configuration items I might need that are different between sources. like my AD sources with different names and obviously IDs i need to look up. i just don’t get how you all make so many changes so frequently that just cause customers more work that we might not have because we are trying to also build and expand the use of SailPoint internally. I want IIQ back!!!