Prácticas probadas de IBM Cognos: Enrutamiento por distribuidores en IBM Cognos 8 BI explicado

Tipo de documento: directiva; producto(s): IBM Cognos 8 BI; área de interés: infraestructura; versión: 1.0

Este breve documento explica los principales conceptos de los distribuidores de IBM Cognos 8 durante el enrutamiento de solicitudes.

Business Analytics Proven Practices Team, Business Analytics Proven Practices Team, IBM

Cognos Proven Practices Team (Equipo de prácticas probadas de Cognos)



28-07-2010

Introducción

Objetivo

Este documento tiene por objetivo complementar las guíasSecurity and Administration Guide (Guía de seguridad y administración)yArchitecture and Deployment Guide (Guía de arquitectura e implementación), que son parte de la documentación del producto IBM Cognos 8. Se explicará el concepto de enrutamiento por distribuidores, incluyendo el equilibrio de carga y el enrutamiento avanzado.

Aplicabilidad

Los conceptos descriptos en este documento se aplican a todas las versiones de IBM Cognos 8 BI.

Exclusiones y Excepciones

Este documento se limita al enrutamiento basado en distribuidores y no trata el enrutamiento de servicios. Se presupone que el lector está familiarizado con los conceptos descriptos en la Guía de arquitectura e implementación.


Enrutamiento en IBM Cognos 8

¿Por qué enrutar?

IBM Cognos 8 está basado en una arquitectura orientada a servicios (SOA, por sus siglas en inglés). Esto significa que el producto consta de un conjunto de servicios independientes que se comunican a través de SOAP en una red. Existen diversos servicios que implementan las diferentes características del producto. Cada uno de estos servicios sólo puede atender un cierto tipo de solicitud. Este es uno de los desafíos del enrutamiento en una SOA: enrutar una solicitud a un servicio que pueda atender este tipo de solicitud.

Otro desafío del enrutamiento en una SOA es el equilibrio de carga y/o la conmutación por error. En un sistema completo, puede haber múltiples instancias del mismo tipo de servicio. Y, al haber múltiples instancias, es posible que tenga lugar un equilibrio de carga (a cada instancia se le asigna un porcentaje configurable de las solicitudes de ese tipo) o una conmutación por error (las solicitudes de un cierto tipo de servicio son reenrutadas a una instancia activa debido al error de otra de las instancias).

El distribuidor

Ambos desafíos son abordados por un componente de software llamado distribuidor. Técnicamente, el distribuidor es un servlet que administra datos de entrada HTML y genera datos de salida HTML. En el caso de IBM Cognos 8, la carga de entrada y de salida será SOAP (XML a través de HTTP).

Cada distribuidor aloja un conjunto de servicios que están determinados por los componentes de sistema instalados en esta instancia de IBM Cognos 8. Los servicios están registrados en el distribuidor, y es el distribuidor el que los controla. Al mismo tiempo, el distribuidor "conoce" cuáles son las instancias de servicio que aloja y, por ende, qué tipo de solicitudes puede atender a nivel local.

Cuando se inicia un distribuidor, se registra en el Administrador de contenido (CM) activo, informa los servicios que aloja y obtiene de CM información sobre el sistema. Mediante este proceso, cada uno de los distribuidores puede "conoce" todos los otros distribuidores del sistema y los servicios que alojan.

Si bien un entorno simple de servidor único podría ser suficiente para realizar pruebas, por lo general, los sistemas de producción constan de variosnodos. Cada uno de estos nodos ejecuta un distribuidor con su propio conjunto de servicios registrados. La multiplicidad de nodos posibilita el equilibrio de carga y la conmutación por error. La arquitectura de IBM Cognos 8 efectúa esta implementación a través de un bus lógico que se ubica entre los distribuidores de cada nodo. En este bus lógico, las solicitudes pasan o son enrutadas entre los distribuidores de un sistema hasta llegar a una instancia de servicio específica registrada en uno de los distribuidores. Este proceso sirve para reconocer el equilibrio de carga y la disponibilidad del servicio, como se explicará más adelante.

Los clientes, a través de un explorador o programa SDK, envían solicitudes a un distribuidor para que las atienda. Los distribuidores de un determinado sistema se aseguran de que la solicitud sea enrutada a una instancia de servicio con el tipo de servicio correcto, que, a su vez, administra la solicitud y retransmite el resultado al cliente.

Consideraciones sobre los puntos de entrada

Como el distribuidor es un servlet, debe ser implementado en un contenedor de servlets o en un servidor de aplicaciones Java, lo que implica que estará ubicado en el nivel de aplicación de una arquitectura clásica de tres niveles. Se considera riesgoso exponer el nivel de aplicación a los usuarios finales; por lo tanto, suele ser una mejor práctica usar algún otro componente del nivel Web, como un servidor Web, para administrar la comunicación con los clientes externos.

En la arquitectura de IBM Cognos 8, este proceso es efectuado por la puerta de enlace de IBM Cognos 8, que existe en 6 implementaciones diferentes (CGI, MOD, MOD2, MOD2_2, ISAPI) y una implementación de servlets adicional. Las instalaciones típicas usan una o varias puertas de enlace que actúan como punto de entrada al sistema IBM Cognos 8. Sin embargo, lo único que hace el componente de puerta de enlace con la solicitud es retransmitirla al primer distribuidor disponible de su lista configurada de distribuidores. La puerta de enlace no enruta: es un vínculo estático que cambia únicamente cuando el distribuidor configurado no es accesible. Sólo en este caso la puerta de enlace intentará reenviar la solicitud al segundo distribuidor de la lista, y así sucesivamente. Hechas estas aclaraciones, el enrutamiento recién se inicia cuando una solicitud alcanza un distribuidor por primera vez. El primer distribuidor que recibe una solicitud se llama distribuidor FRONTAL. Esto es importante para determinados flujos de solicitudes relacionados con la autenticación (ver Apéndice A).

Sin embargo, técnicamente, no importa si es el punto de entrada es un distribuidor o una puerta de enlace. Esto es extraordinario porque significa que es posible usar características del servidor de aplicaciones tales como complementos de servidor Web que colocan en proxy las solicitudes recibidas en el nivel Web y las llevan al nivel de aplicación de la misma manera que la puerta de enlace de IBM Cognos 8.

En el resto del documento, no se hace ninguna diferenciación entre distribuidor y puerta de enlace; cuando fuera necesario, se hará referencia a un punto de entrada para simplificar las cosas.


Conceptos de enrutamiento

En la siguiente sección se explicarán los principales conceptos del enrutamiento en IBM Cognos 8.

Grupos de servidores

El primer concepto que se describirá es el de losgrupos de servidores.

Un grupo de servidores (SG) es un conjunto de distribuidores. Cada uno de los distribuidores es asignado a un solo grupo de servidores por vez.

De manera predeterminada, cuando se instala el sistema, no se define ningún valor degrupo de servidoresexplícito para los distribuidores. Esto los convierte automáticamente en miembros del"grupo de servidores predeterminado". Sin embargo, el administrador puede asignar un distribuidor a un SG explícitamente, especificando un valor de cadena para la propiedadServer Group (Grupo de servidores)del objeto del distribuidor en IBM Cognos Administration. Este valor define de manera implícita un nuevo grupo de servidores con ese nombre si no existe todavía. Si ya existe, agrega el distribuidor al grupo de servidores.

Figura 1: Distribuidor asignado al SG "Endor"
Figure 1 - Dispatcher which was assigned to SG

Los grupos de servidores son importantes porque definen el ámbito del equilibrio de carga y de la asignación de servicios en general. Cada vez que un distribuidor busca una instancia activa de un determinado servicio, el ámbito de esa búsqueda será el grupo de servidores en el que se encuentra. Un distribuidor nunca podrá enrutar solicitudes a servicios ajenos a su SG, siendo el servicio de Administrador de contenido la única excepción. Cada vez que los distribuidores consideren el equilibrio de carga, lo harán únicamente respecto de los servicios que estén dentro del mismo SG que el distribuidor. Estos son dos factores muy importantes para tener en cuenta.

Por último, los grupos de servidores constituyen un requisito previo para poder usar elenrutamiento avanzado, que se tratará más adelante.

Los grupos de servidores se almacenan en el almacén de contenido y sólo CM puede proporcionar información de la asignación de distribuidores a un grupo de servidores. Se administran implícitamente suministrando los valores al grupo de servidores de propiedad de los distribuidores, es decir, si se ingresa un nuevo valor que no existía antes de la definición implícita de un nuevo grupo de servidores. Si no queda ningún distribuidor que use un valor X, el grupo de servidores X será eliminado. La lista de grupos de servidores podría ser percibida como "SELECT DISTINCT" en el grupo de servidores de propiedad de todos los distribuidores de un sistema.

IBM Cognos Administration ofrece la posibilidad de agrupar los distribuidores en carpetas. Sin embargo, esto no implica la existencia de un grupo de servidores; es simplemente un agrupamiento organizativo. Al usar carpetas, se pueden aplicar propiedades a múltiples distribuidores al mismo tiempo. Los distribuidores heredarán los valores de propiedad del objeto primario, como una carpeta, de manera predeterminada.

Información de clúster del distribuidor

Para poder asignar solicitudes a los servicios adecuados y enrutarlas correctamente, el distribuidor debe tener información integral sobre

  • los distribuidores que están en funcionamiento en el sistema IBM Cognos 8
  • los grupos de servidores a los que pertenecen esos distribuidores
  • los servicios asociados con cada uno de los distribuidores
  • el estado de ejecución de cada servicio

Esta información se denomina"información de clúster del distribuidor".

Como se mencionó brevemente en la sección 2.2, cada distribuidor se registrará en el Administrador de contenido al iniciarse. Durante este proceso de registro, el distribuidor informará a CM los servicios que aloja y su estado de ejecución (habilitado/deshabilitado). CM agregará esta información a la información de clúster del distribuidor recopilada hasta entonces. Luego el distribuidor consultará a CM sobre un subconjunto de la información de clúster del distribuidor y creará a partir de él unavista de clúster del distribuidor. La vista de clúster contiene todos los servicios y los distribuidores con los que están asociados, de manera que cada distribuidor tiene información sobre los otros distribuidores y sus servicios asociados.

La información de clúster del distribuidor se actualiza únicamente cuando se una llamada especial (reconfigure) que provoca que el distribuidor solicite información actualizada de CM y vuelva a generar su vista de clúster. Esta llamada es realizada por el Administrador de contenido cuando un distribuidor del sistema IBM Cognos 8 cambia su estado de ejecución de manera intencional (es detenido o iniciado por un administrador) o involuntaria (se bloquea). Esto genera información de clúster del distribuidor actualizada en CM que, a su vez, debe ser distribuida a cada uno de los distribuidores del sistema. Esto se realiza enviando la llamada reconfigure a cada uno de ellos. Una vez actualizada la información de clúster en CM, se puede tardar hasta 1 minuto para que todos los otros distribuidores recopilen los cambios y los apliquen. Esto se debe a que los distribuidores tienen un ping de supervivencia de 30 s, lo que significa que cada 30 s informan a CM que siguen activos. Al mismo tiempo, CM detectará que un distribuidor no está disponible después de un plazo máximo de 30 s.

Además de la información de clúster del distribuidor en general, es necesario actualizar las vistas de clúster de cada distribuidor con los estados de ejecución de los servicios. Sin embargo, esto sucede únicamente cuando un administrador cambia el estado de ejecución de un servicio. En ese caso, el distribuidor que aloja ese servicio concreto informará a CM el cambio y CM, a su vez, informará a los otros distribuidores.

La vista de clúster de un distribuidor se puede ver mediante la siguiente URL:

http://<INTERNAL_DISPATCHER_URI>?b_action=p2plbDiag

Es necesario que el usuario que acceda a esta URL tenga la capacidad "canUseAdministrationPortal" y que Cognos Application Firewall (CAF) esté deshabilitado respecto del distribuidor al que se accede.

Figura 2: Datos de salida de la vista de clúster de /p2plbDiag URL
Figure 2 - Cluster View output of /p2plbDiag URL

Equilibrio de carga

El equilibrio de carga es un concepto que se puede aplicar cuando hay múltiples instancias del mismo servicio IBM Cognos 8 disponiblesdentro de un grupo de servidores. Las instancias del mismo servicio en diferentes grupos de servidores no son aptas para el equilibrio de carga.

Sin embargo, no todos los servicios pueden ser objeto del equilibrio de carga; en las siguientes secciones encontrará más información al respecto.

En IBM Cognos 8, el equilibrio de carga puede estar habilitado o deshabilitado. Uno podría deshabilitar el equilibrio de carga integrado a IBM Cognos cuando se usan equilibradores de carga externos para distribuir la carga entre los nodos (distribuidores). Esto es obligatorio cuando se implementa IBM Cognos 8 en un clúster de WebSphere. En ese caso, los componentes de software de WebSphere deciden a qué nodo o distribuidor se enruta una determinada solicitud. Sin embargo, este enrutamiento no está basado en la disponibilidad o la carga del servicio IBM Cognos 8, sino en la disponibilidad y la carga del distribuidor. Como en un clúster todos los nodos deben ser idénticos, todos ejecutarán los mismos servicios y, por lo tanto, será contraproducente reenrutar la solicitud nuevamente.

Un segundo caso de uso se daría cuando se usa un equilibrio de carga de hardware o software externo entre distribuidores; sin embargo, estos casos de uso son muy específicos y, por lo tanto, es habitual que el equilibrio de carga esté habilitado para IBM Cognos 8.

El equilibrio de carga está controlado por el valor "Load Balancing Mode" ("Modo de equilibrio de carga") de un distribuidor (ver figura 1). Se lo puede establecer en "Weighted Round Robin" ("Operación por turnos ponderada"), es decir, habilitado, o en "Cluster Compatible" ("Compatible con clúster"), es decir, deshabilitado. Es importante tener presente que TODOS los distribuidores de un sistema deben usar el mismo modo, ya que, de lo contrario, el enrutamiento podría estar en conflicto y el producto podría no funcionar como se espera.

El modo "Operación por turnos ponderada" implica que IBM Cognos 8 debe enrutar las solicitudes aplicables. El enrutamiento facilitará una variante del método de operación por turnos de manera de distribuir solicitudes entre múltiples instancias de servicio. Si bien la operación por turnos es una asignación sencilla y directa de solicitudes, no respeta las posibles diferencias entre las instancias del servicio. Como IBM Cognos 8 usa una SOA, esas instancias podrían estar (y es probable que estén) ubicadas en diferentes servidores físicos, que podrían disponer de recursos muy diferentes (montones, CPU). Por consiguiente, no todas las instancias de un servicio son iguales en su capacidad potencial. Un servicio que se ejecuta en un CPU multinúcleo con mucha memoria RAM disponible podría administrar más carga que un servicio que se ejecuta en una CPU única con 2GB de RAM. Por este motivo, se agregó una ponderación al método de asignación de solicitudes denominado "operación por turnos". De esta forma, se puede ponderar cuántas solicitudes obtendrá una instancia determinada. De hecho, la ponderación se asigna al distribuidor y no al nivel de servicio, por lo que se aplica a todos los servicios alojados en el distribuidor, lo cual es lógico ya que todos comparten el mismo hardware. La ponderación se define en la propiedadProcessing Capacity (Capacidad de procesamiento)(ver figura 1) de un distribuidor. Teniendo en cuenta esta capacidad, la operación por turnos funciona de la siguiente forma:

Ejemplo:

Se definen 4 distribuidores con diferentes capacidades de procesamiento.

Distribuidor A, ponderación 1
Distribuidor B: ponderación 2
Distribuidor C: ponderación 1
Distribuidor D: ponderación 4

Las solicitudes se asignarán a los distribuidores en el siguiente orden: A, B, B, C, D, D, D, D, A, B, B, C, D, D, D, D, ...

El segundo valor del modo de equilibrio de carga es "compatible con clúster". Como se mencionó anteriormente, este método se usa para evitar un reenrutamiento de solicitudes aplicables que fueron deliberadamente enrutadas a un distribuidor específico y, por ende, a una instancia de servicio allí alojada. Esto es típico de entornos o instalaciones agrupados en clústeres, donde se usa un equilibrador de carga externo. Es importante tener en cuenta que las solicitudes que no pueden ser objeto del equilibrio de carga igualmente serán enrutadas al distribuidor/servicio correcto.

El modo de enrutamiento compatible con clúster excluye el uso del enrutamiento avanzado (que se tratará más adelante) y, por ende, vuelve obsoleta la definición de grupos de servidores explícitos.

Afinidad de la solicitud

Como se mencionó anteriormente, no todas las solicitudes pueden ser objeto del equilibrio de carga. Esto se debe a que existe otro concepto que define una medida en función de la importancia que tiene que una determinada solicitud sea procesada por una instancia de servicio de IBM Cognos 8 en un distribuidor específico. Esta medida se llamaafinidad de la solicitud. Si una solicitud es afín, no podrá tener una carga equilibrada.

La afinidad de una solicitud depende del servicio involucrado y del tipo de operación. Es establecida implícitamente por el sistema IBM Cognos 8 cuando se crea la solicitud, y no se puede controlar ni cambiar. La afinidad está almacenada en un valor que es parte del encabezado de acción SOAP de una solicitud. En IBM Cognos 8, existen 5 valores de afinidad diferentes.

  1. (ninguno): no afín.
    La solicitud puede ser enrutada a cualquier instancia en ejecución del servicio IBM Cognos 8 de destino.
  2. high: alta afinidad.
    La solicitud debe ser enrutada al distribuidor especificado en el parámetro nodeID, que es obligatorio para las solicitudes de alta afinidad y, por lo tanto, será establecido en el encabezado SOAP de la solicitud. Si el distribuidor solicitado no está disponible, la solicitud se considerará no afín.
  3. session: afinidad de sesión.
    Igual que la alta afinidad, con la diferencia que nodeID es opcional. Si nodeID no está especificado, la solicitud se considerará no afín.
  4. absolute: afinidad absoluta.
    El distribuidor debe enrutar la solicitud al distribuidor especificado por nodeID. Si el distribuidor especificado no está disponible, se producirá un error en la solicitud y se devolverá un error SOAP.
  5. control: afinidad de control.
    Igual que la afinidad absoluta; sin embargo, está reservada para operaciones de sistema relacionadas con la ejecución de informes como la cancelación de un informe.

Se recalca que solamente las solicitudes no afines pueden tener una carga equilibrada

Enrutamiento avanzado

Cuando se introdujo el concepto de grupos de servidores, no quedaba del todo claro cuál sería la aplicación de los grupos de servidores. Este último concepto lo revelará.

Cada distribuidor es parte de un grupo de servidores en un momento dado. De manera predeterminada, existe un solo grupo de servidores al que pertenecen todos los distribuidores de un sistema IBM Cognos 8. El equilibrio de carga de IBM Cognos 8 únicamente tiene lugar dentro del grupo de servidores, lo que significa que, en circunstancias normales, una vez que una solicitud ha sido asignada a un grupo de servidores, no hay manera de que pueda salir de ese grupo.

Esto implica que todos los distribuidores son iguales, en el sentido de que están disponibles para todo tipo de solicitudes y comparten la misma conectividad de base de datos si se ejecuta (Batch)ReportService. Sin embargo, esto puede no ser suficiente para todos los casos de uso.

El usuario podría desear que ciertas ejecuciones de informes sean procesadas por distribuidores específicos, por diversos motivos:

  • Los informes ejecutados por los ejecutivos deben ser procesados en un hardware dedicado
  • Los informes de los usuarios de una ubicación determinada deben ser procesados por servidores locales, y el sistema global se encuentra geográficamente distribuido
  • Un cierto tipo de conectividad de base de datos solamente existe (o no existe) en determinados distribuidores. Por ejemplo, si el sistema tiene distribuidores que se ejecutan en Windows y UNIX, y Microsoft SQL Server no tiene cliente de base de datos para SQL Server en UNIX. Es necesario asegurarse de que los informes ejecutados en SQL Server sean procesados por una instancia de ReportService alojada en un distribuidor que se ejecuta en Windows.
  • En los informes de IBM Cognos PowerCubes, es necesario que los archivos de cubo estén disponibles a nivel local. En lugar de copiarlos en múltiples equipos, sería conveniente procesar todos los informes basados en esos cubos en equipos que tengan el archivo correspondiente.

Estos son sólo algunos de los casos de uso que se pueden soportar implementando los grupos de servidores y el enrutamiento avanzado.

Elenrutamiento avanzadopermite enrutar solicitudes no afines de (Batch)ReportService y PowerPlay Service a grupos de servidores específicos en función de determinadasreglas de enrutamiento. Una vez asignadas a un grupo de servidores, pueden ser objeto del equilibrio de carga en ese grupo.

Las reglas de enrutamiento asignanconjuntos de enrutamientoa los grupos de servidores. Las reglas de enrutamiento se definen globalmente para todo el sistema IBM Cognos 8. Se almacenan en una lista única y son gestionadas por el Administrador de contenido a través de Cognos Administration.

Figura 3: Botón "Specify Routing Rules" ("Especificar reglas de enrutamiento") de Cognos Administration
Figure 3 -

La coincidencia entre las solicitudes de ejecución de informes y las reglas de enrutamiento es administrada por CM (no por el distribuidor). Las reglas son analizadasen secuenciay, cuando se desencadena la primera coincidencia, se detiene toda posterior evaluación de las reglas. Para recalcar, si bien una determinada solicitud coincide con la reglas #1 y #3, siempre será considerada de acuerdo a la regla #1 ya que la primera coincidencia es la que cuenta.

El servicio IBM Cognos 8 que envía una solicitud de (Batch)ReportService o PowerPlay Service es el responsable de llamar a CM para evaluar las reglas de enrutamiento y poner la información del grupo de servidores en la solicitud que se envía a un distribuidor. Por ejemplo, si un informe es llamado de manera interactiva a través de Cognos Connection, será Presentation Service (XTS) el que consulte a CM para determinar si el informe destinado para su ejecución está sujeto a alguna regla de enrutamiento. Si lo está, el servicio de CM responderá con el nombre de un grupo de servidores que Presentation Service agregará a la solicitud enviada a su distribuidor local para su procesamiento. Los informes programados serían administrados por Job and Monitoring Service (JMS).

Figura 4: Definición de reglas de enrutamiento en Cognos Administration
Figure 4 - Definition of Routing Rules in Cognos Administration

Por último, la definición de cuáles son las ejecuciones de informes a las que se aplicará el enrutamiento avanzado está a cargo de los conjuntos de enrutamiento. Un conjunto de enrutamiento es un nombre, una etiqueta aplicada a un conjunto de objetos de un cierto tipo. Existen tres tipos de conjuntos de enrutamiento, que se distinguen por el tipo de objetos que contienen:

  • Conjunto de enrutamiento de paquetes:
    Está compuesto de paquetes. Las ejecuciones de informes basadas en datos de los paquetes definidos se enrutarán a un grupo de servidores específico.
  • Conjunto de enrutamiento de grupos:
    Está compuesto de grupos de seguridad. Las ejecuciones de informes ejecutadas por un usuario miembro de uno de los grupos del conjunto se enrutarán al grupo de servidores especificado.
  • Conjunto de enrutamiento de roles:
    Está compuesto de roles de seguridad. Las ejecuciones de informes ejecutadas por un usuario miembro de uno de los roles del conjunto se enrutarán al grupo de servidores especificado.

Un conjunto de enrutamiento únicamente puede contener elementos de un solo tipo. No es posible definir un conjunto que contenga, por ejemplo, un paquete, dos grupos y un rol. Estos objetos deben pertenecer a tres conjuntos distintos.

Un administrador agrega objetos a un conjunto especificando el nombre del conjunto en la correspondiente sección de las propiedades del objeto. Si no existe ningún conjunto con ese nombre, será creado automáticamente. Consulte la documentación del producto para obtener detalles sobre cómo asignar grupos, roles o paquetes a un conjunto de enrutamiento.

Por último, la solicitud de ejecución de informes, (Batch-)ReportSevice o PowerPlay Service, será cotejada con las reglas de enrutamiento definidas. Si coincide con alguna regla, será enrutada a un distribuidor de ese grupo de servidores de destino. En el grupo de servidores de destino, puede tener lugar el equilibrio de carga y, finalmente, la solicitud se asigna a una instancia del servicio requerido. Si no hay ninguna coincidencia disponible con el servicio IBM Cognos 8, la solicitud generará un error que explique que no hay ningún servicio disponible para administrar ese tipo de solicitud.

El enrutamiento avanzado es muy versátil y puede mejorar en gran medida la administración de carga general y la modelación de tráfico a través del enrutamiento a recursos dedicados.


Proceso de enrutamiento

Finalmente, una vez introducidos los conceptos necesarios, ahora es posible definir el proceso de enrutamiento. En líneas generales, consta de cinco pasos.

Nota:La siguiente descripción es conceptual y no refleja necesariamente un resumen exacto de los pasos de cada acción. Sin embargo, es suficiente para poder comprender los conceptos tratados.

Identificar operación

El distribuidor tiene una lista estática de controladores. Cada controlador es consultado para detectar si puede administrar la solicitud en cuestión. Existen controladores para administrar la autenticación, el equilibrio de carga, etc. Sin entrar en detalles, bastará con comprender que cada controlador tiene su propia secuencia de pasos que usará para administrar la solicitud.

Por ejemplo, una de las primeras operaciones que ejecuta el distribuidor cuando recibe una solicitud es verificar si la sesión de la que es parte la solicitud ya ha sido autenticada. En caso contrario, se usará el controlador de autenticación, que ejecutará una serie de pasos y, sólo después de una autenticación exitosa, reemitirá la solicitud original para que continúe su procesamiento.

En los siguientes pasos, se presupone que la sesión ha sido autenticada.

Identificar servicio de destino

El siguiente paso consiste en identificar el servicio de destino que puede administrar la solicitud. El servicio de destino servicio se identifica en función de la siguiente información en el orden presentado.

  • Encabezado HTTP SOAPAction
    P. ej.: http://developer.cognos.com/schemas/reportService/1
    En este caso, el encabezado SOAPAction contendrá referencias a esquemas específicos que aluden al servicio que se va a usar.
  • Asignaciones de servicio
    Cada distribuidor tiene una lista estática de asignaciones de servicio SOAPAction de la que se puede extraer el servicio de destino.
  • Parámetro de URL "b_action"
    El comando HTTP GET o POST del distribuidor puede contener el parámetro b_action cuyo valor indica el servicio de destino.
    P. ej.: b_action=xts.run apunta a Presentation Service (XTS)
  • Información de ruta de acceso de la solicitud
    Algunas rutas de dirección URL indican un servicio de destino
    P. ej.: /cgi-bin/cognosisapi.dll/gd/… indica una acción específica (recuperar un gráfico o diagrama prerrepresentado) que es administrada por un controlador/servicio específico.
  • Si la solicitud no especifica ninguno de los elementos anteriores, es reenviada a la página de inicio de IBM Cognos Connection.

En este punto, la solicitud está autenticada y el servicio de destino está identificado.

Administrar solicitudes del Administrador de contenido

Si el servicio de destino es el servicio de Administrador de contenido, la solicitud se enruta al Administrador de contenido activo, sin tener en cuenta el enrutamiento avanzado, los grupos de servidores ni el equilibrio de carga. Esto es crucial para que el producto funcione.

Administrar solicitudes de ejecución de informes

En el caso de una solicitud de (Batch-)Report Service o PowerPlay Service, por lo que uno de los servicios ejecuta un informe de cualquier tipo, puede ser objeto de enrutamiento avanzado, si esnoafín.

Todas las solicitudes afines son enrutadas al distribuidor indicado, mientras que a las no afines se les aplicará el enrutamiento avanzado, si fuera definido.

En este punto, la solicitud ya estará asignada a un grupo de servidores.

Procesar el equilibrio de carga

Una vez que la solicitud ha sido asignada a un grupo de servidores, puede ser objeto del equilibrio de carga, siempre que sea no afín. Dependiendo del número de instancias del servicio de destino disponibles en el grupo de servidores, la solicitud será asignada de manera directa (una sola instancia disponible) en función de los resultados de la evaluación de operación por turnos ponderada (múltiples instancias del servicio de destino disponibles).

Si no hay ninguna instancia del servicio de destino disponible, la solicitud generará un error y se devolverá un mensaje de error al cliente que indique que no hay servicio de destino disponible en el grupo de servidores.


Apéndice A: Desafíos conocidos

SSO podría requerir XTS en distribuidores FRONTALES únicamente

Debido a la actual implementación del controlador de autenticación, puede darse una situación en ciertos entornos que genere un error en SSO.

Esto sólo se aplica a configuraciones queNO usen un componente de puerta de enlace, generalmente cuando IBM Cognos 8 se implementa en un servidor de aplicaciones como IBM WebSphere y se usan complementos de servidor de aplicaciones. En estas configuraciones, existe un requisito por el cual todos los accesos se deben efectuar únicamente a través de distribuidores FRONTALES y todos los distribuidores FRONTALES deben ejecutar Presentation Service.

En caso de que un distribuidor no FRONTAL también ejecute Presentation Service, puede suceder que al usuario se le devolverá XML en su explorador en lugar de que funcione la autenticación.

Cada grupo de servidores requiere al menos una instancia del Dispatcher Service

Cuando se definen los grupos de servidores, es importante asegurarse de que cada grupo de servidores ejecute al menos una instancia de Dispatcher Service; de lo contrario, las solicitudes podrían no ser enrutadas correctamente. Esto puede ocurrir si, por ejemplo, se define un grupo de servidores que contiene un solo nodo que es una instalación de un componente del Administrador de contenido. De manera predeterminada, una instalación exclusiva para CM no ejecuta Dispatcher Service.

Es una mejor práctica definir los grupos de servidores de manera que solamente los nodos que ejecuten servicios de ejecución de informes como (Batch-)ReportService y PowerPlay Service se agreguen a los grupos de servidores explícitamente definidos y que todos los demás nodos se queden en el grupo de servidores predeterminado.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=580117
ArticleTitle=Prácticas probadas de IBM Cognos: Enrutamiento por distribuidores en IBM Cognos 8 BI explicado
publish-date=07282010