Warning: A non-numeric value encountered in /home/customer/www/archive.ricston.com/public_html/wp-content/themes/Divi/functions.php on line 5766

When visiting our GitHub page, among our open source projects you’ll discover one called mule-module-iso8583. This project has been sitting there for quite a while but we never had the opportunity to talk about it. That is, until now :).

ISO 8583 is a specification describing a protocol for exchanging financial data in the context of card transactions. This data typically includes card number, purchase amount, PIN, etc… Chances are that when you are purchasing with your card, ISO 8583 is being used to transfer the transaction details to your bank. The protocol is flexible in terms of encoding and message structure. For this reason, you’ll find financial institutions using different flavours of the protocol.

The Mule ISO 8583 Module leverages the j8583 library to read and write ISO 8583 messages. Let’s examine one of the module’s tests to understand how to use it:

Here we have a test putting an ISO 8583 echo request onto the VM queue iso8583.service. The test is expecting back an echo reply from the service asserting its availability. The request’s encoding is ASCII, however, the module can also interpret raw ISO 8583 messages.

On the service side, we have the following code:

The first thing to note is the iso8583-to-message-transformer after the VM inbound endpoint. This takes in an ISO 8583 message from the Mule message payload and spits out a java.util.Map. Each entry in the map represents an ISO message field where the key is a field number and the value is an object of type org.mule.module.iso8583.Field. A Field object contains the field’s value and describes the field’s structure (e.g., field length).

In the transformer, we specify the expected header length of the ISO 8583 request to be 4 bytes. This value changes from one protocol implementation to another. It is also quite possible that a header is not even present. In addition to the header length, we specify the message factory bean to use. We’ll discuss the message factory later but you should know that this property MUST be configured on each ISO 8583 transformer.

Instead of creating a message from scratch, the transformed message is changed from an echo request to an echo reply. A field, identified by the no. 39, is added to the payload. Field no. 39 is defined in the ISO 8583 spec as the response code. Its value is set to ’00’ meaning that the request was processed successfully. The field’s length and type are also set to help the transformer construct the ISO 8583 message

ISO 8583 requires that every message contain a field that identifies its type. In Mule, a transformed ISO message has this field in the inbound property “iso8583.mti”. To specify the MTI for an outgoing ISO request/reply, just add an outbound scoped property named “iso8583.mti” to the message. In our service, the outgoing message’s MTI is set to ‘0810’ to indicate that the message is an echo reply.

The last step is to transform the reply into an ISO 8583 message using the message-to-iso8583-transformer.

One last point to mention is the message factory. The message factory follows a set of rules that say how messages should be parsed and written. These rules are declared in an XML configuration that the message factory’s configPath property points to. Among these rules are ones stating which headers to write as well as which fields to expect, as shown below:

Be sure to check out the j8583 site to view the full list of things you can do with this module.