IBM MQ streaming queues en la práctica

Las streaming queues de IBM MQ permiten que un queue manager coloque una copia casi idéntica de cada mensaje en una segunda cola. La aplicación que hace put en la cola original no necesita cambiar, y la aplicación que hace get de la cola original sigue sin saber que el streaming ha ocurrido.

Este artículo es deliberadamente práctico. Usa un único contenedor IBM MQ, crea un pequeño conjunto de colas locales y valida después los dos modos de calidad de servicio de streaming (BESTEF y MUSTDUP).

También introduce CAPEXPRY, que es importante cuando quiere retener los mensajes duplicados durante un período limitado en lugar de dejar que la cola de destino crezca indefinidamente.

1. Objetivos del lab

Al final de este lab debería ser capaz de:

• Explicar el objetivo y el comportamiento de las streaming queues de IBM MQ
• Configurar STREAMQ y STRMQOS en colas locales
• Entender la diferencia entre BESTEF y MUSTDUP
• Entender por qué CAPEXPRY es importante en la cola de destino
• Reconocer las principales restricciones que se aplican a streaming queues

2. Software necesario

Para este lab, vamos a usar:

• IBM MQ 9.4.x en Linux
• Docker Engine y plugin Docker Compose
• una cuenta Linux con permisos para ejecutar comandos Docker

Si Docker todavía no está instalado, ejecute:

• Ubuntu / Debian

  sudo apt-get update
  sudo apt-get install -y docker.io docker-compose-plugin
  sudo systemctl enable --now docker

• RHEL / CentOS / Fedora

  sudo dnf -y install dnf-plugins-core
  sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
  sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
  sudo systemctl enable --now docker

Verifique la instalación:

docker version
docker compose version

Obtenga la imagen de IBM MQ:

docker pull icr.io/ibm-messaging/mq:latest

3. Qué añaden las streaming queues a un diseño MQ

Las streaming queues se configuran en las propiedades de las colas, y no en las aplicaciones. Los atributos que debe considerar son:

La decisión principal que suele tomar es esta:

• Si el flujo de negocio original debe continuar aunque el camino duplicado tenga problemas, use BESTEF
• Si la copia duplicada es obligatoria, por ejemplo por compliance o por captura garantizada para replay, use MUSTDUP

4. Comportamiento operativo importante

Dos detalles que es importante conocer:

1. El mensaje duplicado es creado por el queue manager, no por la aplicación que hace put 2. Cuando MQ hace streaming de un mensaje, la copia duplicada tiene su expiración restablecida a ilimitada, salvo que la limite con CAPEXPRY en la cola que recibe la copia

Este segundo punto es fácil de ignorar. Si hace streaming hacia una cola de histórico y nadie la consume, esa cola seguirá creciendo sin control.

5. Principales restricciones a tener en cuenta

Existen algunas restricciones importantes del mecanismo de streaming:

• No es posible crear cadenas de streaming como Q1 -> Q2, Q2 -> Q3
• No es posible crear ciclos como Q1 -> Q2, Q2 -> Q1
• No es posible definir STREAMQ en una transmission queue
• STREAMQ no puede referirse a una model queue

Por simplicidad, este lab usa solo colas locales en un único queue manager.

6. Crear la carpeta del lab y el fichero docker-compose

Cree una carpeta de trabajo:

mkdir -p ~/mq-streaming-lab
cd ~/mq-streaming-lab

Cree el fichero docker-compose.yaml:

cat > docker-compose.yaml <<'EOF'
services:
  mq-dev:
    container_name: mq-dev
    image: icr.io/ibm-messaging/mq:latest
    environment:
      LICENSE: "accept"
      MQ_QMGR_NAME: "QM1"
    ports:
      - "1414:1414"
EOF

7. Iniciar el queue manager

Inicie el contenedor Docker:

docker compose up -d

Confirme que el queue manager está activo:

docker exec mq-dev dspmq

Debería ver QM1 en estado Running.

8. Crear las colas del lab

Este bloque de código crea las siguientes colas:

• APP.IN.NORMAL para un ejemplo normal de streaming
• APP.IN.BEST para el escenario BESTEF
• APP.IN.MUST para el escenario MUSTDUP
• APP.AUDIT como cola duplicada normal
• APP.AUDIT.SMALL como cola duplicada deliberadamente limitada

docker exec -i mq-dev runmqsc QM1 <<'EOF'
DEFINE QLOCAL(APP.IN.NORMAL) REPLACE
DEFINE QLOCAL(APP.IN.BEST) REPLACE
DEFINE QLOCAL(APP.IN.MUST) REPLACE
DEFINE QLOCAL(APP.AUDIT) REPLACE
DEFINE QLOCAL(APP.AUDIT.SMALL) MAXDEPTH(1) REPLACE
CLEAR QLOCAL(APP.IN.NORMAL)
CLEAR QLOCAL(APP.IN.BEST)
CLEAR QLOCAL(APP.IN.MUST)
CLEAR QLOCAL(APP.AUDIT)
CLEAR QLOCAL(APP.AUDIT.SMALL)
END
EOF

Confirme las definiciones:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
DISPLAY QLOCAL(APP.IN.NORMAL) STREAMQ STRMQOS
DISPLAY QLOCAL(APP.IN.BEST) STREAMQ STRMQOS
DISPLAY QLOCAL(APP.IN.MUST) STREAMQ STRMQOS
DISPLAY QLOCAL(APP.AUDIT) CURDEPTH MAXDEPTH CAPEXPRY
DISPLAY QLOCAL(APP.AUDIT.SMALL) CURDEPTH MAXDEPTH CAPEXPRY
END
EOF

9. Streaming básico con BESTEF

Active el streaming de APP.IN.NORMAL hacia APP.AUDIT:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
ALTER QLOCAL(APP.IN.NORMAL) STREAMQ(APP.AUDIT) STRMQOS(BESTEF)
CLEAR QLOCAL(APP.IN.NORMAL)
CLEAR QLOCAL(APP.AUDIT)
DISPLAY QLOCAL(APP.IN.NORMAL) STREAMQ STRMQOS
END
EOF

Ponga un mensaje:

docker exec mq-dev bash -lc "printf 'stream-normal-1\n' | /opt/mqm/samp/bin/amqsput APP.IN.NORMAL QM1"

Examine la cola original:

docker exec mq-dev /opt/mqm/samp/bin/amqsbcg APP.IN.NORMAL QM1

Examine la cola duplicada:

docker exec mq-dev /opt/mqm/samp/bin/amqsbcg APP.AUDIT QM1

En este punto debería ver el mismo contenido en ambas colas.

10. Comportamiento BESTEF cuando la cola duplicada ya está llena

Vamos ahora a crear un escenario en el que la cola destino del streaming no pueda recibir más mensajes y el camino original deba seguir funcionando.

Configure APP.IN.BEST para hacer streaming hacia la cola pequeña:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
ALTER QLOCAL(APP.IN.BEST) STREAMQ(APP.AUDIT.SMALL) STRMQOS(BESTEF)
CLEAR QLOCAL(APP.IN.BEST)
CLEAR QLOCAL(APP.AUDIT.SMALL)
END
EOF

Ponga un mensaje en APP.AUDIT.SMALL para alcanzar MAXDEPTH(1):

docker exec mq-dev bash -lc "printf 'pre-fill-small-queue\n' | /opt/mqm/samp/bin/amqsput APP.AUDIT.SMALL QM1"

Verifique la profundidad de la cola:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
DISPLAY QLOCAL(APP.AUDIT.SMALL) CURDEPTH MAXDEPTH
END
EOF

Ahora ponga un mensaje en la cola original configurada con BESTEF:

docker exec mq-dev bash -lc "printf 'best-effort-message\n' | /opt/mqm/samp/bin/amqsput APP.IN.BEST QM1"

Verifique la profundidad de ambas colas:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
DISPLAY QLOCAL(APP.IN.BEST) CURDEPTH
DISPLAY QLOCAL(APP.AUDIT.SMALL) CURDEPTH
END
EOF

Interpretación:

• APP.IN.BEST debería contener el mensaje original
• APP.AUDIT.SMALL debería seguir llena solo con el mensaje precargado

Esto es exactamente el significado de BESTEF: el camino del mensaje original sigue disponible aunque la copia duplicada no pueda entregarse.

11. Comportamiento MUSTDUP cuando la cola duplicada ya está llena

Ahora pasamos al modo más restrictivo. Configure APP.IN.MUST para hacer streaming hacia la misma cola, con profundidad limitada a un máximo de 1 mensaje:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
ALTER QLOCAL(APP.IN.MUST) STREAMQ(APP.AUDIT.SMALL) STRMQOS(MUSTDUP)
CLEAR QLOCAL(APP.IN.MUST)
DISPLAY QLOCAL(APP.IN.MUST) STREAMQ STRMQOS
END
EOF

Manteniendo APP.AUDIT.SMALL llena, intente poner un nuevo mensaje:

docker exec mq-dev bash -lc "set -o pipefail; printf 'must-duplicate-message\n' | /opt/mqm/samp/bin/amqsput APP.IN.MUST QM1; echo RC:$?"

Verifique de nuevo las colas:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
DISPLAY QLOCAL(APP.IN.MUST) CURDEPTH
DISPLAY QLOCAL(APP.AUDIT.SMALL) CURDEPTH
END
EOF

• El put debería fallar porque la cola duplicada no puede aceptar la copia
• APP.IN.MUST debería seguir vacía
• APP.AUDIT.SMALL debería mantener profundidad 1

Esta es la diferencia operativa que más importa en la práctica:

• BESTEF protege el flujo de la aplicación original
• MUSTDUP protege la garantía de que existe una copia duplicada

12. Aplicar retención con CAPEXPRY

Si hace streaming hacia una cola de histórico y nadie la consume, los mensajes se acumulan. Una práctica común es usar CAPEXPRY para limitar el tiempo de vida de la copia duplicada.

Defina CAPEXPRY en la cola de destino:

docker exec -i mq-dev runmqsc QM1 <<'EOF'
ALTER QLOCAL(APP.AUDIT) CAPEXPRY(300)
DISPLAY QLOCAL(APP.AUDIT) CAPEXPRY
END
EOF

Esto significa que los nuevos mensajes que lleguen a APP.AUDIT no podrán vivir más de 300 segundos, aunque la copia duplicada tuviera, de otra forma, expiración ilimitada.

En un escenario de producción, esto es a veces preferible a crear una aplicación separada solo para limpiar la cola de histórico.

13. Lo que mostró el lab

Este lab demostró cuatro puntos concretos:

1. Las streaming queues se configuran en objetos cola, no en la aplicación que hace put. 2. El queue manager coloca una copia casi idéntica del mensaje en la cola secundaria. 3. BESTEF y MUSTDUP son materialmente diferentes cuando el camino duplicado tiene un problema. 4. CAPEXPRY es importante para controlar la retención en la cola de destino.

14. Cuándo las streaming queues son una buena opción

Las streaming queues son especialmente útiles cuando necesita:

• Un histórico de corto plazo de mensajes de negocio
• Una alimentación duplicada para análisis u observabilidad
• Un origen de replay para pruebas de recuperación
• Un mecanismo poco intrusivo para copiar mensajes hacia otro flujo de procesamiento

Serán menos adecuadas cuando necesite fan-out complejo o lógica de transformación. En esos casos, el uso de publish/subscribe o una capa adicional de integración será probablemente una mejor opción.

15. Resumen

Las streaming queues de IBM MQ son deliberadamente simples: configure una cola de origen con STREAMQ, elija BESTEF o MUSTDUP, y deje que el queue manager duplique los mensajes.

La pregunta práctica a tener en cuenta en el diseño de la solución no es si el streaming funciona, sino qué hacer en caso de fallo:

• Si el camino de negocio original debe permanecer aislado de fallos en el camino duplicado, use BESTEF
• Si la copia duplicada es obligatoria, use MUSTDUP

Si es necesario, use CAPEXPRY para controlar la retención de mensajes en la cola de destino.

16. Cleanup

Este paso de cleanup elimina solo los artefactos del lab. No desinstala Docker ni IBM MQ del host.

docker compose down -v
cd ..
rm -rf ~/mq-streaming-lab

Documentación útil en IBM

• Streaming queues
• Streaming queues configuration
• Streaming queue restrictions
• Using streaming queues to store a history of messages
• DEFINE queues reference (STREAMQ, STRMQOS, CAPEXPRY)