Best Way to Provide IdentityIQ JavaDoc as a Reference for AI Coding Assistants

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

Hi everyone,

I’m working with SailPoint IdentityIQ 8.4 and exploring how to use AI coding assistants, such as Claude or ChatGPT, to help develop, review, and troubleshoot IdentityIQ Rules written in BeanShell.

I want the AI to use the official IdentityIQ JavaDoc as its primary reference when generating or reviewing code, particularly for SailPoint classes, methods, parameters, return types, and supported API signatures.

I can access the JavaDoc through my IIQ environment:

https:///identityiq/doc/javadoc/

I also have access to the local doc/javadoc directory.

My questions are:

  1. What is the recommended way to provide this JavaDoc to an AI assistant so it can reliably reference the correct classes and methods?
  2. Is there a way to make the JavaDoc accessible as a knowledge source, MCP server, or another integration that AI coding tools can query directly?
  3. Would uploading the JavaDoc HTML files or providing a local documentation directory be sufficient, or is there a better approach?
  4. How do you ensure that AI-generated Rules use APIs compatible with your specific IdentityIQ version and avoid hallucinating methods or using unsupported signatures?

My goal is to help the AI generate more accurate IdentityIQ Rules based on the official documentation, rather than relying on generic Java knowledge or unverified examples.

I’d appreciate any recommendations, tools, or practical approaches from people who have implemented a similar workflow.

Thanks in advance!

3

Hello Islam. Since you already have the IIQ 8.4 JavaDoc locally, I think you could start with a simpler approach before exploring MCP or RAG. For Claude Code, you could give it access to your JavaDoc folder using: claude --add-dir /path/to/iiq-8.4-javadoc

For ChatGPT, you could create a Project and upload the relevant JavaDoc classes as text or Markdown, if your organization permits it. To check whether an AI-suggested method actually exists, you could also use javap against your installed identityiq.jar:

javap -public -classpath identityiq.jar sailpoint.object.Identity

I would suggest using the JavaDoc from your exact IIQ 8.4 build and checking the Rule’s <Signature> for available inputs, since JavaDoc alone may not cover everything. You could also instruct the assistant to verify method signatures rather than guess, and test the generated BeanShell in a non-production instance.

This might be a good starting point before investing time in an MCP or RAG setup.

4

Hello @IslamElkhouly ,

Building on the answers above, here’s are the setups that you can try. It adds a verification layer so you aren’t relying on the AI to read the docs correctly.

1. Create a compact API reference.

Use the JavaDoc from your exact IIQ 8.4 build for method descriptions, and use javap -public against your installed identityiq.jar to extract actual class and method signatures. Store the results in searchable text or Markdown files. This gives the AI a compact reference for verifying API usage. Raw JavaDoc HTML is noisy and token-heavy. Instead, generate a plain-text/Markdown API index from your exact 8.4 build: run javap -public over the key packages in identityiq.jar (sailpoint.object, sailpoint.api, sailpoint.tools, sailpoint.connector) and save the output as .txt or .md files. These are small, accurate signatures that fit easily in context. Keep the JavaDoc for the descriptions and behavior of the main classes (SailPointContext, Identity, Link, Bundle, ProvisioningPlan, QueryOptions, Filter).

2. Add project-specific instructions.

For Claude Code, a CLAUDE.md file can instruct the assistant to target your specific IIQ version, verify SailPoint API signatures before using them, respect the Rule’s declared <Signature> inputs and return type, and flag anything it cannot verify. Apply equivalent project instructions in other coding assistants.In Claude Code, use a CLAUDE.md (Project instructions) with rules such as:

  • Target IIQ 8.4 and BeanShell (Java-like syntax, no generics or lambdas).
  • Only use classes and methods that appear in the provided API reference. If unsure, say so rather than guess.
  • Always use the Rule’s declared <Signature> inputs (context, log, identity, plan, etc.) and never invent variables.
  • Use context.getObjectByName(...), Filter/QueryOptions, and remember to context.decache() in loops.

3. Introduce validation and testing.

A lightweight script could check generated code against the API reference for common unsupported method calls. Treat this as a preliminary check rather than a complete BeanShell validator, since overloads, inheritance, and dynamic method resolution complicate static analysis. Test the resulting Rules in a non-production IIQ environment.

  • Script a check that extracts method calls from generated code and verifies them against the javap output.
  • Optionally compile the logic as plain Java against identityiq.jar on the classpath as a quick sanity check before pasting into a Rule (BeanShell is more forgiving, so this catches bad signatures).
  • Always test in a non-production instance, and use the console (iiq console) to run rule / checkRule-style tests on small data sets.

4. MCP/RAG is optional.
If you want something reusable across tools, a small MCP server that exposes “search class” and “get method signatures” over the javap index is realistic and works with Claude (and any MCP-capable client). But with a compact API index plus a good instruction file, most teams get 90% of the benefit without it.

The key point is that JavaDoc tells the AI what should exist, and javap against your jar proves what does exist in your version.