Persistent Connections

A real payment switch does not open a new connection for every message. It opens one connection and sends a sign-on (a message that says it is ready). Then it keeps that connection open for hours or days. Business messages, echo tests (short messages that check the connection is still alive) and sign-offs (messages that say it is leaving) all go over the same connection. PruTAN can work the same way, on both sides:

Studio, Suites, Interceptor and Stress Lab (PruTAN calls the switch): keep the connection to a host open and use it again for later messages.
Sandbox (the switch calls PruTAN): keep the caller's connection open and answer everything it sends. See Sign-on, Sign-off and Echo for that side.

This page is about the calling side.

To start and stop named connections yourself, see Connection Pool. This includes connections where the switch connects in to Studio.

What "reuse" means

A connection is a TCP socket. Your machine talks to the switch's host and port, and the switch answers on the same socket. Think of it as a phone call.

Not reused: dial, send one message, get the reply, hang up. Every new message dials again. This is how PruTAN has always worked, and it is still the default.
Reused: dial once, then send every later message on the same open call. The ports on both sides stay the same, and there is no new dial.

Keep the connection open

This setting belongs to the workspace, so it applies to every ISO message sent from that workspace. Open Settings, scroll to Connection Configuration and set Keep the connection open (seconds).

Value	What happens
`0`	Close after every message. This is the default, and it is exactly how PruTAN worked before.
`-1`	Never close. The connection stays open until the switch closes it, the setting changes, or PruTAN restarts.
`60`	Close after 60 seconds with no traffic. Any whole number of seconds works. The smallest is 1.

Real switches keep the connection open for good and expect an echo every 30 to 60 seconds. Gateways often close a connection after 60 to 300 seconds with no traffic. There is no millisecond option, because dialling alone takes longer than that.

A change takes effect within about 10 seconds. Going from -1 to 0 closes the open connection. Going from 0 to -1 applies on the next send.

Each workspace keeps one connection per host and port. Two workspaces never share a connection.
The header size must match the switch from the first message. On a kept-open connection, a wrong header size is caught at once, and the response tells you so.
A Stress Lab run opens one connection per virtual user and closes them all when the run ends.

Reading the response

After a send, the connection pill in the response header tells you what happened. Hover over it to see the full details, including the keep-alive count described below.

Connection	Meaning
`per-message`	The workspace setting is 0. PruTAN dialled, sent the message and closed the connection.
`new`	PruTAN dialled a new connection for this message and keeps it open.
`reused`	The message went out on a connection that was already open.
`busy`	Another message from this workspace was using the connection for the whole request timeout.

Trace shows the same information for every past run.

One message at a time

A connection carries only one message at a time. If two requests from the same workspace go to the same host at the same moment, the second one waits for the first reply. It waits up to its own request timeout, and then reports busy. The reply to a message is the first message that comes back with the message type that answers it: an 0210 for an 0200, an 0810 for an 0800. Anything else the switch sends on the connection while you wait is logged and skipped. PruTAN never resends a message.

Automatic echo (keep-alive)

A switch that keeps a connection open usually closes it when nothing arrives for a while. Your side is expected to send an echo test when the connection is quiet. PruTAN can do that for you.

There is no separate echo setting. Instead, you pick the request that is the echo and give it a number:

Create an echo request in Studio that points at the switch. A typical body:
```
<isomsg>
  <field id="0" value="0800"/>
  <field id="7" value="{{$generateDate(MMddHHmmss)}}"/>
  <field id="11" value="{{$generateRandomNumber(6)}}"/>
  <field id="70" value="301"/>
</isomsg>
```
Field 0 is the message type. 0800 is a network message. Field 70 says which kind of network message it is: 001 is a sign-on, 002 is a sign-off, 301 is an echo test.
Open the request's Settings tab and fill in Send when idle for (s), for example 30. Save.

From then on, whenever nothing has been sent to that host for 30 seconds, PruTAN sends this request by itself. It uses this exact body, spec and header size, with the variables filled in from the workspace's environment. The switch sees traffic and keeps the connection open.

Because the echo is this saved request, anything the request carries goes out with it. If your switch expects a message header, put it in the request body as a <header> element, the same way you do for sign-on and sign-off. There is no separate header setting for the echo.

How it behaves:

It only uses a connection that is already open. It never dials. The first business message opens the connection, and the echo keeps it alive after that.
Business traffic resets the timer, so no echo goes out while a suite is running. Echoes fill the quiet gaps. They continue after the suite ends, until the connection closes.
Each echo runs like a normal send: pre-request script, send, validation rules. It is not written to History and costs no credits. The next business message shows Keep-alive: 4 sent, last 12s ago in its connection pill, or last failure: ... if an echo got no reply.
A failed echo closes the connection. The next business message dials a new one.
Any ISO request can have the number, so one workspace can send echoes to several switches, with one request per host. If two requests point at the same host, only one of them is used.

PruTAN refuses to save the number when the echo cannot work:

The workspace setting is 0. No connection is kept open, so there is nothing to send the echo on.
The number is not shorter than the workspace setting (when that setting is a positive number). The connection would close before the echo is sent.

To stop the echo, clear the box, or set the workspace setting back to 0. Either change takes effect within about 10 seconds, even when there is no other traffic.

This echo does not answer echo tests that the switch sends to you. On the calling side, PruTAN only reads replies to its own messages. If the switch expects you to answer its echoes, run that switch against a Sandbox instead.

Sign-on and other handshakes

PruTAN sends nothing on its own, except the echo you set up. A sign-on, key exchange or cutoff is a request that you write and send, like any other message. If the switch wants a sign-on before business messages, send your sign-on request first. It goes out on the same connection, and the 0200 that follows goes out on the same open, signed-on connection.

When the connection drops and PruTAN dials again, the switch will usually want a new sign-on. Send it again yourself, or put it at the start of your suite.

Pausing a rule

To test how a client handles a slow host, a Sandbox or Interceptor rule can pause before it answers:

fn.sleep(3000);
res.setBody("39", "00");

The pause holds only that one connection. Other callers keep getting answers. The pause is capped at 10 seconds by default. See Function Reference.

FeaturesCI/CD

FeaturesConnection Pool