Vinny Jiménez

Posted on Feb 13

Deja de hacer esperar a tus usuarios dominando APEX_AUTOMATION

#orclapex #plsql #arquitectura #performance

Lee este APEX Insights en Inglés.

Todos hemos estado ahí: un usuario hace clic en "Enviar" y el spinner de carga del
navegador se convierte en su único compañero durante los siguientes 20 segundos.
Ya sea generando un PDF de 50 páginas, sincronizando datos con un ERP externo vía
REST, o realizando cálculos por lotes complejos, bloquear la sesión del usuario
para tareas de larga duración es un Anti-patrón de Arquitectura.

En el desarrollo web moderno, los usuarios esperan interfaces de alto rendimiento
y no bloqueantes. En el mundo de Oracle APEX, eso significa dominar
APEX_AUTOMATION.

diseñado específicamente para el ciclo de vida de APEX. No es solo un
"ejecutor de trabajos"; es un motor de orquestación.

En este APEX Insights, pasamos del desarrollo "drag-and-drop" a una
arquitectura de rendimiento intencional.

El Pivote Arquitectónico: Bloqueante vs. No Bloqueante

El cambio fundamental que hace un Arquitecto Senior es pasar de
"Hacerlo ahora" a "Manejarlo eventualmente".

Cuando un proceso se ejecuta en primer plano (la sesión del usuario), consume una
de tus valiosas conexiones ORDS y obliga al usuario a esperar. Si esa conexión
agota el tiempo de espera (timeout), el usuario no sabe si el proceso terminó,
falló o si sigue ejecutándose como un "zombie" en el fondo.

Al delegar a APEX_AUTOMATION, desacoplas la Intención (el usuario queriendo
ejecutar una tarea) de la Ejecución (la base de datos ejecutándola).

El Motor: Entendiendo las Automatizaciones

Las automatizaciones nativas se definen declarativamente en Componentes
Compartidos > Automatizaciones. Constan de:

Tipo de Disparador (Trigger Type):
- Programado (Scheduled): Se ejecuta según un horario tipo cron (por ejemplo, "Cada hora").
- Bajo Demanda (On Demand): Solo se ejecuta cuando se llama explícitamente vía API.
Origen (Source): Una consulta SQL o función PL/SQL que identifica qué necesita ser procesado.
Acciones: Los bloques PL/SQL que se ejecutan una vez por cada fila en el origen (o una vez globalmente).

Patrones: Poll vs. Push

Hay dos formas principales de diseñar tu arquitectura de segundo plano:

1. El Patrón de Sondeo (Polling)

La automatización se ejecuta cada cierto tiempo, consulta una "Tabla de Cola"
(por ejemplo, SELECT * FROM task_queue WHERE status = 'PENDING'), y procesa
cualquier elemento nuevo.

Ideal para: Sistemas desacoplados donde múltiples procesos alimentan un único motor de segundo plano.

2. El Patrón Push (Asíncrono Inmediato)

Defines una automatización "Bajo Demanda". Cuando el usuario hace clic en un
botón, en lugar de ejecutar el código directamente, llamas a:

apex_automation.execute(
    p_static_id => 'HEAVY_DATA_PROCESS'
);

Ideal para: Reactividad directa de la UX donde quieres que el trabajo comience ahora, pero sin hacer esperar al usuario.

Implementación: Configurando para el Éxito

El Enfoque Ingenuo (Procesamiento en Primer Plano)

-- ❌ PELIGROSO: Bloquea la sesión del usuario, riesgo de timeouts
BEGIN
    -- Lógica pesada (por ejemplo, 30 segundos)
    heavy_processing_pkg.run_data_sync;

    apex_application.g_print_success_message := '¡Sincronización completa!';
END;

El Enfoque del Consultor (APEX_AUTOMATION)

Primero, define tu automatización en Componentes Compartidos con el ID estático
SYNC_ENGINE. Luego, dispárala de forma segura:

-- ✅ SEGURO: Ejecución asíncrona, retorno inmediato
BEGIN
    -- Podemos pasar contexto vía estado de sesión o una tabla de cola
    -- personalizada
    insert into app_job_queue (task_type, payload) 
    values ('DATA_SYNC', :P10_PAYLOAD);

    -- Disparar la automatización para que revise la cola
    apex_automation.execute(p_static_id => 'SYNC_ENGINE');

    apex_application.g_print_success_message := 
        'Sincronización iniciada en segundo plano.'
        || ' Revisa el log para ver el estado.';
END;

Monitoreo: El Dashboard del Arquitecto

Un trabajo en segundo plano es tan bueno como su visibilidad.
APEX_AUTOMATION proporciona vistas de log integradas que son esenciales para
el mantenimiento.

APEX_AUTOMATION_MSG_LOG: Mensajes detallados y errores.
APEX_AUTOMATION_LOG: Historial general de ejecución (Éxito/Fallo/Duración).

Un Arquitecto Senior construye un "Dashboard de Administración" interno para
monitorear estas vistas, asegurando que si un trabajo falla a las 3:00 AM, sea
detectado y corregido antes de que el negocio comience su día.

Buenas Prácticas para la Excelencia en Segundo Plano

Idempotencia: Asegúrate de que si un trabajo se ejecuta dos veces (por ejemplo, después de un reintento), no duplique el trabajo. Usa llaves únicas o verificaciones de estado.
Bind Variables: Incluso en sesiones de segundo plano, usa variables de vinculación para prevenir inyección SQL y permitir la estabilidad de los planes de ejecución.
Manejo de Errores: Envuelve las acciones en un bloque BEGIN...EXCEPTION para registrar errores específicos en una tabla personalizada o en el log de APEX.
Gestión de Transacciones: Recuerda que cada ejecución es su propia sesión. La lógica de COMMIT debe manejarse con cuidado dentro de las acciones PL/SQL.

Ejemplo de Idempotencia

Para asegurar que tu trabajo de segundo plano sea seguro de reintentar, utiliza
una verificación como esta:

Demo en Vivo: Ver para Creer

Para apreciar realmente el poder de APEX_AUTOMATION en este
APEX Insights, debes verlo en acción. Al usar un patrón asíncrono
inmediato, mostramos al
usuario un mensaje de éxito al instante mientras el servidor trabaja en el fondo.

Míralo en Acción

Instrucciones de Construcción

Si quieres probar esto antes de construirlo, revisa nuestro Demo en Vivo.

Si tienes un workspace en apex.oracle.com, sigue estos pasos:

Crea una Tabla de Log:

create table demo_job_log (
    id          number generated always as identity primary key,
    payload     varchar2(100),
    status      varchar2(20),
    created_at  timestamp default localtimestamp,
    finished_at timestamp
);

Define la Automatización:

Ve a Shared Components > Automations.
Nombre: Demo_Heavy_Process, Static ID: demo-async.
Trigger: On Demand.

Acción (PL/SQL):

begin
    -- Simular trabajo pesado
    dbms_session.sleep(10); 

    insert into demo_job_log (payload, status, finished_at)
    values ('Async Task Triggered', 'SUCCESS', localtimestamp);
end;

Crea la Página de Disparo:

Añade un Botón (ej. START_PROCESS).

Añade un Proceso de Página que se ejecute al hacer clic:

begin
    apex_automation.execute(p_static_id => 'demo-async');
    apex_application.g_print_success_message := '¡Automatización disparada!';
end;

Verificación: Haz clic en el botón. La página se recarga instantáneamente.

La fila aparecerá en demo_job_log tras los 10 segundos.

Conclusión

Dominar APEX_AUTOMATION es la marca distintiva de un Arquitecto Senior de
Oracle APEX. Eleva tus aplicaciones de simples herramientas CRUD a sistemas de
clase empresarial capaces de manejar operaciones complejas con elegancia y
confiabilidad.

Deja de hacer esperar a tus usuarios. Empieza a automatizar.

Pregunta para la comunidad: ¿Cómo manejas actualmente los procesos largos en
tus apps? ¿Sigues el enfoque ingenuo o ya diste el salto a las automatizaciones?
¡Hablemos en los comentarios!

🚀 Toma el Siguiente Paso

Demo en Vivo: Mira el patrón "Immediate Async" funcionando.
Revisa tu aplicación: Identifica procesos lentos y muévelos a una Automatización.
Suscríbete a APEX Insights: Recibe consejos avanzados directamente en tu email.
Comparte el Conocimiento: ¡Conéctate conmigo en LinkedIn para discutir tus desafíos!

☕ Agenda una Llamada |
💼 Conecta en LinkedIn |
🐦 Sigue en X

Referencias

💖 Apoya Mi Trabajo

Si encontraste este APEX Insights útil, ¡considera apoyar los esfuerzos de
código abierto de la comunidad de APEX!

GitHub Sponsors |
Buy Me a Coffee

DEV Community