Thursday, 27 November 2014

IBM Integration Bus - Port Reporting

Following on from this earlier post: -


I'm working with a colleague to implement the same configuration in another environment.

Again, we're using IBM HTTP Server 8.5.5.2 in front of IBM Integration Bus 9.0.0.2, in order to allow requests ( SOAP over HTTP in this particular case ) to be routed to one of a number of Integration Nodes ( aka Brokers in the old tongue ).

This is partly to improve performance ( more engines to service requests ) and partly for resilience ( service can be maintained in the event of the loss of one Integration Node ).

So I have learned three new things today ( what's the bon mot about impossible things and breakfast ? Well, mine is learn new stuff before AND after breakfast !! ).

Firstly, one can report on the IIB configuration to see what ports an Integration Node is listening for HTTP connections, as follows: -

mqsireportproperties <<NAME OF INTEGRATION NODE>> -b httplistener -o HTTPConnector -a

which returns something like this: -

 HTTPConnector
  uuid='HTTPConnector'
  address=''
  port='7122'
  maxPostSize=''
  maxSavePostSize=''
  acceptCount=''
  compressableMimeTypes=''
  compression=''
  connectionLinger=''
  connectionTimeout=''
  maxHttpHeaderSize=''
  maxKeepAliveRequests=''
  maxThreads=''
  minSpareThreads=''
  noCompressionUserAgents=''
  restrictedUserAgents=''
  socketBuffer=''
  tcpNoDelay=''
  enableLookups='false'

It's worth noting that the port ( 7122 in the above example ) isn't the port on which the Integration Server ( formerly Execution Group) listens ( see below ).

Secondly, in order for IHS to route HTTP requests to IIB, there needs to be another, different, port configured, specifically at the Integration Server ( formerly Execution Group)  level, as evidenced by a modified mqsireportproperties command: - 

mqsireportproperties <<NAME OF INTEGRATION NODE>> -e default -o HTTPConnector -a

HTTPConnector
  uuid='HTTPConnector'
  userTraceLevel='none'
  traceLevel='none'
  userTraceFilter='none'
  traceFilter='none'
  port='8220'
  address=''
  maxPostSize=''
  maxSavePostSize=''
  acceptCount=''
  compressableMimeTypes=''
  compression=''
 connectionLinger=''
  connectionTimeout=''
  maxHttpHeaderSize=''
  maxKeepAliveRequests=''
  maxThreads=''
  minSpareThreads=''
  noCompressionUserAgents=''
  restrictedUserAgents=''
  socketBuffer=''
  tcpNoDelay=''
  explicitlySetPortNumber='8220'
  enableLookups=''
  enableMQListener=''
  shutdownDelay=''
  allowCrossConnectorPolling=''
  autoRespondHTTPHEADRequests=''
  integratedWindowsAuthentication=''
  iwaTimeoutSeconds='300'

In this example, port 8220 is explicitly set for this Integration Server.

That's the port that I needed to know about in order to configure IBM HTTP Server / WebSphere Plugin to route requests to that particular Integration Server ( one of many ).

Thirdly, and importantly, this port will NOT come up until the Integration Server is started.

I'd assumed that IIB was similar to WAS in that the TCP/IP ports come up as soon as the container ( IIB instead of a WAS JVM ) starts, but that is NOT the case.

Bottom line, one needs to start the Integration Server ( which hosts the flow(s) running on IIB, before the port will show up.

This surprised us, as we were busy using netstat and telnet but couldn't find out why the port wasn't listening :-(

Finally, and fourthly, the IBM Integration Bus Toolkit allows one to export a plugin configuration file suitable for the WebSphere Plugin.

Therefore, I could've simply asked my IIB admin guru to generate the file, rather than my having to hand-code it, or use Java.

However, that's the point of learning .........

Thanks to this IBM Technote for some guidance on mqsireportproperties: -

Using the mqsireportproperties command in IBM Integration Bus or WebSphere Message Broker for a single message flow

No comments: