3

I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors: 

Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector, 
error is Unable to put message on queue null. MQ returned error code 2538.

Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z

Can someone please help me resolve this. Please let me know if any further details are required.

Here are the details:

  1. Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
  2. MQ is running on-premise
  3. The port I am trying to connect is 1414.
  4. Have a secure connector running on the machine where MQ is installed.
  5. MQ version is 8.
  6. In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
JoshMc
  • 10,239
  • 2
  • 19
  • 38
Veena Menon
  • 51
  • 4
  • That's helpful but we need a bit more. For example, what does "Have a secure connector running on the machine where MQ is installed" mean? That's not an MQ term. Is it a Cast Iron term? Also, "the port I am trying to connect is 1414" is helpful but there's no mention of whether an MQ listener is defined and running on that port. Also, if Cast Iron is deployed in an off-premise cloud and MQ is on premise, do you know there's a route through the firewall to reach MQ? – T.Rob Jul 16 '15 at 12:54
  • MQ will record connection attempts in its log files and as event messages. If the login name was the issue, you would see 2035 errors on the QMgr. The 2538 suggests it isn't getting that far. However, if you ever do get that far, a v8 QMgr will not allow admin connections on any SVRCONN channel by default. You would have to have disabled CHLAUTH or defined a new CHLAUTH rukle or two to get the mqm ID or anything in the mqm group to connect at all. Again, not enough info in the question to say whether this is an issue or not. – T.Rob Jul 16 '15 at 12:57
  • Thanks for your reply Rob. The secure connector is a Cast Iron term. It is a connector which runs on the machine where MQ is running and the same configuration are set up in Cast Iron Console(very similar to one way SSL handshake). For Cast Iron cloud to communicate with on-premise MQ, it requires this secure connector to be in running status. It is used in cases where there is a firewall. There is an MQ listener running on the port 1414.Cast Iron flow is deployed on the cloud which is off-premise and MQ is on-premise. Please let me know if you need any further details. – Veena Menon Jul 17 '15 at 07:58
  • I checked the MQ logs too. But there are no messages in the logs whch gives information about the message failing in MQ. As you said, it has not reached MQ as yet, hence no messages in logs. – Veena Menon Jul 17 '15 at 08:23

1 Answers1

2

The return code is instructive:

2538  0x000009ea  MQRC_HOST_NOT_AVAILABLE

This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.

There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.

  1. The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
  2. The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
  3. The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.

If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.

Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.

Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.

The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.

For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.

For example:

DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
    ADDRESS('127.0.0.1') +
    USERSRC(MAP) MCAUSER('mqm') +
    ACTION(REPLACE) 
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
    USERLIST('*NOBODY') +
    WARN(NO) ACTION(REPLACE)

The first statement defines the new channel.

The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.

The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.

T.Rob
  • 31,522
  • 9
  • 59
  • 103