Rules for ISO Interceptor

Rules in the ISO Interceptor provide a robust mechanism for dynamically modifying intercepted ISO requests and responses. By applying rules, users can tailor the message forwarded to the client and the response returned to the caller based on specific conditions, enhancing the accuracy and flexibility of ISO testing scenarios.

Interceptor applies rules in two sections — Client Request Rules and Client Response Rules.

Client Request Rules : Modify the ISO message before it is forwarded to the client URL — for example ireq.setBody(...) — so it matches what the client endpoint expects.

Client Response Rules : Intercept the ISO response coming back from the client and reshape it before it is returned to the caller — for example ires.setBody(...).

Example :

We will apply rules to the 0100_Auth request created in the previous section and validate the updated response.

Add the scripts under the relevant section. The example below stamps a fresh transmission date/time onto the live request before it is forwarded, and injects an authorization identification response onto the live response before it is returned:

// Client Request Rule — runs before the message is forwarded to the client URL
// Stamp a fresh transmission date & time (field 7), format MMDDhhmmss
ireq.setBody("7", fn.generateDate("MMddHHmmss"));

// Client Response Rule — runs on the response before it is returned to the caller
// Inject an Authorization Identification Response (field 38)
ires.setBody("38", fn.generateRandomNumber(6));

Now navigate to the Studio module and execute this Interceptor request following the steps from the previous section, using the Interceptor's endpoint & port (not the Sandbox host port). The Interceptor applies the rules, so the message forwarded to the client carries the freshly stamped field 7, and the response returned to the caller carries the rule-set field 38.

Compare the response without the rules to the response after the rules to see the difference:

// Response WITHOUT rules — field 38 is the static template value
<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="38" value="008001"/>
  <field id="39" value="00"/>
  <field id="43" value="Cranium"/>
  <field id="49" value="826"/>
  <field id="61" value="1651412110"/>
</isomsg>

// Response AFTER rules — field 38 is set to a random 6-digit value by the ires rule
// (field 7 was also stamped on the forwarded request by the ireq rule)
<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="38" value="497312"/>
  <field id="39" value="00"/>
  <field id="43" value="Cranium"/>
  <field id="49" value="826"/>
  <field id="61" value="1651412110"/>
</isomsg>

The Client Request Rule sets field 7 (Transmission Date & Time) on the message forwarded to the client, and the Client Response Rule sets field 38 (Authorization Identification Response) to a random 6-digit value on the response returned to the caller. Because field 38 is generated dynamically, its value changes on every execution — 497312 above is just one example.

• To better analyze responses and follow the execution flow of Interceptor requests, please refer to the Analytics submenu.

By integrating Interceptor rules into your workflow, you can achieve more streamlined development cycles, better validation, and a smoother testing experience.