Persistent Connections to ISO Host

Persistent Connections to ISO Host

Up until v0.9.X the connections to the ISO server from API server was transient i.e one connection per request. Starting v0.10.X, it will be possible to cache connections to the ISO host and reuse them across multiple messages. In order to do, two changes have been done in the yaml spec definition (all examples have been picked up from iso_specs.yaml) -

Header Fields in Spec definition

   header_fields:
     - name: "$$header_mti$$"
       id: 1
       type: Fixed
       size: 4
       data_encoding: ASCII
       children: []

You'll need to define header fields per spec. These fields will be parsed and the value resulting from them will be used as a key to fetch a particular message. For instance, in this example above, the value of the Message Type (the first four bytes) field will be used to pick the message.

Please note that header_fields are part of the actual message also, and so they're parsed twice i.e In this example, Message Type will appear in the header_fields as well as in every message definition.

Further, the message definition itself should have a header_match clause which is simply a list of values that should match the value of the parsed header_fields. Example -

    messages:
      - name: "1100 - Authorization"
        header_match:
          - "1100"
          - "1110"

In this example, we will use 1100 - Authorization message when the parsed header_fields match 1100 or 1110.

This is good so far as identifying a message is concerned (i.e when a new message comes in, we can figure out if we're looking at a Authorization or a Reversal etc).

The next bit is about matching requests to response

Key Fields in Message Definition

In order to uniquely identify messages (when many of them could be in-flight at the sametime), we need to associate a message with a unique value which is also be present on the response. This is done by marking a field as a "key" field as below -

              - name: "STAN"
                id: 9
                type: Fixed
                size: 6
                data_encoding: ASCII
                key: true
                position: 11

In this example above, we're using STAN as a unique field. A persistent connection to a ISO server is only used when the flight-key used is non-empty (You could mark more than one field as key so long as the response also has those fields and are returned unaltered by the host). If there is no flight-key for a message, we fallback to using connection per message.