ISO Rules

PruTAN's Sandbox module offers powerful rules features to enhance user experience during the development process by conditionally manipulating the response for ISO requests. These rules enable conditional adjustments to response data, ensuring tailored and precise responses during testing.

Example:

We will utilize the Auth_0100_0110 request example simulated in Sandbox in the previous section to apply rules and validate the response.

// Request Body
<isomsg>
  <header/>
  <field id="0" value="0100"/>
  <!-- MTI (Message Type Identifier) for Authorization request -->
  <field id="3" value="210000"/>
  <!-- Processing Code: 210000 for Card Authorization -->
  <field id="4" value="000000002000"/>
  <!-- Transaction Amount: 20.00 (amount in cents) -->
  <field id="22" value="801"/>
  <!-- POS Entry Mode -->
  <field id="43" value="Cranium"/>
  <!-- Card Acceptor Name/Location -->
  <field id="49" value="826"/>
  <!-- Transaction Currency Code (826 = GBP) -->
  <field id="61" value="1651412110"/>
  <!-- Reserved Private -->
</isomsg>

// Response Body
<isomsg>
  <header/>
  <field id="0" value="0110"/>
  <!-- MTI (Message Type Identifier) for Authorization response -->
  <field id="3" value="{{$echo()}}"/>
  <field id="4" value="{{$echo()}}"/>
  <field id="22" value="{{$echo()}}"/>
  <field id="35" value="{{$echo()}}"/>
  <field id="38" value="008001"/>
  <!-- Authorization Identification Response -->
  <field id="39" value="00"/>
  <!-- Response Code: 00 (Approved) -->
  <field id="43" value="{{$echo()}}"/>
  <field id="49" value="{{$echo()}}"/>
  <field id="61" value="{{$echo()}}"/>
</isomsg>

Now, we have written a Rules script to update the response conditionally:

// Rules script

// Read PAN & expiry from the request, generate random data,
// then build and set the Track 2 Data (field 35)
accNum = req.getBody("2");
expDate = req.getBody("14");
code = fn.generateRandomNumber(3);
data = fn.generateRandomNumber(10);
req.setBody("35", fn.concatenate(accNum,"=",expDate,code,data));

Now, navigate to the Studio module and execute this request following the steps provided in the previous section using necessary data like URL, reqBody, port, etc. You will get the conditionally updated response.

The request body you send from Studio (the client request) carries the values the rule reads — the PAN in field 2, which is generated dynamically, and the expiry date in field 14:

// Client request body (sent from Studio)
<isomsg>
  <header/>
  <field id="0" value="{{Atm_req_mti}}"/>
  <field id="2" value="{{$generateCard(16)}}"/>
  <!-- PAN (dynamically generated) -->
  <field id="3" value="210000"/>
  <field id="4" value="000000002000"/>
  <field id="14" value="2504"/>
  <!-- Expiration Date (YYMM) -->
  <field id="22" value="801"/>
  <field id="43" value="Cranium"/>
  <field id="49" value="826"/>
  <field id="61" value="1651412110"/>
</isomsg>
// Response body after the rule runs
// (field 35 is built dynamically, so its value changes on every execution)
<isomsg>
  <!-- org.jpos.iso.packager.GenericPackager -->
  <field id="0" value="0110"/>
  <field id="3" value="210000"/>
  <field id="4" value="000000002000"/>
  <field id="22" value="801"/>
  <field id="35" value="{PAN}={expiry}{service code}{discretionary data}"/>
  <field id="38" value="008001"/>
  <field id="39" value="00"/>
  <field id="43" value="Cranium"/>
  <field id="49" value="826"/>
  <field id="61" value="1651412110"/>
</isomsg>

Here, the rule builds field 35 (Track 2 Data) from the card number (field 2) and expiry date (field 14) in the request, plus a random service code and discretionary data, in the format PAN=expiry+service code+discretionary data. Since the PAN and random parts change each run, the body above shows the structure while the screenshot shows one actual value.

PruTAN's Sandbox Rules feature empowers users to fine-tune responses with precision and agility. By harnessing dynamic adjustments based on request conditions, it enhances the testing environment's adaptability and accuracy, ultimately facilitating smoother development cycles.

Rules for a connected switch

Here are two rules you will need as soon as a switch keeps one connection open to the Sandbox. Both use the requests from Sign-on, Sign-off and Echo.

Insist on a sign-on

The Sandbox answers any message it can match, whether the switch has signed on or not. To refuse business messages until the switch has sent a sign-on (the message that says it is ready), store the sign-on in an environment variable and check it.

On SignOn_0800_0810:

env.set("signedOn", "yes");
res.setBody("39", "00");

On SignOff_0800_0810:

env.set("signedOn", "no");
res.setBody("39", "00");

On Auth_0100_0110:

if (env.get("signedOn") != "yes") {
  res.setBody("39", "96");   // whatever your switch uses for "not signed on"
}

env.set writes the value back to the environment. So the value survives from one message to the next, and it also survives a Sandbox restart. The flag belongs to the Sandbox, not to one connection. If two switches are connected, a sign-on from either one counts for both.

Answer slowly

To test how the switch handles a slow host, pause before you answer:

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

The pause holds only that one connection. Other switches keep getting answers. The pause is capped at 10 seconds, so a typing mistake cannot block a connection for minutes. Stress Lab runs no rules, so a pause never affects a load test.

Table of Contents