Ampliar el ejemplo de Direccionamiento de mensajes utilizando una base de datos

Puede modificar el ESQL del ejemplo de Direccionamiento de mensajes para poder utilizarlo en otros flujos de mensajes.

Reutilización del flujo de mensajes Routing_using_database_and_memory_cache

El archivo ESQL, Routing_using_database_and_memory_cache, contiene todo el ESQL que se utiliza en la versión en memoria caché del ejemplo. Abra este archivo y busque la siguiente sección (marcada como Sección 1 en el ESQL):

Routing_using_database_and_memory_cache.esql

Deberá cambiar las tres partes resaltada (secciones 1, 2 y 3) basándose en el mensaje que va a direccionar el ESQL:

  1. Las tres variables ESQL, Variable1, Variable2 y Variable3, las utiliza el nodo Compute para buscar el gestor de colas de destino y la cola en la tabla de base de datos. Estas variables pueden estar grabadas en el código o pueden derivarse del mensaje entrante. En el ejemplo, el primer valor está grabado en el código y los dos otros se derivan del mensajes XML entrante. Es práctico tener el primer grabado en el código para poder utilizar un valor distinto para cada tipo de mensaje que pueda direccionarse, lo que significa que una tabla de base de datos puede utilizarse para muchos conjuntos diferentes de los datos de direccionamiento. Para crear un valor grabado en el código, establezca su valor en la sentencia DECLARE. En el ejemplo, Variable1 está establecida en el valor SAMPLE_QUEUES.
  2. Esta sección del ESQL muestra cómo se puede usar información desde el mensaje para establecer las otras dos variables. Para un tipo o formato de mensaje distinto, es necesario volver a escribir completamente esta parte para que haga referencia a los campos del mensaje entrante que es necesario utilizar para el direccionamiento.
  3. Si se producen problemas al establecer las variables, se establecerían los valores predeterminados. En el ejemplo, estos valores se establecen en el valor default.

Cuando se reutilice el ESQL para proporcionar prestaciones de direccionamiento en otro flujo de mensajes, puede dejar el resto del ESQL. La tabla de base de datos tiene que actualizarse con cualquier nueva entrada que requiera el nuevo flujo. Consulte el script de base de datos setupRoutingDatabase que se suministra con el ejemplo en el proyecto de Message Broker.

Cuando se utiliza el ESQL, debe asegurarse de que la Modalidad de cálculo de las propiedades del nodo Compute se ha establecido en uno de los siguientes valores, de lo contrario se perderá la información de direccionamiento:

El nombre de origen de datos ODBC de base de datos Origen de datos, también debe añadirse a las propiedades del nodo de cálculo.

Modificar el ámbito del bloque BEGIN ATOMIC ... END;

La sentencia ATOMIC BEGIN... END; se utiliza en el flujo de mensajes Routing_using_memory_cache para asegurarse de que sólo una hebra utiliza la memoria caché a la vez. La restricción de una sola hebra en esta parte del ESQL sólo es importante si la memoria caché va a renovarse dinámicamente. Si ha decidido que no es necesario renovar la memoria caché durante la vida del flujo de mensajes, entonces puede reducir el ámbito atómico del bloque para cubrir únicamente la inicialización de la memoria caché. El diagrama siguiente muestra el ESQL actual (marcado como Sección 4 en el ESQL):

Traslado al bloque del principio
  1. BEGIN ATOMIC indica que el siguiente ESQL va a ser de una sola hebra hasta que se llegue a la sentencia END; correspondiente.
  2. Si la memoria caché no se renueva dinámicamente, el comentario de ESQL marcado por el número 4 muestra a dónde se puede mover la sentencia END;.
  3. Si se coloca una sentencia END; nueva en el marcador 4, debe eliminarse la sentencia END; actual.

Después de haber realizado esta modificación, la búsqueda del nombre de la cola en la memoria caché dejará de ser de una sola hebra. En la memoria caché se pueden leer varios mensajes simultáneamente.

Utilizar variables externas para que sea más fácil desplegar el flujo de mensajes en distintos sistemas

Las variables externas permiten que los valores grabados en código de los flujos de mensajes se promocionen al nivel de flujo de mensajes para poder modificarlos durante el despliegue. El flujo de mensajes puede personalizarse al realizar el despliegue para el entorno en el que se está desplegando sin necesidad de modificar el ESQL del flujo de mensajes.

El flujo de mensajes Routing_using_database_and_memory_cache tiene una variable denominada Variable1, que se utiliza para realizar la búsqueda de base de datos; es codificada en el valor QUEUES. Se debe externalizar esta variable durante el despliegue para pueda modificarse su valor en función de el sistema en que se efectúa el despliegue. Esta externalización permite utilizar distintos conjuntos de colas y gestores de colas para cada sistema, pero continúa permitiendo el uso de la misma tabla de base de datos.

Para que la Variable1 sea una variable externa:

  1. Modifique el ESQL para declarar la Variable1 como variable externa. Cambiar
    DECLARE Variable1 CHAR 'SAMPLE_QUEUES'
    a
    DECLARE Variable1 EXTERNAL CHAR 'SAMPLE_QUEUES'
    El ESQL debe ser similar al ejemplo siguiente:
    -- Section 1
    DECLARE Variable1 EXTERNAL CHAR 'SAMPLES_QUEUES';
    DECLARE Variable2 CHAR;
    DECLARE Variable3 CHAR;
  2. La variable externa se debe definir en el nivel de flujo de mensajes.
    1. Abra el flujo de mensajes Routing_using_database_and_memory_cache, haga clic en la pestaña Propiedades definidas por el usuario al final del editor de flujos de mensajes.
    2. Cree una nueva propiedad llamada Variable1 y establezca su valor predeterminado en SAMPLE_QUEUES:

      Propiedades definidas por el usuario

  3. La variable Variable1 es ahora una variable externa.
    1. Añada el flujo de mensajes a un archivo de archivado de intermediario (BAR), pulse en el separador Configurar.
    2. Seleccione el nodo Compute en el flujo y cambie el valor de la variable siguiente:

      Editor del archivo BAR

Para utilizar esta variable externa, debe crear nuevas entradas en la tabla ROUTING_TABLE de la base de datos ROUTING que tenga parámetros Variable1 distintos. Si el flujo se despliega sin cambiar el valor de Variable1, funcionará como antes. (De forma predeterminada, Variable1 toma el valor SAMPLE_QUEUES).

Modificar los criterios de renovación de memoria caché

Los criterios de renovación actuales para la memoria caché de la tabla de base de datos del ejemplo de Direccionamiento de mensajes son:

Puede ser de utilidad utilizar otros criterios para decidir cuándo renovar la memoria caché. Los posibles criterios pueden ser:

  1. Renovar la memoria caché tras un periodo de tiempo específico
  2. Renovar la memoria caché tras un número específico de mensajes

El ejemplo puede modificarse fácilmente para utilizar cualquiera de estos criterios. El lugar crítico del ESQL para la renovación de la memoria caché es:

criterios ESQL

Para cambiar los criterios de renovación para que se utilice un periodo de tiempo de 60 segundos:

  1. Cambie el criterio encerrado en un círculo rojo en el ESQL por:
    IF CacheQueueTable.LastUpDate is null or (CURRENT_TIMESTAMP -
        CacheQueueTable.LastUpDate) second > INTERVAL '60' SECOND THEN
  2. Cambiar
    SET CacheQueueTable.valid = true;
    a
    SET CacheQueueTable.LastUpDate = CURRENT_TIMESTAMP;

Para cambiar los criterios de renovación para que sea verdadero (true) tras 100 mensajes:

  1. Cambie el criterio encerrado en un círculo rojo en el ESQL por:
    IF CacheQueueTable.MessageCount is null or
    CacheQueueTable.MessageCount > 100 SECOND THEN
  2. Cambiar
    SET CacheQueueTable.valid = true;
    a
    SET CacheQueueTable.MessageCount = 0;
  3. Añada una sentencia al final del módulo ESQL para incrementar la cuenta:
    SET CacheQueueTable.MessageCount = CacheQueueTable.MessageCount +1;

Volver a la página inicial del ejemplo