What is URL Encoding?

When you pass information through a URL, you need to make sure it only uses specific allowed characters like: alphabetic characters, numerals, and a few special characters that have meaning in the URL string. Any other characters should be encoded so that they don't cause problems.

The most commonly encoded character is the <space> character. You see this character whenever you see a plus-sign (+) in a URL. This represents the space character. The plus sign acts as a special character representing a space in a URL. The most common way you'll see this is in a mailto link that includes a subject. If you want the subject to have spaces in it, you can encode them as pluses:

mailto:email?subject=this+is+my+subject

How Do You Encode a URL?

Simply replace the special characters with their encoding string. This will nearly always begin with a %. If you don't want to do it by hand, you can use a script such as is found on the JavaScript site: Encoding Web Addresses.

How URL_Decoding can be done in Message Broker?

     I.        When the HTTP client sends the Request-Type as “GET” and the Content-type as “URL-Encoded”,then our Message broker HTTPInput node by itself can decode the url-encoded input message .

To extract the decoded message ,we have to enable the “parseQueryString” property in the HTTPInput node as below.

Then the decoded message will be present in the below path.We can extract the message from this path for further use.

For eg:

SET Environment.Variables.OriginalMessage = CAST(InputLocalEnvironment.HTTP.Input.QueryString.Input AS BLOB CCSID 1208);

   II.        When the HTTP client sends the Request-Type as “POST” and the Content-type as “URL-Encoded”,then our Message broker HTTPInput node cannot by itself decode the url-encoded input message .

The following method can be used to achieve such scenarios.

Introduce a “Javacompute node” after HTTPInput node.

String result =  java.net.URLDecoder.decode("=%3cn%3aMessage+xmlns%3an%3d%22http%3a%2f%2f%3e%5d%5d%3e%3c%2fMsg%3e%3c%2fn%3aMessage%3e", "UTF-8");

Refer the message in a variable or directly as shown in the above example.

Note : No need for checking “parseQueryString” option in HTTPInput node.

HTTP URL Encoding

Encoding Vs Encryption Encoding is the process of transforming data so that it may be transmitted without danger over a communication channel or stored without danger on a storage medium. For instance, computer hardware does not manipulate text, it merely manipulates bytes, so a text encoding is a description of how text should be transformed into bytes. Similarly, HTTP does not allow all characters to be transmitted safely, so it may be necessary to encode data using base64 (uses only letters, numbers and two safe characters). When encoding or decoding, the emphasis is placed on everyone having the same algorithm, and that algorithm is usually well-documented, widely distributed and fairly easily implemented. Anyone is eventually able to decode encoded data. Encryption, on the other hand, applies a transformation to a piece of data that can only be reversed with specific (and secret) knowledge of how to decrypt it. The emphasis is on making it hard for anyone but the intended recipient to read the original data. An encoding algorithm that is kept secret is a form of encryption, but quite vulnerable (it takes skill and time to devise any kind of encryption, and by definition you can't have someone else create such an encoding algorithm for you - or you would have to kill them). Instead, the most used encryption method uses secret keys : the algorithm is well-known, but the encryption and decryption process requires having the same key for both operations, and the key is then kept secret. Decrypting encrypted data is only possible with the corresponding key. See encoding as a way to store or communicate data between different systems. For example, if you want to store text on a hard drive, you're going to have to find a way to convert your characters to bits. Alternatively, if all you have is a flash light, you might want to encode your text using Morse. The result is always "readable", provided you know how it's stored. Encryption means you want to make your data unreadable, by encrypting it using an algorithm. For example, Caesar did this by substituting each letter by another. The result here is unreadable, unless you know the secret "key" with which is was encrypted. Encoding Vs Compression Encoding is representing a piece of information in other form. Say for example, one can represent 10 as 0xA. This is hexadecimal encoding. Compression is done solely to lessen the number of symbols to represent given piece of information. It is achieved with the help of specific encoding of information. Encoding is used at various places but audio/video encoding is more known encoding to us. This leads to this confusion. As different types of encoding gives different types of compression, it combines encoding & compression. But encoding doesn't always compress the data. Those examples are in communication theory. NRZ & NRZI are example of encoding which doesn't compress data. In MQInput node,we can easily do the encoding setup by setting the below properties At HTTP node,we can do Compression (Compression is the only Encoding that can be done at HTTPInput node). What is URL Encoding? When you pass information through a URL, you need to make sure it only uses specific allowed characters like: alphabetic characters, numerals, and a few special characters that have meaning in the URL string. Any other characters should be encoded so that they don't cause problems. The most commonly encoded character is the character. You see this character whenever you see a plus-sign (+) in a URL. This represents the space character. The plus sign acts as a special character representing a space in a URL. The most common way you'll see this is in a mailto link that includes a subject. If you want the subject to have spaces in it, you can encode them as pluses: mailto:email?subject=this+is+my+subject How Do You Encode a URL? Simply replace the special characters with their encoding string. This will nearly always begin with a %. If you don't want to do it by hand, you can use a script such as is found on the JavaScript site: Encoding Web Addresses. How URL_Decoding can be done in Message Broker? I. When the HTTP client sends the Request-Type as “GET” and the Content-type as “URL-Encoded”,then our Message broker HTTPInput node by itself can decode the url-encoded input message . To extract the decoded message ,we have to enable the “parseQueryString” property in the HTTPInput node as below. Then the decoded message will be present in the below path.We can extract the message from this path for further use. For eg: SET Environment.Variables.OriginalMessage = CAST(InputLocalEnvironment.HTTP.Input.QueryString.Input AS BLOB CCSID 1208); II. When the HTTP client sends the Request-Type as “POST” and the Content-type as “URL-Encoded”,then our Message broker HTTPInput node cannot by itself decode the url-encoded input message . The following method can be used to achieve such scenarios. Introduce a “Javacompute node” after HTTPInput node. String result = java.net.URLDecoder.decode("=%3cn%3aMessage+xmlns%3an%3d%22http%3a%2f%2f %3e%5d%5d%3e%3c%2fMsg%3e%3c%2fn%3aMessage%3e", "UTF-8"); Refer the message in a variable or directly as shown in the above example. Note : No need for checking “parseQueryString” option in HTTPInput node.

MQ Cluster - Quick reference for understanding

Concept
If we define a queue as Cluster queue,then the MQ will automatically create the Remote Queue definitions in other cluster queue managers as well.
In a cluster,we need not create transmission queue.Its automatically created by MQ for routing messages. This single transmission queue can be used to carry messages to any other queue manager in the cluster.
All the queue managers that join a cluster agree to work in this way. They send out information about themselves and about the queues they host, and they receive information about the other members of the cluster.
This information is stored in repositories. Most queue managers retain only the information that they need, that is, information about queues and queue managers with which they need to communicate. Each queue manager keeps the information in a partial repository. Some designated queue managers retain a full repository of all the information about all queue managers in the cluster.
When a new Queue manager joins a cluster,we need to manually create cluster sender channel and cluster receiver channel.All other channels required for communication are automatically created.
Queues that are accessible by any other queue manager in the cluster is called ‘Cluster queues’.

Just like Distributed queueing,
From an external application we can put messages from any queuemanager in the cluster.But we can only get messages from the queuemanager which hosts the queue.

Queue manager joining a cluster should have cluster sender channel and cluster receiver channel.
QM3 joins cluster CLUSTEST.It has 2 full repositories,QM1 and QM2.
(Channel name should always be w.r.t. receiver side)
Then QM3 cluster sender channel to QM1 is CLUSTEST.QM1.and this is the channel name at receiver side for QM1.
QM3 cluster receiver channel from QM1 is CLUSTEST.QM3.And this is the sender channel for QM1.
If we introduce a Queue manager to one of the Full repositories,it is sufficient.The cluster channels carry message s in the clusters as well the information about clusters.
How cluster works?
When a Queue manager newly gets added to cluster,first a cluster sender channel is manually created,to introduce itself to one of the full repositories of the cluster.The full repository queue manager then automatically creates cluster sender channel to the newly joined queue manager and sends information about the cluster.

SYSTEM.CLUSTER.TRANSMISSION.QUEUE is the cluster transmission queue used by queue managers in cluster.
SYSTEM.CLUSTER.REPOSITORY.QUEUE is the queue which holds repository information of the cluster

Using Cluster we can achieve,
1)Work load balancing(If same queue is defined in more than 1 queue managers in a cluster)
 Cluster Workload algorithm
Cluster Workload exits

To achieve this,we need to define the same Cluster queue in more than one Cluster Queue managers.
2)High availability (by creating multiple queues in cluster in queue managers)
To achieve this,it is enough if we create Cluster queue in one Queue manager.Even if that Queue manager is down,the application can send messages to that queue via other Queue managers in the Cluster.But MQGet is not possible unless and until the Cluster Queue is defined in all the Cluster Queue manager.

SSL configurations in Message Broker

I created a document about my POCs on SSL One-way and Two-way ...I am presenting the document for you ..Hope this helps for those who are working with SSL in WMB

1.    Objective

To execute SSL One-way and Two-way authentication in Message broker.

This document focus only on the SSL configurations and execution.This document will not talk about the Webservices and WSDL configurations.

2.    Assumptions

We are simulating SSL Client and Server One-way and Two-way authentications by having two flows deployed in two execution groups.

All the properties set for the Client and Server flow should use Execution group wide properties and should not use broker-wide properties.This helps to easily differentiate between the SSL client and SSL server.

We are going to use Selfsigned certificate for Testing purpose.

For Production,use CA signed certificate only.

default is the SSL Server Execution group

TestSSLis the SSL Client Execution group

3.    Prerequisite Requirements

We need to develop two message flows.One acting as SSL server and the other acting as SSL client.

3.1.        SSL Server

SOAP Input node -> Compute node -> SOAP Reply node

SOAPInput node -Properties

Use HTTPS -Checked

3.2.        SSL Client

MQ Input node ->SOAP Request node ->MQOutput node

SOAPRequest node-Properties

Web service URL – eg:   https://localhost:7800/Calculator

Protocol                 - SSL

4.    SSL One-way Configurations

Client authenticates the Server.

Server has Keystore.Client has Truststore,where the Server’s certificate in Truststore will be verified during SSL handshake for authentication.

4.1.        Service side configurations

Create keystore for Server

keytool -genkey -alias selfsigned2 -keyalg RSA -keypasspassoneway4  -keystore keystore2.jks -storepasspassoneway4

Export certificate to keystore

keytool -export -file myselfsigned2.cert  -keypasspassoneway4  -keystore keystore2.jks  -storepasspassoneway4  -alias selfsigned2

Certificate and KeystoreVerifications

keytool -list -v -keystore  keystore2.jks -storepasspassoneway4

keytool -printcert -file myselfsigned2.cert

keytool -list -v -keystore Truststore2.jks -storepasspassoneway4

Execution group configurations

mqsichangepropertiesBroker1  -e default -o ComIbmJVMManager -n keystoreFile  -v D:\SSL\keystore2.jks

mqsisetdbparmsBroker1     -n Keystore2::passoneway4   -u ignore   -p passoneway4

mqsichangepropertiesBroker1    -e default  -o ComIbmJVMManager -n keystorePass   -v Keystore2::passoneway4

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststoreFile -v “”

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststoreType -v “”

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststorePass -v “”

mqsichangepropertiesBroker1    -e default -o HTTPSConnector   -n sslProtocol -v SSL

Verifications

mqsireportpropertiesBroker1    -e default -o ComIbmJVMManager –r

mqsireportpropertiesBroker1   -e default -o HTTPSConnector -r

4.2.        Client side configurations

Import certificate to Truststore

keytool -importcert -alias selfsigned2 -file myselfsigned2.cert  -keystore Truststore2.jks

Execution group configurations

mqsichangepropertiesBroker1     -e TestSSL -o ComIbmJVMManager -n truststoreFile   -v D:\SSL\Truststore2.jks

mqsichangepropertiesBroker1    -e TestSSL -o HTTPSConnector   -n sslProtocol -v SSL

mqsisetdbparmsBroker1     -n Truststore2::passoneway4   -u ignore   -p passoneway4

mqsichangepropertiesBroker1     -e TestSSL  -o ComIbmJVMManager -n truststorePass   -v Truststore2::passoneway4

mqsireportpropertiesBroker1    -e TestSSL -o ComIbmJVMManager –r

mqsireportpropertiesBroker1   -e TestSSL -o HTTPSConnector–r

4.3.        Testing

When you test SSL client and SSL server flows,you will be getting the response without any issues.

4.4.        Debugging

If you are not getting any response,checkfor specific errors in Debug mode and also in <Broker Work path>/components/<Brokername>/<EG uuid>/console file.

5.    SSL Two-way configurations

Client authenticates the Server.And also Server authenticates the Client.

Server has Keystore.Client has Truststore,where the Server’s certificate in Truststore will be verified during SSL handshake for authentication.

Similarly Client has keystore.Server has Truststore ,where the Client’s certificate in Truststore will be verified during SSL handshake for authentication.

Hence this is called as Mutual authentication.

5.1.        Service side configurations

Create keystore for Server

keytool -genkey -alias selfsigned2 -keyalg RSA -keypasspassoneway4  -keystore keystore2.jks -storepasspassoneway4

Export certificate to keystore

keytool -export -file myselfsigned2.cert  -keypasspassoneway4  -keystore keystore2.jks  -storepasspassoneway4  -alias selfsigned2

Import certificate to Truststore

keytool -importcert -alias selfsigned3 -file myselfsigned3.cert  -keystore Truststore3.jks

Certificate and KeystoreVerifications

keytool -list -v -keystore  keystore2.jks -storepasspassoneway4

keytool -printcert -file myselfsigned2.cert

keytool -list -v -keystore Truststore2.jks -storepasspassoneway4

Execution group configurations

mqsichangeproperties  Broker1    -e default -o ComIbmJVMManager -n keystoreFile  -v D:\SSL\keystore2.jks

mqsisetdbparms Broker1     -n Keystore2::passoneway4   -u ignore   -p passoneway4

mqsichangeproperties Broker1    -e default  -o ComIbmJVMManager -n keystorePass   -v Keystore2::passoneway4

mqsisetdbparmsBroker1     -n Truststore3::passtwoway4   -u ignore   -p passtwoway4

mqsichangepropertiesBroker1    -e default  -o ComIbmJVMManager -n truststorePass   -v Truststore3::passtwoway4

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststoreFile -v D:\SSL\Truststore3.jks

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststoreType -v JKS

mqsichangepropertiesBroker1   -e default -o ComIbmJVMManager -n truststorePass -v Truststore3::passtwoway4

mqsichangepropertiesBroker1    -e default -o HTTPSConnector   -n sslProtocol -v SSL

mqsichangepropertiesBroker1    -e default  -o HTTPSConnector -n clientAuth -v true

Verifications

mqsireportproperties Broker1    -e default -o ComIbmJVMManager –r

mqsireportproperties Broker1   -e default -o HTTPSConnector -r

5.2.        Client side configurations

Create keystore for Server

keytool -genkey -alias selfsigned3 -keyalg RSA -keypasspasstwoway4  -keystore keystore3.jks -storepasspasstwoway4

export certificate  to keystore

keytool -export -file myselfsigned3.cert  -keypasspasstwoway4  -keystore keystore3.jks  -storepasspasstwoway4  -alias selfsigned3

Import certificate to Truststore

keytool -importcert -alias selfsigned2 -file myselfsigned2.cert  -keystore Truststore2.jks

Execution group configurations

mqsichangeproperties Broker1     -e TestSSL -o ComIbmJVMManager -n truststoreFile   -vD:\SSL\Truststore2.jks

mqsichangeproperties Broker1    -e TestSSL -o HTTPSConnector   -n sslProtocol -v SSL

mqsisetdbparms Broker1     -n Truststore2::passoneway4   -u ignore   -p passoneway4

mqsichangeproperties Broker1     -e TestSSL  -o ComIbmJVMManager -n truststorePass   -v Truststore2::passoneway4

mqsichangepropertiesBroker1  -e TestSSL -o ComIbmJVMManager -n keystoreFile  -v D:\SSL\keystore3.jks

mqsichangepropertiesBroker1    -e TestSSL -o HTTPSConnector   -n sslProtocol -v SSL

mqsisetdbparmsBroker1     -n Keystore3::passtwoway4   -u ignore   -p passtwoway4

mqsichangepropertiesBroker1    -e TestSSL -o ComIbmJVMManager -n keystorePass   -v Keystore3::passtwoway4

mqsireportpropertiesBroker1    -e TestSSL -o ComIbmJVMManager –r

mqsireportpropertiesBroker1   -e TestSSL -o HTTPSConnector -r

5.3.        Testing

When you test SSL client and SSL server flows,you will be getting the response without any issues.

5.4.        Debugging

If you are not getting any response,checkfor specific errors in Debug mode and also in <Broker Work path>/components/<Brokername>/<EG uuid>/console file.

Loved this SOA Presentation...very Catchy

Thought of sharing this video presentation which I liked a lot ..Hope you all enjoy... http://www.youtube.com/watch?v=A3_QlYJRVvk

HTTP in Message Broker

HTTP nodes in Message Broker

The HTTP-Input node accepts a request and theHTTP-reply node  replies to the destination

Various HTTP nodes in Message Broker

HTTP Input

HTTP Request

HTTP Reply

Through HTTPInput node ,we can listen to HTTP requests from Clients.So,if we use HTTPInput node ,then our  flow becomes the HTTP Server which is exposing its service as Webser vice.

The path url is property will get the HTTP requests intended to this webservice.Sample could be /CustomerTest

Hence the HTTP client should send the requests to the HTTP server as http://<server_ip>:7080 /CustomerTest

7080 – is the port of broker http listener.It is biphttplistener

This is the only HTTP port available for Broker.So,if we want to call another HTTP Service,we need to differentiate it based upon the path url. Eg: /EmployeeTest

If we want,we can also enable http port of execution groups.

To view Brokerwide listener

mqsireportproperties MyBroker -b httplistener -o AllReportableEntityNames -r

(To disable Brokerwide Listener set startListener='false' in mqsichange properties)

HTTPListener

  uuid='HTTPListener'

  enableSSLConnector='false'

  threadPoolSize=''

  traceOverrideLevel=''

  traceOverrideSize=''

  traceLevel='none'

  traceSize='102400 KB'

  javaDebugPort=''

  startListener='true'

HTTPConnector

  uuid='HTTPConnector'

  address=''

  port='7080'

  allowTrace=''

  maxPostSize=''

  acceptCount=''

  bufferSize=''

  compressableMimeTypes=''

  compression=''

  connectionLinger=''

  connectionTimeout=''

  maxHttpHeaderSize=''

  maxKeepAliveRequests=''

  maxSpareThreads=''

  maxThreads=''

  minSpareThreads=''

  noCompressionUserAgents=''

  restrictedUserAgents=''

  socketBuffer=''

  tcpNoDelay=''

  enableLookups='false'

HTTPSConnector

  uuid='HTTPSConnector'

  algorithm='Platform Default'

  clientAuth='Platform Default'

  keystoreFile='Platform Default'

  keystorePass='********'

  keystoreType='Platform Default'

  truststoreFile='Platform Default'

  truststorePass='********'

  truststoreType='Platform Default'

  sslProtocol='Platform Default'

  ciphers='Platform Default'

  address=''

  port=''

  allowTrace=''

  maxPostSize=''

  acceptCount=''

  bufferSize=''

  compressableMimeTypes=''

  compression=''

  connectionLinger=''

  connectionTimeout=''

  maxHttpHeaderSize=''

  maxKeepAliveRequests=''

  maxSpareThreads=''

  maxThreads=''

  minSpareThreads=''

  noCompressionUserAgents=''

  restrictedUserAgents=''

  socketBuffer=''

  tcpNoDelay=''

  enableLookups='false'

=====================================================================

To view Executiongroup HTTP listener

mqsireportproperties MyBroker  -e default -o HTTPConnector -r

HTTPConnector

  uuid='HTTPConnector'

  userTraceLevel='none'

  traceLevel='none'

  userTraceFilter='none'

  traceFilter='none'

  port='0'

  address=''

  allowTrace=''

  maxPostSize=''

  acceptCount=''

  bufferSize=''

  compressableMimeTypes=''

  compression=''

  connectionLinger=''

  connectionTimeout=''

  maxHttpHeaderSize=''

  maxKeepAliveRequests=''

  maxSpareThreads=''

  maxThreads=''

  minSpareThreads=''

  noCompressionUserAgents=''

  restrictedUserAgents=''

  socketBuffer=''

  tcpNoDelay=''

  explicitlySetPortNumber=''

  enableLookups=''

  enableMQListener=''

  shutdownDelay=''

  allowCrossConnectorPolling=''

  autoRespondHTTPHEADRequests=''

=====================================================================

To switch to the embedded execution group-wide listener:

mqsichangeproperties MyBroker -b httplistener -o HTTPListener -n startListener -v false

mqsichangeproperties MyBroker -e default -o ExecutionGroup -n httpNodesUseEmbeddedListener -v true

--------------------------------------------------------------------------------------

To switch to the Broker-wide listener:

mqsichangeproperties MyBroker -b httplistener -o HTTPListener -n startListener -v true

mqsichangeproperties MyBroker -e default -o ExecutionGroup -n httpNodesUseEmbeddedListener -v false

--------------------------------------------------------------------------------------

How to check HTTP port assigned for an execution group?

C:\Program Files\IBM\MQSI\8.0.0.1>mqsireportproperties RadBroker -e default -o H

TTPConnector -a

HTTPConnector

  uuid='HTTPConnector'

  userTraceLevel='none'

  traceLevel='none'

  userTraceFilter='none'

  traceFilter='none'

  port='0'

  address=''

  allowTrace=''

  maxPostSize=''

  acceptCount=''

  bufferSize=''

  compressableMimeTypes=''

  compression=''

  connectionLinger=''

  connectionTimeout=''

  maxHttpHeaderSize=''

  maxKeepAliveRequests=''

  maxSpareThreads=''

  maxThreads=''

  minSpareThreads=''

  noCompressionUserAgents=''

  restrictedUserAgents=''

  socketBuffer=''

  tcpNoDelay=''

  explicitlySetPortNumber=''

  enableLookups=''

  enableMQListener=''

  shutdownDelay=''

  allowCrossConnectorPolling=''

  autoRespondHTTPHEADRequests=''

--------------------------------------------------------------------------------------

HTTP Asynchronous nodes

You can make HTTP requests and receive a response asynchronously using the HTTPAsyncRequest and HTTPAsyncResponse nodes.

HTTP is synchronous: a client issues a request and waits for the corresponding response before anything else is done.
But we can make the client to act for Asynchronous HTTP client as well.In this way,there wont be any performance issues.

Basically, The HTTP client is only aware of a synchronous call.

Various scenarios of client connections:

1)Same client opening many number of connections to HTTP Server (HTTP URL: http://<server_ip>:7080 /CustomerTest)

2)Multiple clients opening multiple number of connections to HTTP Server :- same url (HTTP URL: http://<server_ip>:7080 /CustomerTest)

Workload balancing can be achieved via Load Balancer

If  I have multiple HTTP clients want to communicate with 2 brokers in load balanced way,but there is only one url, HTTP URL: http://<server_ip>:7080 /CustomerTest ,both the brokers are listening at same port.

When there is no load balancer,the client will have an url set at their request.So,only either one of the broker can be set at the url path.

In the case,if we use load balancer,then we can url the load balancer ip at the HTTP request url of HTTP client.By this way we can route the requests to both the brokers as the load balancer will act as network dispatcher.

Moving HTTP connection processing away from broker by using a proxy

The proxy is a servlet engine running inside Websphere Application Server just like Message broker internal process.

Message broker biphttpistener can support maximum upto 1200 concurrent sessions.

If we want more than 1200 sessions,then we can go for proxy engine.

Proxy engine is capable of handling more number of concurrent sessions than the default broker http listener.

HTTP Persistent and Non-Persistent connections

When HTTP request is made from a client,a new TCP connection is opened from client to Server.Once the response is sent by HTTP server through this TCP connection,the connection is terminates.For the next request from the same client ,a new TCP connection is opened.This is called non-persistent connections.This is also called as Short-lived connections.If the clients want to make individual connections then this type of connections can be choosen.But considering the memory and resource utilisations due to session creations ech and everytime would be a overhead.This could be preferred when many number of clients want to have individual connections with HTTP server.

For non-persistant connections,there may be ‘n’ number of clients connecting to the HTTP server.We can restrict the maximum number of concurrent connections by limiting ‘maxthreads’  property.Default is 250.

Command to change is: mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxThreads -v 2000

But machine resources, such as amount of addressable memory, determine the absolute maximum number of concurrent HTTP client connections that you can make to Message Broker, and these resources may be exhausted before the maxThreads limit is reached.

Increase the heap size of the JVM running within the biphttplistener process to let the JVM allocate more threads for the incoming connections. The default setting for the listener JVM is 192 MB, but you should increase it to 512 MB when dealing with large numbers of concurrent connections. To change the value, modify the Message Broker registry.

(http://www.ibm.com/developerworks/websphere/library/techarticles/0608_braithwaite/0608_braithwaite.html)

Hence always better to prefer HTTP persistent connections.This is also called as Long-Lived connections.This can be preferred when small number of clients want to have high volume of throughput from HTTP server.(When small number of clients are there,there will be small number of connections opened.But they are opened for a long time to serve all the requests instantly through the TCP session path).

There is  a property called maxKeepAliveRequests that specifies how many number of requests can be made in a single connection at the maximum.Default is 100. The next request the client sends creates a new socket and again can send up to 100 requests.        

Command to change this property according to our requirement

mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxKeepAliveRequests -v 0.

Promoted Properties vs UDP

Broker properties are divided into four categories:
Properties that relate to a specific node
Properties that relate to nodes in general
Properties that relate to a message flow
Properties that relate to the execution group
Experiment1
* Promote Property for main flow - Input Mq node Queue property and Output node Queue property
The properties are seen when seeing properties of message flow
Properties are promoted to message flow level
After creating bar file ,just the overriding properties are changing with new values
After overriding with new values,the bar file is just saved WITHOUT RECOMPILATION.
If we recompile,again it get backs to the same old value;the overridden values are not getting effected.
Just deploy now;The overriding properties works fine :)
Experiment 2
* Subflow is used in the middle of MQInput and MQOutput node in the main flow
*The subflow has a MQOutput node whose Queuename is promoted
*As it is promoted,the queue name has become the subflow's configurable property
*Now,when subflow is referred in the main flow,the subflow's property is shown.But it says,the subflow's promoted property cannot be overridden ."Property override is not supported on the subflow node"

WMB and Error Handling

(WMB) Error handling

When we design any message flow, we often do not give more emphasis on error handling. Well as per my experience I found this error handling techniques & design principles more crucial than designing the happy path.
So here I am with few details on how to handle unhappy path in WMBV6.0 with information about the message flow error behavior.


Design Consideration

·                     Connect the Failure terminal of any node to a sequence of nodes that processes the node's internal exception (the Failure flow).

·                     Connect the Catch terminal of the input node or a TryCatch node to a sequence of nodes that processes exceptions that are generated beyond it (the Catch flow).

·                     Insert one or more TryCatch nodes at specific points in the message flow to catch and process exceptions that are generated by the flow that is connected to the Try terminal.

·                     Ensure that all messages that are received by an MQInput node are processed within a transaction or are not processed within a transaction.

Understanding the Flow Sequence

·                     When an exception is detected within a node, the message and the exception information are propagated to the node's Failure terminal ( Diagnostic information is available in the ExceptionList). 

·                     If the node does not have a Failure terminal or if it is not connected, the broker throws an exception and returns control to the closest previous node that can process the exception. This node can be a TryCatch node  (Root & LocalEnvironment are reset to the values they had before) or the MQInput node .

·  If the catch terminal of the MQInput node is connected, the message is propagated there (ExceptionList entries are available; Root & LocalEnvironment are reset to the values they had before).
      1) If message is transactional and catch terminal is connected ,then message goes to catch terminal and thrown to Input node due to Throw node in Catch.And then backout count is checked.And based upon backout count,message is retried.Finally message goes to Failure terminal if it is connected.If Failure terminal is not connected,then Backout Q or System DLQ is checked.
      2)  If message is not transactional and catch terminal is connected,then message goes to catch terminal and thrown to Input node due to Throw node in Catch. But backout count is not checked and also does not go to Failure terminal even if it is connected and it is discarded.


What if in Failure path,there is some error?
Error path should be properly handled by Failure terminal's subsequent nodes.Otherwise,successive errors will be discarded.

Otherwise if the catch terminal is not connected, the transactionality of the message is considered.

·                     If the message is not transactional, the message is discarded. Otherwise , if it is transactional, the message is returned to the input queue, and it is read again, whereupon the backout count is checked.

·                     If the backout count has not exceeded its threshold, the message is propagated to the output terminal of the MQInput node for reprocessing. Otherwise if it is exceeded & if the failure terminal of the MQInput node is connected then the message is propagated to that path. (Root is available but ExceptionList is empty)

·                     If the failure terminal of the MQInput node is not connected, the message is put on an available queue, in order of preference; message is put in backout queue, if one is defined; otherwise in dead-letter queue, if one is defined. If the message cannot be put on either of these queues, it remains on the input queue in a retry loop until the target queue clears.(It also records the error situation by writing errors to the local error log)

The below are the info that can be captured from the ExceptionList:

·         MessageId of the incoming message

·         Flow name(Name of the message flow in which exception has occurred)

·         Node name in which the exception has occurred

·         Error time (Time when the exception has occurred)

·         Error Number (Error Number for the exception which is generated by Message broker)

·         Error Severity(Severity of the exception)

·         ErrorDetails(Complete description of the error)

My testing scenarios:

With Javacompute node:

Input queue -àHas Backout queueàBackout threshold =3

1)      Scenario:

Javacompute node has exception catching code as below.

Message flow  nodes’ Failure and Catch  are not connected

 Transactionality is “YES”,

catch (SQLException sqx ){

           MbUserException mbue = new MbUserException(this, "evaluate()", "","", sqx.toString(), null);

             throw mbue;

         }

      Observation:

·         Error thrown to MQInput node

·         Message is retrying with Backout count in MQMD as 1,2,3 consecutively

2)Scenario:

   Javacompute node has exception catching code

    MQInput node’s catch is connected

      Transactionality is “YES”

     Exception handling subflow ends with MQOUTPUT node (ERRORQ)  

      Observation:

·         Error thrown to MQInput node

·         Exception once thrown to MQInput node,is sent to catch terminal

·         The message  is written to MQOUTPUT node (ERRORQ).This message written has only original message

·         Retry is not actually performed because the message is not thrown to the input queue.

         3)Scenario

                        Javacompute node does not have exception catching code .Just like below,

catch (SQLException sqx ){

           

            }

                   MQInput node’s catch is connected

      Transactionality is “YES”

     Exception handling subflow ends with MQOUTPUT node (ERRORQ)  

                 The below Exceptionlist populating message is written in subflow,  

                    DECLARE start REFERENCE TO InputExceptionList.*[1];

             WHILE  start.Number IS NOT NULL DO

                 

                  SET OutputRoot.XML.Exception.messageNumber = start.Number;

                  SET  OutputRoot.XML.Exception.messageText = start.Text;

           

                  MOVE start LASTCHILD;

             END WHILE;

Observation:

Behaved same as Scenario 2 but the message at output is,

hi

<Exception>

 <messageNumber>6233</messageNumber>

 <messageText>Problem encountered obtaining JDBC connection</messageText>

</Exception>

4)Scenario

  Only if it is connectivity failure,the code has to retry.

 Otherwise the code should not retry