BeanShell y conectores en SailPoint: el purgatorio del desarrollador de producción

Todo desarrollador de SailPoint IdentityIQ tiene una historia con BeanShell. La del punto y coma olvidado que tumbó una campaña de certificación. La de la regla de provisioning que devolvió null silenciosamente y concedió acceso a todo el mundo. La de depurar añadiendo System.out.println, re-desplegando y rezando.

BeanShell es la materia oscura de IIQ. Está en todas partes, mal entendido, y cuando se rompe, se rompe de formas difíciles de reproducir y aún más difíciles de explicar a un jefe que solo quiere saber por qué la certificación trimestral está atascada.

Este artículo cubre los patrones de BeanShell que realmente funcionan en producción, las trampas en las que he caído (más de una vez) y cómo escribir reglas que no vuelvan para atormentarte.

Qué es realmente BeanShell en IIQ

BeanShell es un lenguaje de scripting Java ligero que se ejecuta dentro de la JVM de IIQ. Tiene acceso a todas las clases de Java y al modelo de objetos completo de SailPoint.

El problema es que BeanShell no es Java. Es interpretado, tipado dinámicamente, y no tiene compilador que atrape tus errores.

Scoping de variables. Las variables dentro de un for son visibles fuera. Las de un if puede que no.

Manejo de null. null.equals(cualquier cosa) lanza excepción. "string".equals(null) devuelve false.

Coerción de tipos. String + int concatena. Pero List.add(int) puede autoboxear o fallar según el contexto.

Resolución de imports. Un typo en un import no falla al parsear — falla cuando esa línea se ejecuta, posiblemente días después.

Patrones de reglas que sobreviven en producción

Prefija todo con el paquete. Escribe sailpoint.object.Identity en lugar de importar sailpoint.object.*.

Valida las entradas al inicio. if (context == null) return null; no es programación defensiva — es supervivencia.

Loggea todo. Añade System.out.println en cada punto de decisión.

Envuelve todo en try-catch. Una excepción no manejada puede abortar todo el lote.

Prueba con datos reales. Las reglas se comportan diferente con nulls y colecciones vacías.

El infierno de los conectores personalizados

La regla BuildMap. El mensaje Build Rule must return a Map es la pregunta más frecuente en Stack Overflow. La causa casi siempre es un null o type mismatch.

ConnectorException. El error real está enterrado tres frames debajo. Activa DEBUG para sailpoint.connector antes de llamar a soporte.

Schema mismatch. IIQ cachea schemas agresivamente. Limpiar la caché y re-ejecutar aggregación es lo primero que probar.

Qué cambia en ISC

ISC no usa BeanShell. Usa un motor de reglas simplificado.

Lo bueno: las reglas no pueden tumbar toda la plataforma. Están sandboxed, con timeouts.

Lo malo: cualquier cosa compleja requiere un workaround.

Lo feo: migrar reglas BeanShell a ISC es manual. No hay conversor automático.

---

BeanShell en IIQ es una herramienta potente. La clave es la disciplina: valida todo, loggea todo, y nunca asumas que una regla funciona solo porque no lanzó una excepción.