PEGA — Fundamentos, Arquitectura, Case Management, Reglas, UI, Decisioning, Integraciones, Seguridad y DevOps

Q1. ¿Qué es Pega y para qué tipo de soluciones se usa?

Pega (Pegasystems, fundada en 1983) es una plataforma enterprise low-code para la gestión de casos (case management), la automatización de workflows, el decisioning y la IA. Sobre Pega Platform se construyen aplicaciones de back-office (créditos, siniestros, onboarding, disputas), servicio al cliente (Pega Customer Service), marketing 1:1 (Customer Decision Hub) y gobierno digital. Es especialmente fuerte en sectores como banca, seguros, salud, telecomunicaciones y sector público, donde hay procesos complejos, regulados y de alto volumen.

Q2. ¿Qué es BPM y cómo se relaciona con case management?

BPM (Business Process Management) es la disciplina de modelar, ejecutar y mejorar procesos de negocio. El case management va más allá: gestiona un caso (una unidad de trabajo con datos, ciclo de vida, reglas y partes interesadas) que puede evolucionar de forma semiestructurada, con etapas y decisiones que cambian según el contexto. Pega combina ambos: los procesos se ejecutan dentro de casos, y el motor de reglas decide el comportamiento dinámicamente según datos y circunstancias, en lugar de un flujo rígido predefinido.

Q3. ¿Cómo se diferencia Pega de otras plataformas (Appian, Camunda, ServiceNow, Salesforce)?

• Pega: motor de reglas con Rule Resolution, case management nativo, decisioning 1:1 (CDH), IA y RPA en una sola plataforma; fuerte en procesos complejos de back-office con reglas de negocio cambiantes.
• Camunda: motor BPMN, orientado a flujos modelados y orquestación de servicios; menos enfocado en UI low-code y decisioning.
• Appian: low-code similar; case management y automatización, sin el decisioning de CDH.
• ServiceNow: centrado en ITSM y workflows de servicio; Salesforce: centrado en CRM.

Q4. ¿Qué versiones existen y cómo se nombran?

Históricamente: PRPC (PegaRULES Process Commander) hasta 7.x, luego Pega Platform 7.x y 8.x (8.1–8.8). Desde 2023 el naming es por año: Pega Platform '23, '24.1, '24.2, '25.x, dentro de la suite Pega Infinity. Pega Cloud aplica patches periódicos de forma gestionada y versiones mayores aproximadamente anuales con ventanas de upgrade planificadas; en on-premise el cliente planifica sus propias actualizaciones.

Q5. ¿Qué es Pega Cloud y qué alternativas de despliegue hay?

Pega Cloud es el modelo SaaS gestionado por Pega (infraestructura en nubes públicas como AWS), donde Pega administra plataforma, parches, escalado y respaldo. Alternativas: instalación on-premise tradicional, contenedores con Kubernetes (Pega provee charts/operadores para despliegues containerizados) y las ediciones para gobierno (Pega Government Cloud, con regiones y requisitos específicos). La elección depende de regulación, residencia de datos y capacidades del equipo de operación.

Q6. ¿Qué roles se distinguen en un proyecto Pega?

Business Architect (diseño funcional y microjourneys), System Architect (CSA), Senior System Architect (SSA/CSSA), Lead System Architect (LSA/CLSA), Decisioning Consultant (CDH), desarrollador RPA y perfiles de administración/DevOps. Certificaciones típicas: Certified Pega Business Architect (CPBA), Certified System Architect (CSA), Certified Senior System Architect (CSSA), Certified Lead System Architect (CLSA) y Certified Pega Decisioning Consultant.

Q7. ¿Cuál es el ciclo de vida de desarrollo en Pega?

Diseño (workshops estilo Design Thinking, "Center-out", Pega Express con fases Discover–Build–Adopt) → construcción en App Studio/Dev Studio (con ramas por equipo) → pruebas (unit tests, scenario tests, regresión) → despliegue por pipelines (Deployment Manager) → operación y mejora (Admin Studio, PDC, monitoreo). Pega Express enfatiza personas, microjourneys y entregas incrementales sobre la plataforma.

Q8. ¿Qué es un microjourney y el enfoque "center-out"?

Un microjourney es un recorrido de valor de inicio a fin desde la perspectiva del cliente o usuario (por ejemplo: "resolver una disputa de tarjeta" o "aprobar un crédito"), y se implementa como un case type. El enfoque center-out diseña desde la intención del cliente hacia adentro (personas, microjourneys y luego procesos internos), en lugar de partir de la estructura organizacional. Es la base metodológica de Pega Express y del Blueprint generado con GenAI.

Q9. ¿Qué es el motor PegaRULES?

Es el motor (Java) que interpreta y ejecuta las reglas almacenadas en la base de datos: proceso, UI, integraciones, seguridad y decisioning son reglas resueltas en tiempo de ejecución mediante el algoritmo de Rule Resolution. Los desarrolladores configuran reglas (no compilan código, aunque se pueden escribir pasos Java), lo que permite cambiar comportamiento sin re-desplegar la aplicación. El motor mantiene caché de reglas en cada nodo para ejecutarlas con baja latencia.

Q10. ¿Cómo se estructura la arquitectura de nodos?

Pega corre como un clúster de nodos (JVMs) que comparten base de datos: nodos de interacción de usuario (web), nodos de procesamiento en background (agentes, queue processors, jobs) y nodos de streaming (para decisioning en tiempo real). En Pega Cloud esta topología es gestionada; en on-premise se diseñan tipos y cantidad de nodos según carga. El estado de sesión (clipboard) vive en memoria por nodo, y la persistencia en la base de datos.

Q11. ¿Cuál es el stack tecnológico?

Java (JVM) como plataforma de ejecución; base de datos relacional (PostgreSQL en Pega Cloud; en on-premise se soportan Oracle, SQL Server, PostgreSQL, entre otras); servidores de aplicaciones Java (Tomcat en cloud; WebLogic, WebSphere o Tomcat en on-premise); servicios de streaming (Kafka) para decisioning en tiempo real; APIs REST para integración; y componentes web modernos en el cliente (Constellation).

Q12. ¿Qué entornos se manejan y cómo se promueve el código?

Típicamente desarrollo → QA/Staging → producción, cada uno como instalación/clúster independiente. Las reglas se promueven empaquetadas (productos/RAP o versiones de aplicación) vía pipelines de Deployment Manager; nunca se copia la base de datos de producción hacia desarrollo (solo refrescos controlados de entornos no productivos desde datos anonimizados cuando el proceso lo permite).

Q13. ¿Qué son las capas enterprise e implementation y los frameworks?

Pega organiza las reglas en capas: el enterprise layer contiene reglas reutilizables para toda la organización (estructura Org-, utilidades, data types comunes); el implementation layer contiene la aplicación específica del negocio. Sobre esa base se extienden los frameworks de producto (Customer Service, Government, etc.), que aportan reglas estándar que la implementación hereda y especializa sin modificarlas (extensión por herencia, no por edición).

Q14. ¿Cómo se organiza una aplicación Pega?

La regla Application define el nombre, la versión, el ruleset stack (lista ordenada de rulesets) y las aplicaciones base (built-on). Dentro se definen case types, data types, clases, portals, access groups y las divisiones/unidades organizacionales (Org-). Los usuarios se representan con Operator IDs ligados a access groups, workgroups y reglas de seguridad.

Q15. ¿Cómo se logra escalabilidad y alta disponibilidad?

Con escalado horizontal de nodos (más nodos web o de background según la carga), escalado de la base de datos, balanceadores de carga y despliegue multi-zona. Pega Cloud gestiona esta elasticidad y la HA; en on-premise se dimensiona según volumetría, se separan nodos por tipo de trabajo y se monitorea con PDC/alerts. El decisioning en tiempo real escala con servicios de streaming dedicados.

Q16. ¿Qué son los requestors y threads?

Un requestor representa una sesión de trabajo (usuario en navegador, servicio REST, batch, aplicación); un thread es una unidad de ejecución dentro del requestor con su propio ámbito de clipboard. Las páginas de nivel requestor se comparten entre threads y persisten durante la sesión; las de nivel thread se crean y liberan por operación. Entender esto es clave para performance: el tamaño y la cantidad de páginas afectan memoria y velocidad.

Q17. ¿Qué es un case type y cómo se estructura?

Un case type (clase Work-) define un tipo de trabajo: su modelo de datos (data types y propiedades), su ciclo de vida (stages y steps), SLA, estados, seguridad y experiencia de usuario. Se diseña en el Case Designer de App Studio. Ejemplos: "Disputa", "Solicitud de crédito", "Onboarding de cliente", "Siniestro".

Q18. ¿Qué son las etapas, pasos y procesos?

Las stages son las fases del caso (por ejemplo: Intake, Review, Approve, Resolve); dentro de cada stage hay steps, que pueden ser procesos automatizados (data transforms, integraciones, decisiones) o assignments (tareas de usuario con formularios). Las transiciones entre etapas pueden ser automáticas o manuales, y en versiones recientes existen etapas alternativas para rework o excepciones. El resultado: un ciclo de vida visual y gobernable.

Q19. ¿Cómo funcionan los estados, la urgencia y los SLA?

Cada caso tiene un estado (New, Open, Pending, Resolved-…) visible como pyStatusWork. La urgencia (pxUrgencyWork) prioriza el trabajo y sube con incrementos configurables. Los SLA definen goal, deadline y passed deadline con acciones en cada umbral: incrementar urgencia, reassignar, notificar o ejecutar automatizaciones. Así se garantiza que los casos críticos no se queden atrás.

Q20. ¿Cómo funciona el routing de assignments?

Los assignments pueden rutearse a un usuario, a una worklist (lista personal), a una workbasket (cola compartida) o resolverse con reglas de skills/routing (por ejemplo, asignar al grupo con la habilidad requerida). Las workbaskets se asocian a workgroups. El "Get Next Work" permite que el usuario tome el siguiente trabajo disponible según reglas. También existen SLA a nivel de assignment.

Q21. ¿Qué son los child cases (add work y spin-off)?

Un caso puede crear casos hijos para dividir trabajo: Add work crea un hijo que forma parte del ciclo del padre (el padre espera a que se resuelva dentro de su flujo), útil para tareas encapsuladas; Spin-off crea un hijo con ciclo de vida independiente (por ejemplo, gestionar una disputa mientras el pedido sigue su curso). El diseño correcto de dependencias evita bloqueos y permite paralelismo.

Q22. ¿Cómo se manejan el locking y la persistencia de los casos?

Pega aplica bloqueo optimista: al guardar se detectan conflictos si otro proceso modificó el caso. La apertura del caso en la UI y ciertas operaciones requieren lock; los procesos batch pueden operar sin lock para alto volumen. La persistencia se hace con métodos Obj-Save (o "Save" en flows), y las actualizaciones masivas se realizan con cuidado para no pisar datos. El diseño de concurrencia es parte del modelado del caso.

Q23. ¿Qué son las correspondencias y los adjuntos?

Las correspondence rules generan comunicaciones (email, cartas, PDF) combinando texto con propiedades del caso; pueden incluir fragmentos reutilizables y ser multimodales. Los attachments se clasifican por categoría, tienen control de seguridad y se asocian al caso; la generación de PDF es nativa. Todo esto permite gestionar la comunicación con el cliente dentro del propio caso.

Q24. ¿Qué son las work parties y cómo se gobiernan los casos a escala?

Las work parties son los roles asociados al caso (cliente, owner, partes interesadas) y determinan quién ve y quién actúa. A escala se gobiernan con: procesos masivos (bulk actions), archiving y purga de casos antiguos (data management), reportes y monitorización por estado/etapa, y reglas de negocio que mantengan los casos consistentes. Buena gobernanza = volumen controlado + trazabilidad.

Q25. ¿Qué son las clases y cómo se organiza la jerarquía estándar?

Las clases definen la estructura (propiedades) y el comportamiento (reglas) de los datos. La biblioteca estándar incluye: @baseclass (raíz), Work- (casos), Data- (datos de referencia como Data-Party o Data-Customer), Org- (estructura organizacional), Embed- (páginas embebidas reutilizables), History-, Rule- (las reglas mismas) y Code- (page lists estándar como Code-Pega-List). Las clases pueden ser abstractas (no instanciables) o concretas; las Work- concretas son los case types.

Q26. ¿Qué diferencia hay entre pattern inheritance y directed inheritance?

• Pattern inheritance: herencia por nombre. "Work-Loan-CarLoan" hereda de "Work-Loan" y ésta de "Work-", siguiendo los prefijos del nombre de clase.
• Directed inheritance: herencia explícita hacia otra clase que no necesariamente comparte el prefijo (por ejemplo, una clase de implementación que hereda del framework, o reglas estándar que heredan de @baseclass).

Q27. ¿Qué son las properties?

Son los atributos de una clase: texto, número, fecha, booleano, páginas (page), listas de páginas (page list) y page groups, entre otros modos. Cada property tiene su regla (etiqueta, tipo, validación, valores). Las propiedades del sistema usan prefijos reservados: py (estándar de negocio, como pyID o pyStatusWork) y px (internas de plataforma). Nombrar bien las propiedades y reutilizarlas es parte de las buenas prácticas.

Q28. ¿Qué es el clipboard y por qué importa?

El clipboard es la memoria de trabajo de una sesión: contiene las páginas de datos (pyWorkPage con el caso activo, páginas de requestor compartidas, páginas de thread y data pages). Los desarrolladores lo inspeccionan con la herramienta Clipboard en Dev Studio. Importa para performance: un clipboard enorme (páginas innecesarias, page lists gigantes) degrada memoria y velocidad; limpiar y acotar páginas es una práctica clave.

Q29. ¿Qué son las data pages?

Son mecanismos declarativos para cargar y cachear datos: se define la página (estructura y parámetros), su scope (thread, requestor o node) y su fuente (data transform, activity, conector REST, report definition, entre otras). Con estrategias de refresco ("reload if older than", refresco bajo demanda) permiten desacoplar la UI y los procesos del origen de datos, mejorar performance por caché y estandarizar integraciones. Son una pieza central del diseño en Pega.

Q30. ¿Qué son los data types y los data transforms?

Los data types modelan datos de referencia (clientes, productos, catálogos) con sus campos y fuentes de datos (REST, base de datos, archivos, manuales). Los data transforms son reglas que mapean y actualizan propiedades de forma declarativa (set, append, mapeo de entrada); reemplazan a las activities para asignaciones simples y son preferidas por su claridad, reutilización y cumplimiento de guardrails.

Q31. ¿Cómo se guardan y consultan los datos de negocio?

Los casos se persisten en tablas de la base de datos Pega (estructura generada por la plataforma) mediante métodos Obj-Save/Obj-Open y las operaciones del motor. Para consultas de negocio se usan report definitions (reportes sobre la BD con filtros y columnas, base de Report Browser y de dashboards), data pages con report definition como fuente, y herramientas de análisis. Para volúmenes históricos se aplican archiving y purga con jobs programados.

Q32. ¿Qué buenas prácticas aplican al modelo de datos?

Separar claramente Work- (casos) de Data- (referencia); reutilizar data types del enterprise layer; evitar propiedades duplicadas o ad-hoc en clases de UI; nombrar consistentemente (prefijos por proyecto, sin tocar py/px); modelar páginas y page lists con la cardinalidad real; y revisar el impacto de cada propiedad en reportes, indexación y purga. Un modelo limpio reduce deuda técnica y mejora performance.

Q33. ¿Qué es una regla y cómo se identifica?

Una regla es la unidad de comportamiento o configuración del sistema (proceso, UI, decisión, integración, seguridad, datos). Se identifica por su clave: tipo de regla + nombre + clase "applies to" (más parámetros en algunos tipos). Las reglas se almacenan en la base de datos, viven en rulesets versionados y se resuelven en runtime: en Pega se "configura", no se "programa" el core.

Q34. ¿Qué es el Rule Resolution y cuál es su orden de prioridad?

Es el algoritmo que determina cuál regla aplica. Ante varias candidatas con la misma clave, decide por:

1. Jerarquía de clases: búsqueda por pattern inheritance y directed inheritance desde la clase de la regla hacia arriba.
2. Orden del ruleset stack de la aplicación (el orden define quién tiene prioridad).
3. Circumstances: una regla circunstanciada (condicionada por valores de propiedades) gana sobre la versión base.
4. Disponibilidad (availability): Yes, No, Blocked, Final o Withdrawn, según se quiera forzar o bloquear herencia.
5. Versión del ruleset: gana la versión más alta.

Q35. ¿Qué son los rulesets y cómo se versionan?

Un ruleset es un contenedor versionado de reglas (formato mayor-menor-patch, por ejemplo 01-01-01). El ruleset stack de la aplicación es la lista ordenada que participa en la resolución. Una versión de ruleset puede bloquearse para edits y entonces se crea la siguiente versión; los cambios se empaquetan por ruleset para despliegue. Los rulesets también pueden declarar prerequisitos y se asocian a la Application rule.

Q36. ¿Qué son las activities y cuándo usarlas?

Son reglas procedurales de bajo nivel: secuencias de steps con métodos (Page-New, Property-Set, Obj-Open, Apply-DataTransform, Connect-REST, Route, Queue-For-Processing, etc.), modos de iteración sobre page lists, condiciones (when), parámetros y manejo de error (StepStatusFail). Siguen siendo útiles para lógica compleja o integraciones, pero los guardrails desaconsejan abusar de ellas (y de pasos Java); para asignaciones simples se prefieren data transforms, decisiones y reglas declarativas.

Q37. ¿Qué son las reglas de decisión (when, decision table, decision tree, map value)?

• When: condición booleana reutilizable (por ejemplo, "cliente VIP").
• Decision Table: matriz de condiciones y resultados (evaluaciones por filas con "otherwise").
• Decision Tree: árbol de ramas con evaluaciones jerárquicas.
• Map Value: mapeo de valores exactos o rangos (por ejemplo, score a categoría).

Q38. ¿Qué son las reglas declarativas (expression, constraint, onchange, trigger)?

• Declare Expression: calcula un target automáticamente cuando cambian sus fuentes (forward chaining) o al acceder a él (backward chaining).
• Declare Constraint: regla de integridad que se aplica al guardar; puede forzar o impedir la persistencia.
• Declare OnChange: dispara lógica cuando cambia una propiedad específica.
• Declare Trigger: reacciona a eventos de instancias de una clase (crear, guardar, borrar) — usado con cuidado por su impacto.
• Declare Index: mantiene índices auxiliares para reportes de relaciones complejas.

Q39. ¿Cómo se implementan las validaciones?

Con reglas Validate (validaciones de negocio que se ejecutan al enviar formularios o ejecutar acciones, mostrando mensajes al usuario), Edit Validate (validaciones de formato a nivel de campo), métodos Obj-Validate en activities, propiedades requeridas y constraints declarativas. La regla de oro: validar en el punto más cercano al usuario, con mensajes claros, y no duplicar la misma validación en múltiples capas.

Q40. ¿Qué son los guardrails y cómo se usan?

Los guardrails son las buenas prácticas de Pega codificadas como advertencias en Dev Studio, con un Compliance Score por aplicación. Ejemplos de hallazgos típicos: abuso de activities o pasos Java, uso de Connect-SQL en lugar de data pages, modificar reglas estándar (en vez de especializarlas por herencia), entre otros. Mantener el score alto reduce riesgo de upgrade y problemas de performance; el despliegue serio incluye los guardrails como calidad de entrada.

Q41. ¿Qué diferencia hay entre App Studio, Dev Studio y Admin Studio?

• App Studio: entorno principal para negocio y arquitectos: case types, data types, vistas, escenarios, Blueprint. Genera las reglas subyacentes.
• Dev Studio: entorno completo de desarrollo: todas las reglas, depuración (Tracer, Clipboard), integraciones avanzadas, seguridad.
• Admin Studio: salud y operación del sistema (alertas, monitoring, gestión operativa).
• Prediction Studio: ciclo de vida de modelos de IA/decisioning.

Q42. ¿Cómo funciona la UI tradicional (sections, harnesses, flow actions)?

En la UI clásica, las sections definen la disposición de campos en cada área, los harnesses son los contenedores de página (perform, new, confirm) y las flow actions gobiernan la interacción dentro de un assignment (confirmar, recopilar datos, aprobar). El estilo se controla con themes (Theme Cosmos en 8.x) y skins; los portales se construyen en Dev Studio. Es el modelo que sigue vigente en muchas aplicaciones existentes.

Q43. ¿Qué es Constellation?

Constellation es la arquitectura de UI moderna de Pega: una interfaz server-driven donde las vistas (views) se definen en App Studio y el front-end (basado en componentes de la Digital Experience — DX API y librería React de Pega) las renderiza consumiendo datos del motor vía API. No se editan harnesses/sections tradicionales; la experiencia es consistente (SPA) y optimizada para apps nuevas en Pega Cloud, con menor costo de mantenimiento de UI.

Q44. ¿Cómo se personaliza la experiencia en Constellation?

Organizando views por contexto (formularios, listas, resúmenes), con reglas de visibilidad y comportamiento por etapa/estado; configurando landing pages y navegación; aplicando temas y branding consistentes; y extendiendo con componentes DX personalizados solo cuando la librería estándar no cubre el caso. La personalización se gobierna en App Studio sobre el modelo de caso, no sobre HTML/CSS ad-hoc.

Q45. ¿Qué canales y portales soporta Pega?

Portales web responsivos, aplicaciones móviles (Pega Mobile), email (con Email Bots y correspondencia), y mashups/web embeds (Pega Web Mashup) para integrar la experiencia Pega dentro de aplicaciones externas. La omnicanalidad consiste en que el mismo caso se gestiona desde cualquier canal, manteniendo datos, reglas y trazabilidad únicos.

Q46. ¿Cómo se manejan idioma y localización?

Con reglas de localización de textos (field value/localization rules), reglas de Locale para formatos de número, fecha y zona horaria, y variantes de UI/correspondencia por idioma. La estrategia habitual es centralizar los literales y evitar texto embebido en reglas. Para portales multi-país se definen locales por operador o por contexto del caso.

Q47. ¿Qué buenas prácticas aplican a la UI en Pega?

Reutilizar secciones/views en lugar de duplicar; diseñar formularios por tarea (no formularios monolíticos); cargar datos bajo demanda (data pages con scope correcto) para no inflar el clipboard; cuidar accesibilidad y consistencia visual; y validar la experiencia en el canal real (desktop, móvil). En Constellation, evitar "luchar contra el framework": extenderlo de forma soportada.

Q48. ¿Qué es Pega Customer Decision Hub (CDH)?

Es el motor de decisión 1:1 de Pega para marketing y servicio: determina la mejor acción para cada cliente (next-best-action) en tiempo real o batch, combinando políticas de negocio, estrategias y modelos analíticos. Se usa en inbound (web, call center) y outbound (email, SMS, push) para personalización consistente y gobernable, con control de contacto y priorización.

Q49. ¿Cuáles son los conceptos centrales del decisioning?

• Acción y tratamiento: qué se ofrece (propuesta) y cómo se presenta.
• Jerarquía Issue/Group/Action: organización del portafolio de ofertas.
• Estrategias: canvas de filtros, priorización y arbitraje que deciden qué acción gana.
• Modelos predictivos y adaptativos: propensity scores que aprenden del comportamiento.
• Políticas de contacto (engagement policies): límites de frecuencia, supresión y elegibilidad.

Q50. ¿Cómo se integran las decisiones en tiempo real?

A través de APIs de decisión invocadas desde canales digitales, contenedores en línea dentro de las aplicaciones y servicios de streaming que alimentan los eventos de interacción (comportamiento del cliente). Los modelos adaptativos aprenden de esos eventos de forma continua. El objetivo: decisión en milisegundos con datos frescos del cliente, respetando las políticas de contacto.

Q51. ¿Qué es Pega Process AI y el Email Bot?

Process AI aplica IA a la operación de procesos: clasificación y categorización de trabajo entrante, análisis de texto (intenciones, entidades), enrutamiento inteligente y sugerencias para el agente. El Email Bot es el caso emblemático: procesa correos entrantes, entiende la intención (NLP), crea o actualiza casos, responde automáticamente o escala a un humano. Reduce trabajo manual de triage y acelera la atención.

Q52. ¿Qué capacidades GenAI aporta Pega?

Pega GenAI integra modelos de lenguaje para: Blueprint (describir una aplicación en lenguaje natural y generar el diseño con personas, microjourneys y case types base), generación y sugerencia de configuración en App Studio, borradores de respuestas y resúmenes de casos en servicio al cliente, y asistencia guiada. Los proveedores de LLM se configuran mediante reglas de conexión, con opciones de despliegue según las políticas de datos de la organización.

Q53. ¿Qué es Pega RPA y cuándo se usa?

Pega Robotic Process Automation automatiza interacciones con aplicaciones (incluidas las que no tienen API), mediante robots construidos en Robot Studio y administrados a escala con Robot Manager. Robots attended asisten al usuario; los unattended ejecutan procesos completos. Se integran con los casos Pega para cubrir pasos sin interfaz programática (sistemas legacy, terminales, escritorios), y son una alternativa puente mientras se logra una integración por API.

Q54. ¿Qué mecanismos de procesamiento en background existen?

• Job Scheduler: trabajos programados (cron-like) para tareas periódicas.
• Queue Processors: procesamiento asíncrono desde colas, con paralelismo configurable; los procesos encolan trabajo (Queue-For-Processing) y siguen sin esperar.
• Agentes estándar: mecanismo clásico por intervalos; en diseños nuevos se prefieren schedulers y queue processors.

Q55. ¿Cómo se gobiernan los modelos de IA/decisioning?

Con Prediction Studio: creación y revisión de modelos, monitoreo de performance (métricas de calidad, deriva), análisis de predictores y explicabilidad (reason codes), y control de versiones/promoción. Los modelos adaptativos aprenden continuamente bajo políticas definidas. La gobernanza incluye dueños de modelo, revisión periódica y trazabilidad de decisiones para cumplimiento y auditoría.

Q56. ¿Qué panorama de integración ofrece Pega?

• Connectors (Pega llama a sistemas externos): Connect-REST, Connect-SOAP, Connect-SQL, repositorios de archivos (SFTP), colas JMS/MQ.
• Services (sistemas externos llaman a Pega): Service-REST, Service-SOAP, Service-File, listeners de email.
• Data pages como patrón de acceso y caché de datos externos.
• Asincronía: Queue-For-Processing, queue processors, Kafka/stream para eventos.

Q57. ¿Cómo se construye una integración REST (connector)?

Se define el conector con endpoint, método HTTP, autenticación y opciones de conexión; se mapea la respuesta JSON a páginas del clipboard con data transforms (y la request desde propiedades); se especifica manejo de códigos de error/estado y timeouts. Buenas prácticas: encapsular el conector en una data page, simular respuestas (mock) para pruebas, y no invocar servicios externos lentos dentro de pasos interactivos sin asincronía.

Q58. ¿Cómo se exponen servicios desde Pega?

Con reglas Service-REST (endpoints REST con request/response JSON mapeados a propiedades), Service-SOAP (legacy) o listeners de archivos/email para intake. Los servicios se agrupan en service packages que definen métodos, clases y seguridad (qué access groups pueden usar cada método), y se consumen por sistemas externos para crear casos, consultar estado o disparar procesos. La autenticación típica es OAuth 2.0 o basic auth sobre HTTPS.

Q59. ¿Por qué las data pages son el patrón preferido de integración?

Porque separan el "qué datos necesito" del "cómo los obtengo": la UI y los procesos consumen la página, y la definición decide la fuente (REST, report, activity) y el scope de caché (thread/requestor/node) con su estrategia de refresco. Esto permite reutilizar, cachear, simular en pruebas y cambiar de implementación sin tocar a los consumidores. Cuidado con páginas demasiado grandes o scopes incorrectos: impactan memoria y frescura de datos.

Q60. ¿Qué opciones existen para archivos y procesamiento batch de datos?

Repositorios (SFTP/otros) para leer y escribir archivos; listeners de archivos para intake automático; data sets y data flows (CSV, JSON, tablas, Kafka) para mover datos de forma estructurada y masiva, muy usados en decisioning (customer data, interacciones); y el procesamiento por queue processors para integraciones pesadas. La elección depende del volumen, la frecuencia y el destino (casos, decisiones o análisis).

Q61. ¿Cómo se integra la mensajería asíncrona y los eventos?

Con colas JMS/IBM MQ (connectores y servicios), y con Kafka/streaming para eventos en tiempo real — clave en decisioning (interacciones del cliente) y en arquitecturas event-driven. El patrón recomendado para procesos: encolar (Queue-For-Processing) y dejar que un queue processor procese en background, con reintentos y monitoreo; así el canal no depende de la disponibilidad del sistema externo.

Q62. ¿Cómo se manejan los errores de integración?

Mapeando códigos de estado y errores del servicio a estados de negocio y mensajes accionables; definiendo reintentos con backoff y colas de trabajo fallido (broken queue) para reproceso; registrando detalles técnicos en logs y alertas; y diseñando idempotencia (claves de correlación, no duplicar casos/pagos) para poder reintentar con seguridad. El error de integración debe ser visible y gestionable por operación, no un log que nadie mira.

Q63. ¿Cómo se protegen las integraciones?

Con OAuth 2.0 (client credentials o authorization code) y certificados/TLS en los conectores; gestión de tokens con caché (por ejemplo, data page de token con refresco) y keystores para certificados; operadores de servicio dedicados con access groups de mínimo privilegio; y registros de auditoría del uso de servicios. Evitar credenciales embebidas en reglas o código: centralizar en reglas de conexión seguras y secretos gestionados.

Q64. ¿Cómo funciona el modelo de seguridad de Pega?

Combina autenticación (quién es el usuario: SAML, OIDC, LDAP) y autorización (qué puede hacer): RBAC con access groups, roles y AROs, más ABAC con access control policies; más la estructura organizacional (divisiones y unidades) que segmenta datos y trabajo. Los usuarios son Operator IDs; los servicios usan operadores dedicados. La seguridad se diseña junto con el modelo de caso, no después.

Q65. ¿Qué son los access groups, roles y AROs?

• Access Group: agrupa aplicación, roles, portal, workgroup y otros atributos; es lo que se asigna al operador.
• Access Role: conjunto de permisos que se otorga por clase mediante AROs.
• ARO (Access of Role to Object): define por clase y rol el nivel de acceso (Read, Write, Delete…) y los privileges (permisos especiales como aprobar, desembolsar, anular).

Q66. ¿Qué es ABAC y para qué sirven las access control policies?

El control de acceso basado en atributos condiciona permisos según atributos del operador y del caso (por ejemplo, que el usuario solo acceda a casos de su región o de su nivel de aprobación). Se implementa con Access Control Policies: condiciones evaluadas en runtime que restringen el acceso otorgado por los roles cuando el contexto no cumple la política. Es la herramienta para reglas de seguridad finas (territorio, límite de monto, confidencialidad) sin multiplicar roles.

Q67. ¿Qué opciones de autenticación y SSO existen?

SAML 2.0 y OpenID Connect para SSO con el IdP corporativo (con MFA gestionado en el IdP), LDAP/Active Directory en instalaciones on-premise, y autenticación personalizada para casos específicos. Para servicios se usan OAuth 2.0/client credentials. Se configuran timeouts de sesión, políticas de contraseña (cuando aplica autenticación local) y se recomienda forzar HTTPS y cabeceras seguras.

Q68. ¿Cómo se gestionan operadores y la estructura organizacional?

Los Operator IDs representan usuarios (con access group, workgroup y divisiones/unidades); los workgroups/workbaskets gobiernan routing y pertenencia; y la jerarquía Org- (división, unidad) segmenta datos y visibilidad. La gestión del ciclo de vida (altas, bajas, cambios de rol) debe estar integrada con RR. HH. y revisarse periódicamente; operadores de servicio (integración) se tratan aparte con permisos mínimos.

Q69. ¿Qué mecanismos de auditoría y trazabilidad existen?

Las History classes (History-) registran cambios de instancias auditadas; los casos tienen su historial visible (etapas, asignaciones, cambios de estado); las reglas y su resolución quedan versionadas por ruleset; y los logs de seguridad/autenticación dejan evidencia de accesos. Para cumplimiento se combinan auditoría técnica (plataforma) con controles de proceso (quién aprobó qué y cuándo) y reportes de evidencia.

Q70. ¿Qué protecciones a nivel de plataforma aplican?

Cifrado en tránsito (TLS) y en reposo (gestionado en Pega Cloud); certificaciones de la nube de Pega (SOC 2, ISO 27001, entre otras); hardening mediante el Security Checklist de App Studio (revisar operadores de ejemplo, configuraciones por defecto inseguras, etc.); control de acceso por IP cuando aplica; y gestión de parches dentro del ciclo de upgrades. En on-premise, estas capas son responsabilidad del cliente sobre la infraestructura.

Q71. ¿Qué consideraciones de privacidad de datos aplican?

Clasificar y minimizar datos personales en el modelo (evitar copiar todo al clipboard); cifrar propiedades sensibles y restringir su visualización por rol; aplicar retención y purga (incluye archivos y adjuntos); gobernar el uso de datos en decisioning (consentimiento, políticas de contacto, tratamiento); y alinear con GDPR/leyes locales (derecho de acceso y borrado según el alcance de la plataforma). La privacidad se diseña en el modelo de caso y datos, no solo en la UI.

Q72. ¿Cómo se versionan y empaquetan las reglas?

Las reglas viven en rulesets versionados; los cambios se empaquetan con product rules (archivos RAP) o como versiones de aplicación (application packages), que se importan en el entorno destino o se despliegan por pipeline. Para parches puntuales se usan productos específicos con las reglas necesarias; para releases completos, la versión de la aplicación con su ruleset stack. Los hotfixes de plataforma provienen del catálogo de Pega y se aplican según el modelo (cloud gestionado u on-premise).

Q73. ¿Qué son las branches y cómo se trabaja en equipo?

Las branches permiten que varios desarrolladores trabajen en paralelo sobre las mismas reglas sin pisarse: cada equipo/feature abre una rama, desarrolla y luego se merge con revisión de diferencias regla por regla en Dev Studio. Buenas prácticas: ramas cortas, merges frecuentes, no ramificar reglas que no lo soportan (según guardrails) y mantener el ruleset destino actualizado antes de integrar.

Q74. ¿Qué es Deployment Manager y cómo funciona un pipeline?

Deployment Manager es la herramienta de CD de Pega: se define un pipeline (por ejemplo, Dev → QA → Prod) con etapas y tareas (desplegar, ejecutar pruebas, aprobar), incluidos quality gates automáticos (por ejemplo, ejecución de unit tests y cumplimiento de guardrails). Los candidatos son versiones de aplicación o productos; cada despliegue queda auditado. En Pega Cloud el orquestador es gestionado; para on-premise requiere componentes adicionales.

Q75. ¿Qué son los productos (RAP) y cuándo se usan?

La regla de product (Rule-Admin-Product) empaqueta un conjunto específico de reglas en un archivo RAP para moverlas entre entornos. Se usa para parches puntuales, migraciones de emergencia o distribución a otras instalaciones; para releases completos es preferible la versión de aplicación. Importar un producto en producción es una operación sensible: se prueba en un entorno previo y se documenta.

Q76. ¿Cómo se prueba una aplicación Pega?

Con unit tests de reglas (Pega unit testing, creados junto a la regla y ejecutables en pipelines), scenario tests de case types (App Studio) para validar rutas y resultados, pruebas funcionales/regresión por caso de uso, y pruebas de performance/carga sobre nodos y base de datos. Las pruebas de integración usan mocks/simulaciones de servicios externos. La automatización en el pipeline evita regresiones silenciosas entre sprints.

Q77. ¿Cómo se gestionan los entornos y la configuración por ambiente?

Cada entorno es una instalación independiente; los valores que cambian por entorno (URLs, credenciales, parámetros) se gestionan con Dynamic System Settings (DSS) y reglas de configuración, nunca hardcodeados. Los datos maestros de negocio se cargan por proceso controlado. Se evita promover datos entre entornos; se promueven reglas. Refrescos de datos (clones) solo con anonimización y autorización.

Q78. ¿Qué herramientas de administración y monitoreo hay?

Admin Studio (salud del sistema, alertas, revisión de configuración), PDC (Predictive Diagnostic Cloud) para monitoreo SaaS con métricas, alertas proactivas y diagnóstico basado en el historial de la plataforma, y en on-premise herramientas clásicas como el SMA (System Management Application) para nodos y agentes. El trabajo rutinario: revisar alertas, capacidad, colas y salud de nodos antes de que se conviertan en incidentes.

Q79. ¿Qué herramientas de diagnóstico existen?

• Tracer: ejecución paso a paso de actividades y procesamiento de casos (depuración funcional).
• Clipboard: inspección del estado de las páginas en memoria.
• PegaRULES log y Alert log: eventos y alertas del motor (excepciones, performance, patrones problemáticos).
• DB Trace: SQL ejecutado contra la base de datos (con cautela en producción).
• PAL (Performance Analyzer Logging): contadores por interacción para medir hotspots de performance.

Q80. ¿Qué buenas prácticas mejoran el rendimiento?

Mantener el clipboard pequeño (limpiar páginas, evitar page lists gigantes); usar data pages con scope y refresco correctos; preferir data transforms/report definitions sobre loops de Obj-* en activities; indexar y depurar la base de datos (incluye purga de históricos); cuidar las reglas circunstanciadas costosas; y aprovechar lazy loading en Constellation. Medir siempre con PAL/PDC antes de optimizar por intuición: el cuello de botella suele estar en DB o en tamaño de clipboard.

Q81. ¿Cómo se gestionan upgrades y mantenimiento de la plataforma?

En Pega Cloud, los upgrades (versiones mayores y patches) son gestionados, con notificación, ventana y recomendaciones de prueba previa; en on-premise el equipo planifica la instalación, los scripts de actualización de base de datos y las pruebas de regresión. En ambos casos: revisar guardrails/alertas de compatibilidad, probar en un entorno previo, planificar con negocio y tener rollback definido. Un plan de upgrades disciplinado es lo que mantiene la plataforma sana a largo plazo.