MTI Mapping and MUX Configuration Question

[scottmishra]

Hi @tilln!

First thanks so much for maintaining this plugin, it's been really helpful!. Quick question about MUX configurations. I am trying to set up negative test cases where our system returns error codes to requests instead of the appropriate response message. One example is that I am sending an MTI 210X (a pre-auth message) and are expecting a 264X (host error code) back from the system. I set up the MTI Mapping to be something like 0123456789 0123451789 0123056789

When the record goes out and comes back we can see: The IN shows 2100 000000035644 0000000011N and The Out shows 2644 000000035644 0000000011N

Looking at the MUX documentation and your comments in https://github.com/tilln/jmeter-iso8583/issues/4 I would have thought 264X would have mapped to 210X, but it looks like the request and response don't get matched together.

Any thoughts you have would be great.

[tilln]

Hi @scottmishra

I think your MTI mapping should match your request/response pair just fine.

A quick Groovy script confirms that:

@Grab('org.jpos:jpos:2.1.6') 
import org.jpos.q2.iso.*
import org.jpos.iso.*
import org.jpos.core.SimpleConfiguration
import org.jdom2.Element

def mux = new QMUX()
mux.setConfiguration(new SimpleConfiguration())
def cfg = new Element('mux')
cfg.addContent(new Element('in').addContent('in'))
cfg.addContent(new Element('out').addContent('out'))
cfg.addContent(new Element('mtimapping').addContent('0123456789 0123451789 0123056789'))
mux.setPersist(cfg)
mux.initService()

def req = new ISOMsg('2100')
req.set(11, '000000035644')
req.set(41, '0000000011N')

def resp = req.clone()
resp.setMTI('2644')

assert mux.getKey(req) == mux.getKey(resp), "No match!"

Could you please share your script or just the relevant part ("ISO8583 Connection Configuration") to make sure everything is set up correctly?

[scottmishra]

Sure thing: Below is another example for another message type: i send an echo (2804) where I would expect back a 2644. Connection Config:

Sampler Example:

If I run the same test, but edited so my system sends back a 2814 instead of a 2644, the MUX is able to align the request and response. Its a real puzzler

[tilln]

@scottmishra A puzzler indeed.

Here are two ideas to do more investigation.

1. Check the MUX In the 30 or so seconds before your Sampler times out you could dump the MUX's Internal Space to check that your message's key is in fact in there with the expected value as per mapping, e.g.

   def baos = new java.io.ByteArrayOutputStream()
   org.jpos.q2.iso.QMUX.getMUX('<INSERT-YOUR-CONNECTION-REFERENCE>-mux').isp.dump(new PrintStream(baos, true, 'UTF-8'), '')
   baos.toString()

   For this it would be easiest to upgrade to plugin v1.2, otherwise the MUX is not as simple to access as its key is generated dynamically.

2. Check the Channel Is there any chance that the DRPChannel you are using is modifying the messages in any way that could impact their matching? If you can easily modify its source code you could insert more logging output there e.g. dump the received message, or call the MUX's getKey method to verify it is mapped to the request.

HTH

[scottmishra]

just wanted to do a quick update, i got owned by work, but I hope to make some adjustments to the Channel class and see what i find out. I hopefully report back in a day or two

[scottmishra]

So I finally got time to come back and look at this. The output for a test run looks like:

2021-09-30 10:24:26,869 DEBUG o.a.j.t.TestBeanHelper: Setting mtiMapping=2222222222 6666666666 4444444444
2021-09-30 10:24:26,869 DEBUG o.a.j.t.TestBeanHelper: Setting muxKeyConfig=[]
2021-09-30 10:24:26,869 DEBUG o.a.j.t.TestBeanHelper: Setting requestListener=C:/Users/smgv/sandbox/test.BSH
2021-09-30 10:24:26,869 DEBUG n.c.b.j.i.ISO8583Config: 'DevConnection' setting up QBeans jmeter-1d81e895
2021-09-30 10:24:26,871 DEBUG n.c.b.j.i.ISO8583Config: Deploying <channel-adaptor name="jmeter-1d81e895-channel" logger="Q2"><in>jmeter-1d81e895-send</in><out>jmeter-1d81e895-receive</out><reconnect-delay>10000</reconnect-delay><wait-for-workers-on-stop>yes</wait-for-workers-on-stop><channel name="jmeter-1d81e895" class="com.chevron.drp.DRPChannel" packager="org.jpos.iso.packager.GenericPackager" header="" logger="Q2"><property name="packager-config" value="C:/JMeter/jmeter-drp/jmeter/resource/nyceiso8583.xml" /><property name="host" value="40.112.186.203" /><property name="port" value="10003" /><property name="socketFactory" value="org.jpos.iso.GenericSSLSocketFactory" /><property name="keystore" value="C:/JMeter/scs.jks" /><property name="storepassword" value="Password1234" /><property name="keypassword" value="" /></channel></channel-adaptor>
2021-09-30 10:24:26,910 DEBUG n.c.b.j.i.ISO8583Config: Start Mux
2021-09-30 10:24:26,910 DEBUG n.c.b.j.i.ISO8583Config: mtiMapping: 2222222222 6666666666 4444444444
2021-09-30 10:24:26,910 DEBUG n.c.b.j.i.ISO8583Config: Starting MUX wit Mapping 2222222222 6666666666 4444444444
.
.
.
.
.
2021-09-30 10:24:28,111 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [send] Out: 2504 000000073785 0000181500H     
2021-09-30 10:24:28,409 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [response] 0236372c
2021-09-30 10:24:28,410 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [response] 3637
2021-09-30 10:24:28,410 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [adjusted hex message data: ] [B@69d1d6a0
2021-09-30 10:24:28,410 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [received msg len] 67
2021-09-30 10:24:28,411 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [New Messages] 32363434023001000080000030393330313532343238303030303030303030303030303030303030303030303030303038393730303030303030303030002020202020
2021-09-30 10:24:28,414 DEBUG n.c.b.j.i.Q2: (channel/40.112.186.203:10003) [receive]  In: 2644 000000000000 0000000000
2021-09-30 10:24:28,480 INFO n.c.b.j.i.Q2: (request-listener) Finished Request Listener <---------- Timeout reached
2021-09-30 10:24:47,341 DEBUG n.c.b.j.i.ISO8583Sampler: ********************** Received response null <--- Sampler shows response is null
2021-09-30 10:24:47,351 DEBUG n.c.b.j.i.ISO8583Sampler: tx=1, rx=0, tx_expired=0, tx_pending=0, rx_expired=1, rx_pending=0, rx_unhandled=1, rx_forwarded=1, connected=false, last=0 <----- 1 unhandled TRX
all min=19968, max=20095, mean=20032.0000 stddev=0.0000 90%=20095, 99%=20095, 99.9%=20095, 99.99%=20095 tot=1 size=10752

I also added logging to show the mti mapping attempting to map every message back to 264X I've tried: 2222222222 6666666666 4444444444 and 2222222222 5555555555 0000000000

this message being 2504 out and expecting 2644 back. Neither work, unfortunately.

[scottmishra]

Ignore that above post, it looks like the test was invalid, the MUX keys don't align properly

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.