A customer came to me with a requirement to interpret their ISO8583 messages and then act accordingly. This is very different from the recent post Faster Payments - ISO8583 Resilience. That article addressed the issue of ensuring the ISO8583 service was actually up and running before sending it transactions. This article is helpful in deciding which IP Address to send the transaction to when there are multiple instances of the service. Also refer to: The Evolution of Application Delivery Part 4: Service Agility.
To better understand what we are doing here lets reference the very handy Wikipedia Article on ISO8583 - Financial transaction card originated messages. As you will see in the section titled "Message Type Indicator", there is a Four Digit identifier used to determine:
The Problem
Why might I wish to route messages based on this information? Lets say you are in the process of upgrading/changing your Transaction Handler. You are interested in routing, or maybe mirroring, only Reconciliation Messages, to the new system an no others. The remainder of the messages, or all of them if you are going to mirror, will still need to be passed to your existing service.
The solution
By implementing F5's LTM (Application Delivery Controller), you can read the ISO8583 message and then perform an action based on this message. LTM isn't natively aware of the 8583 standard so you must tell it what to do. Below is an iRule (TCL script that the LTM can interpret) to route/mirror your traffic as needed:
when CLIENT_ACCEPTED {
TCP::collect
}
## This section collects the first 6 bytes and then uses
## 'switch' to find a match. It allows to you decide where
## to send a request based on its message type.
## You could also use this to simply log without
## performing a pool selection.
when CLIENT_DATA {
set clientData [TCP::payload 6]
switch -glob $clientData {
"??0800" {
pool pool_EchoTestMessage
log local0. "This is a Network Management Message."
}
"??2202" {
# Need to mirror message to the new service for testing
log local0. "Mirroring message to test: $clientData"
pool pool_ISO8583_Service
# Here's the cloning for testing the new service
clone pool pool_NewServiceForTesting
}
}
TCP::release
}
when SERVER_CONNECTED {
TCP::collect
}
## This section allows you to perform an action based
## on the message type of the response from the server.
## You could log the message type or even manipulate
## it before sending it out.
when SERVER_DATA {
set serverData [TCP::payload 6]
log local0. "Response Data raw: $clientData"
switch -glob $clientData {
"??0810" {
pool pool_EchoTestMessage
log local0. "Network Management Message RESPONSE."
}
}
TCP::release
}
At the beginning of this post I referenced the Service Agility post from last month. Applying the above rule delivers enormous flexibility and agility to your solution breaking free from static, fixed designs that hinder growth.
