Cuando cree un flujo de mensajes para recibir mensajes de clientes de telemetría, deberá incluir como mínimo un nodo SCADAInput. Configure las propiedades para definir el puerto en el que escuchará los mensajes nuevos. Si el flujo de mensajes envía mensajes a clientes de telemetría, deberá incluir un nodo Publication o un nodo SCADAOutput (el nodo Publication incluye un nodo SCADAOutput incorporado).
Debe desplegar los flujos de mensajes que contienen nodos SCADAInput y SCADAOutput en un solo grupo de ejecución dentro del intermediario. Si envía mensajes a clientes de telemetría a través de un nodo Publication, el flujo de mensajes que contiene ese nodo también deberá estar en el mismo grupo de ejecución que un nodo SCADAInput, aunque no tenga ningún flujo de mensajes que reciba mensajes de los clientes de telemetría. Esto se debe a que las propiedades del nodo SCADAInput identifican el puerto TCP/IP que se utiliza para las comunicaciones con los clientes y las características de cómo se manejan los mensajes.
Inicie y detenga un escucha de WebSphere MQ Telemetry Transport utilizando un mensaje de publicación con el tema $SYS/SCADA/MQIsdpListener/<número_puerto>. Establezca la parte de carga útil del conjunto de mensajes en ON u OFF. Sustituya <número_puerto> por el puerto individual que desee iniciar o detener o por all para iniciar o detener todos los puertos del sistema que estén designados como puertos SCADA.
El número de mensajes manejados por un flujo de mensajes depende de la productividad de mensajes y de los tiempos de respuesta. Revise los consejos que se proporcionan en Optimizar los tiempos de respuesta de los flujos de mensajes y en Optimizar el rendimiento del flujo de mensajes. Además, deberá tener en cuenta la calidad de servicio que elija para los mensajes recibidos procedentes de los clientes de telemetría o publicados en dichos clientes. Esta tarea está descrita en el apartado Elección de la calidad de servicio.
La calidad de servicio determina la fiabilidad de la entrega de mensajes. Revise las circunstancias de los mensajes que se procesan; en algunas situaciones, la pérdida de mensajes puede ser aceptable. Para otros escenarios, es posible que la entrega de mensajes necesite estar garantizada. Las opciones de Calidad de servicio, QoS0, QoS1 y QoS2, se describen en Niveles y flujos de Calidad de servicio de WebSphere MQ Telemetry Transport.
Si elige garantizar la entrega de mensajes, el intermediario debe realizar acciones adicionales para conservar el mensaje hasta que está seguro de que se ha entregado. Puesto que esto afecta al rendimiento del intermediario y del cliente, deberá buscar el equilibrio entre la necesidad de velocidad de proceso de mensajes y la necesidad de asegurar la entrega de mensajes.
Si elige QoS1 o QoS2, que indica que el mensaje se debe entregar como mínimo o sólo una vez, el intermediario y el cliente deben proporcionar un determinado nivel de acuse de recibo. El intermediario debe almacenar el mensaje para que éste se pueda volver a enviar si no se reciben los acuses de recibo apropiados.
El intermediario almacena los mensajes en la base de datos. Esto puede afectar el manejo de mensajes si el intermediario no es capaz de realizar entrada o salida en la base de datos cuando es necesario; si sucede esto, es posible que el intermediario deje de procesar mensajes. Si la base de datos de intermediario es DB2, desactive el siguiente bloqueo de clave de DB2 para evitar estos problemas de punto muerto. Emita el mandato siguiente en una ventana de mandatos de DB2 para realizar este cambio:
db2set DB2_RR_TO_RS=YES
Reinicie el gestor de bases de datos de DB2 para que este cambio entre en vigor.
Si elige QoS0, no se garantiza la entrega de mensajes. El intermediario no almacena los mensajes.