Skip to main content
Connector Type: Input Connector Description Ingests enterprise messages from IBM MQ queues into Condense for transformation and routing. Brief Description The IBM MQ Stream Input Connector enables Condense to ingest enterprise-grade messaging data from IBM MQ queues into the Condense platform for transformation, routing, and real-time stream processing. IBM MQ (formerly WebSphere MQ) is a robust enterprise messaging middleware designed for guaranteed message delivery, transactional integrity, and asynchronous communication between distributed systems. With this connector, Condense can consume messages from IBM MQ queues and forward them to Kafka-native Condense topics allowing integration of legacy enterprise systems with modern data pipelines and event-driven applications. Links to Relevant Documents Connector Overview Core Functionality
  • Message Ingestion: Consumes messages from a configured IBM MQ queue in real time.
  • Reliable Delivery: Ensures at-least-once delivery semantics, respecting MQ transaction handling.
  • Secure Connectivity: Supports TLS/SSL-secured channels and user authentication.
  • Topic-Based Routing: Publishes consumed MQ messages to Condense Kafka topics for downstream processing.
  • High Throughput: Optimized for continuous consumption of enterprise-scale message loads.
How It Works in Condense
  1. Connection Establishment The connector connects to the IBM MQ queue manager using the provided Server Name, Port, Queue Manager, and Channel configuration.
  2. Authentication The connector authenticates using Username and Password, if required by the MQ server.
  3. Message Consumption It continuously listens to the configured Destination Queue (Queue Name) for new messages.
  4. Data Serialization Retrieved messages are transformed into a structured JSON payload for uniform downstream processing.
  5. Publishing to Kafka The connector publishes these messages to a specified Condense Output Topic, allowing other systems or Condense applications to process them.
Configuration Field-by-Field Explanation 1. Title Description: Name for the connector instance. Example: IBMMQ_Input_Connector_Prod 2. Server Name Description: Hostname or IP address of the IBM MQ server. Example: mq-enterprise-server.company.com 3. Server Port Description: Port used for IBM MQ communication. Example: 1414 4. Destination Name Description: Queue name from which messages are consumed. Example: ORDERS.INPUT.QUEUE 5. Queue Manager Description: Name of the IBM MQ Queue Manager. Example: QM1 6. Channel Description: MQ communication channel. Example: DEV.APP.SVRCONN 7. Username Description: Username used for IBM MQ authentication. Example: mq_user 8. Password Description: Password used for IBM MQ authentication. Example: mq_password 9. Topic (Output) Description: Kafka topic where consumed IBM MQ messages are published. Example: ibmmq_input_stream Example Message Flow
  1. Message published to IBM MQ queue ORDERS.INPUT.QUEUE.
  2. Condense IBM MQ Input Connector retrieves the message.
  3. Connector converts the message payload to structured JSON.
  1. Message is published to the Condense topic ibmmq_input_stream.
Troubleshooting and Common Issues 1. Connection Refused (2059)
  • Verify Server Name, Port, and Queue Manager values.
  • Ensure the channel is configured as SVRCONN.
2. MQRC_NOT_AUTHORIZED (2035)
  • Check the username and password.
  • Verify that the MQ administrator has granted access to the channel and queue.
3. Channel Initialization Failure
  • The configured channel may not exist or may be restricted by CHLAUTH rules.
  • Validate using the MQ command:
4. Message Loss or Delay
  • Verify that the Output Topic is active in Condense.
  • Ensure the connector status is RUNNING.
5. Timeouts (MQRC_CONNECTION_BROKEN)
  • Check firewall or VPN latency.
  • Ensure persistent network connectivity between Condense and IBM MQ.
Advanced Considerations
  • TLS/SSL Security: The connector can be configured to use TLS-enabled channels (for example, DEV.APP.SVRCONN.SSL). Ensure the keystore and truststore configurations are managed in your MQ environment.
  • Message Acknowledgment: Messages are acknowledged only after successful publishing to the Kafka topic, maintaining reliable delivery.
  • Data Format Handling: Binary messages are Base64-encoded before publication to Condense topics.
  • Performance: Batch consumption from queues can be optimized using queue depth-based triggers and parallel channel configurations.
Best Practices
  1. Use dedicated application queues for streaming data to avoid mixing control messages.
  2. Always validate connectivity using IBM MQ command-line tools before configuring in Condense.
  3. Monitor queue depth regularly to detect ingestion delays.
  4. Apply meaningful connector titles and topic names for better observability.
  5. Rotate MQ credentials periodically in accordance with enterprise security policies.