Procesamiento de ReportCaster

En esta sección:

Referencia:

La siguiente imagen muestra los componentes de ReportCaster y el procesamiento que tiene lugar cuando ReportCaster accede a un repositorio SQL para crear, ejecutar y distribuir un trabajo programado.

El servidor de distribución es una aplicación Java que gobierna el proceso de envío y distribución de un trabajo programado. El servidor de distribución puede instalarse en la misma plataforma que el servidor de informes y los componentes (residen en el servidor web o de aplicaciones), o en una plataforma diferente.

El servidor de informes procesa un pedido de trabajo programado, recupera los datos y devuelve el informe al servidor de distribución, que distribuye la salida. ReportCaster admite múltiples servidores de informes (especificados en la herramienta Configuración de ReportCaster) y un repositorio (especificado en la configuración del Cliente de la Consola de administración).

Al crear una programación de ReportCaster, una de las propiedades de la programación establecida por ReportCaster es la de próxima hora de ejecución (NEXTRUNTIME) de esa programación. El servidor de distribución de revisa las programaciones en el repositorio de que tengan una próxima hora de ejecución menor o igual a la hora actual. Una vez ejecutado el trabajo programado, el NEXTRUNTIME queda actualizado para la próxima vez que se ejecute la programación.


Principio de página

x
Referencia: Procesamiento de ReportCaster de un trabajo programado

Los pasos siguientes describen qué sucede cuando el servidor de distribución identifica una programación a ejecutar.

  1. El servidor de distribución da prioridad al trabajo programado con respecto al resto de programaciones encoladas en el servidor de distribución. Al crear una programación, existe un parámetro de prioridad en el que puede especificar un valor de prioridad del 1 (prioridad máxima) al 5 (prioridad mínima). El valor de prioridad predefinido es 3. La cola del servidor de distribución clasifica las tareas programados por prioridad y luego, por tiempo. Si durante un ciclo de programación, uno o varios trabajos siguen en la cola al iniciarse el próximo ciclo de programación, se restablece el orden de prioridad para incluir cualquier trabajo nuevo que entre a la cola.
  2. Cuando una sesión (hilo) del Servidor de informes está disponible, el Servidor de distribución recupera dinámicamente la información de programación, parámetro y alerta desde el Repositorio de WebFOCUS. El número de hilos simultáneos disponible para el envío de trabajos, se controla mediante el parámetro Máximo de hilos, en la herramienta Configuración de consola ReportCaster. Cada servidor de informes configurado en ReportCaster tiene su propia asignación de hilos. Además, los hilos pueden ser asignados para trabajos que no utilizan el Servidor de informes. El número máximo de hilos es el total de estas propiedades de hilo individual. Además, los informes (Procedimientos de servidor WF, Informes estándar y Mis informes) quedan empaquetados para su envío al sistema IBFS y posterior procesamiento de seguridad y configuración del Cliente WF. El sistema IBFS envía el trabajo programado al Servidor de informes.
  3. El trabajo programado de un usuario puede ser lo siguiente:
    • Procedimiento de servidor WF. Un -INCLUDE recupera el procedimiento (FEX). El procedimiento debe estar accesible desde la ruta de servidor del servidor de informes.
    • Managed Reporting. Llama al Cliente para obtener el procedimiento del Repositorio
    • URL. ReportCaster puede programar un URL desde cualquier servidor web y distribuir el contenido a destinatarios especificados.
    • Archivo. puede programar la distribución de archivos de contenido estático a los que puede acceder el servidor de distribución de ReportCaster. Por ejemplo, si quiere distribuir un documento de Microsoft® Word®, puede hacerlo especificando la ruta completamente cualificada y el nombre del archivo; por ejemplo, D:\salesforecast\regionalquota.doc.
    • FTP. ReportCaster puede programar la recuperación de un archivo de cualquier servidor FTP.

    El trabajo programado incluye información sobre la distribución, los valores de parámetros y las variables internas de ReportCaster (como el ID de la programación, el nombre del procedimiento de programación, procedimientos de pre- y posprocesamiento o el ID de usuario (ID de propietario) que ha programado el trabajo).

  4. Cuando el trabajo programado es un:
    • Procedimiento (Procedimiento de servidor WF o procedimiento de Managed Reporting). Los informes recuperados se empaquetan para envio a un servidor de informes. Cuando prepara y envía un trabajo programado para procedimientos de servidor WF o informes WebFOCUS (Managed Reporting), ReportCaster envía comandos al sistema IBFS para su envío al Servidor de informes. A continuación, el Analizador de recursos, que se usa para seguir y monitorizar las solicitudes enviadas al Servidor de informes y los recursos utilizados para crear el informe que se va a distribuir, recupera estos comandos con el objetivo de controlar los recursos empleados para crear el informe. El servidor de informes ejecuta el procedimiento, recupera los datos, crea el informe, y devuelve el informe al sistema IBFS, que lo devuelve al Servidor de distribución. A continuación, el Servidor de distribución procesa la información de distribución y distribuye el informe. Para solicitudes de gráfico, los datos se devuelven al servidor de distribución, que crea la imagen del gráfico y la distribuye.

      Nota: Para especificar que se ejecuten ciertos comandos antes que un trabajo programado, emplee la propiedad Perfil universal de la Consola de administración WebFOCUS. Para más información, consulte el manual Seguridad y administración de WebFOCUS.

    • URL. El Servidor de distribución envía el URL a un servidor web, que ejecuta el URL. De ahí, el contenido se devuelve al servidor de distribución, que lo distribuye.
    • Archivo. El servidor de distribución accede a las unidades interconectadas para recuperar el archivo y después distribuirlo.
    • FTP. El servidor de distribución accede a un servidor FTP, recupera la salida del informe y la distribuye.
  5. El Servidor de distribución distribuye la salida programada como mensaje de e-mail, mediante FTP o SFTP, a una impresora, como informe en una carpeta de Managed Reporting (repositorio WebFOCUS), o a la Biblioteca de informes. También puede distribuir la salida programada a una máquina de fax mediante un proveedor de e-mail a fax de terceros.

    Los Procedimientos de servidor WF y Managed Reporting admiten estallido, permitiéndole enviar partes de un informe a destinatarios específicos. Si distribuye un informe tabular de estallido, el valor de estallido se determina mediante el primer campo BY. Si distribuye un informe gráfico de estallido, el valor de estallido se determina mediante el segundo campo BY. La matriz interna determina automáticamente el valor de estallido. La matriz interna es un área de memoria que guarda cada valor de campo de base de datos, y calcula los valores mencionados en la solicitud TABLE o la solicitud GRAPH.

  6. Cuando el servidor de distribución ha distribuido la salida (o es incapaz de distribuirla), procesa la información de registro, y escribe la información del trabajo en las tablas de registro del repositorio de WebFOCUS.

    Nota: Se ha modificado el proceso de registro para que los mensajes queden escritos en el repositorio de WebFOCUS según vayan estando disponibles, en vez de procesarlos de forma simultánea al final de la programación. La información de registro de ReportCaster queda escrita en las tablas de registro según vaya avanzando la programación. Como resultado, puede ejecutar un informe de registro durante la ejecución de la programación para determinar el estado de ésta.

    Las condiciones de error en informes de registro aparecen en rojo y las advertencias, en naranja.

  7. Si se solicita una notificación, el servidor de distribución la envía por e-mail. El nombre del servidor de correo que procesa el e-mail de notificación aparece especificado en la propiedad Host de correo de notificación, en la herramienta Configuración. Si el servidor de correo está en blanco, utiliza el servidor predeterminado de correo, empleado para la distribución de programaciones de e-mail y especificado por el ajuste Host de correo de la herramienta Configuración de ReportCaster.

    Las condiciones de error ocurren para los registros de informe o notificación cuando:

    • Se devuelve un mensaje de error FOC al servidor de distribución.
    • No hay ningún informe por distribuir.
    • Ha ocurrido un error de comunicación con los servicios (E-mail, (S), FTP, impresora, Managed Reporting, Biblioteca de informes).

    Sugerencia: Le recomendamos utilizar servidores de correo diferentes para la notificación y distribución por e-mail. El uso de servidores de correo distintos garantiza la recepción de notificaciones, incluso si falla el servidor predeterminado de correo.



Ejemplo: Cómo ejecutar un trabajo programado

En este ejemplo, el servidor de distribución sondea la tabla BOTSCHED cada minuto, buscando trabajos programados. Sin embargo, observe que permite que los usuarios autorizados cambien el intervalo de sondeo del servidor de distribución, por medio de la propiedad Intervalo del lector de la herramienta Configuración de ReportCaster. Puede especificar un intervalo de 1 a 999999 minutos.

  1. A las 9:01 A.M., se programa un trabajo con fecha y hora inicial de hoy a las 12:00 P.M. y fecha y hora final de mañana a las 3:00 P.M. El trabajo está programado para que se ejecute cada dos horas.
  2. A las 9:02 A.M., el servidor de distribución lee todos los registros de la tabla BOTSCHED con un NEXTRUNTIME igual a la hora actual. El trabajo no es válido ya que su hora de comienzo es a las 12:00 P.M.
  3. El servidor de distribución sondea la tabla BOTSCHED cada minuto siguiente, buscando trabajos con un NEXTRUNTIME menor o igual a la hora actual.
  4. A las 12:00 P.M., el Servidor de distribución lee la tabla BOTSCHED. El trabajo es válido ya que NEXTRUNTIME es igual a la hora actual. El trabajo queda colocado en la cola del Servidor de distribución y el servidor de distribución actualiza su NEXTRUNTIME en dos horas, para que NEXTRUNTIME sea a las 2:00 P.M.
  5. El servidor de distribución sondea la tabla BOTSCHED cada minuto siguiente, buscando trabajos con un NEXTRUNTIME menor o igual a la hora actual.
  6. A las 2:00 P.M., el Servidor de distribución lee la tabla BOTSCHED. El trabajo es válido ya que NEXTRUNTIME es igual a la hora actual. El trabajo queda colocado en la cola del Servidor de distribución; el servidor actualiza su NEXTRUNTIME en dos horas, para que NEXTRUNTIME sea a las 4:00 P.M.
  7. Este proceso se repite. El trabajo se ejecutará cada dos horas hasta mañana a las 3:00 P.M. La última hora a la que se pondrá el trabajo en la cola de ejecución, es mañana a las 2:00 P.M.

Nota: Para más información sobre cómo recuperar trabajos colocados en la cola del servidor de distribución cuyo NEXTRUNTIME no se ha actualizado, consulte Recuperación. Para más consideraciones, consulte Consideraciones de huso horario y Consideraciones de cambio de hora.


Principio de página

x
Consideraciones de huso horario

Los usuarios en un huso horario diferente, que acceden de manera remota, deben programar trabajos utilizando el huso horario de la máquina en la que está ubicado el servidor de distribución de ReportCaster. A la hora de consultar programaciones de trabajos, la fecha y hora mostradas son las del huso horario del servidor de distribución.

ReportCaster utiliza la tecnología Java, que siempre se ajusta al cambio de hora sin importar la configuración de Windows®. Si está en un área que no observa el cambio de hora, los trabajos programados se ejecutarán a la hora correcta. Sin embargo, algunos de los archivos internos añadirán una hora al horario durante este periodo. Estos archivos incluyen lo siguiente:


Principio de página

x
Consideraciones de cambio de hora

Al tener en cuenta el efecto del cambio de hora (DST en sus siglas en inglés) para trabajos programados por ReportCaster, lo principal es recordar que el cambio de hora ocurre a la 1:59:59 A.M. Como resultado, el reloj muestra las 3 A.M. (cuando comienza DST) o la 1 A.M. (cuando termina DST).

No olvide que el intervalo de programación se mantiene igual, sin importar el cambio de hora. Esto se debe a que la hora de ejecución de la programación está basada en el tiempo transcurrido en vez de la hora que marca el reloj.

La tabla siguiente lista y describe el comportamiento previsto de los trabajos programados por ReportCaster cuando el cambio de hora está en vigor.

Intervalo

Descripción

Por ejemplo:

La programación está configurada para ejecutarse a una hora específica o ejecutarse cada día, semana, mes o año.

La programación se ejecuta a esa hora sin importar el cambio de hora.

Una programación a las 9:15 A.M. seguirá ejecutándose a las 9:15 A.M.

La programación está configurada para ejecutarse cada minuto u hora tras el inicio de DST.

La programación se adelanta 1 hora.

Una programación que se ejecuta cada 2 horas: 12:00 P.M., 2:00 A.M., 4:00 A.M.

Se ejecutará a las horas siguientes: 12:00 P.M., 3:00 A.M., 5:00 A.M., etc.

Esto ocurre porque a la 1:59:59 A.M. el reloj se adelanta a las 3:00 A.M.

La programación está configurada para ejecutarse cada minuto u hora tras el fin de DST.

La programación se retrasa 1 hora.

Una programación que se ejecuta cada 2 horas: 12:00 P.M., 2:00 A.M., 4:00 A.M.

Se ejecutará a las horas siguientes: 12:00 P.M., 1:00 A.M., 3:00 A.M., etc.

Esto ocurre porque a la 1:59:59 A.M. el reloj se retrasa a la 1:00 A.M.


WebFOCUS