Can't match request reply using MUX configuration

[Charlélie Bouvier]

Dear JPOS group,

I have a request with MTI 1460 and a reply from server with MTI 1480.

The only field in common in request reply is the field 12.

So this how I configured my MUX : 

MTI MAPPING : "0123456789 0123456789 0022446769"

Mux Key configuration :
empty MTI : 12

Also tried to add :
1460 : 12
1480 : 12

I receive and unpack the reply, but jpos doesn't seem to match it with the request.

What am I doing wrong please?

Regards,

Charlélie Bouvier

[Mark Salter]

As pong as the whole content of fieldn12 is exactly the samenon the request as the respones, the MTI mapping *as well as* overriding the key to 12 should work.

With the right setup - I am unsure you have tried - and truely matching content then it should work.
Otherwise, perhaps the response is slow and it timed out?

-- 

Mark

Sent from Proton Mail mobile



-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/aef812c1-7f2c-44a9-9473-3a3c0a8f55a3n%40googlegroups.com.

[Charlélie Bouvier]

Hi Mark,

Thank you for your quick reply.

I do have the same value in field 12.
And I have logs that tell me I received the response with MTI 1480 and unpacked the response with the same field 12.

I'll keep digging to find out what's going wrong.

Regards,

Charlélie

[Mark Salter]

So you overrode both key field list and MTI mapping and the response beat your timeout and had the same length of/and value in field 12?

-- 

Mark

Sent from Proton Mail mobile



-------- Original Message --------

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/2573ce60-d574-4d7f-a57a-86e27a4bf648n%40googlegroups.com.

[Charlélie Bouvier]

Yes I am.

Timeout is 5000ms, I receive the response in approx 200ms

field 12 value is  221117162710 in request and reply

2023-01-02 17:01:05,133 DEBUG o.a.j.t.TestBeanHelper: Setting fields=[DE0=1460, DE4=000000000500, DE12=221117162710, DE24=100, DE48=58000002000000003031313431343030323136303130343338373030, DE49=978, DE53=00, DE124=0FC008080800000061306534383337632D303830322D343932632D383033352D66626530353361373464623134313766333531652D636366362D343662342D613161622D6662333861343736643438333230323230383138303832343030303030303030303030333530555020434B444F2020202020202020202020202020202020202020202020202020202020202020203230313061626161326435332D613530622D346639322D386338652D346233383738653963373232]
2023-01-02 17:01:05,133 DEBUG o.a.j.t.TestBeanHelper: Setting timeout=5000
2023-01-02 17:01:05,133 DEBUG o.a.j.t.TestBeanHelper: Setting responseCodeField=39
2023-01-02 17:01:05,133 DEBUG o.a.j.t.TestBeanHelper: Setting successResponseCode=000
2023-01-02 17:01:05,133 DEBUG o.a.j.t.p.AbstractProperty: Running version, executing function
2023-01-02 17:01:05,133 DEBUG n.c.b.j.i.ISO8583Sampler: sampleStart
2023-01-02 17:01:05,178 DEBUG n.c.b.j.i.Q2: (channel/XXXXX) [connect] Try 0 XXXXXX
2023-01-02 17:01:05,178 DEBUG n.c.b.j.i.Q2: (packager) [pack] 3134363090100100000188000000000000000010303030303030303030353030323231313137313632373130313030303238580000020000000030313134313430303231363031303433383730303937383031003138360FC008080800000061306534383337632D303830322D343932632D383033352D66626530353361373464623134313766333531652D636366362D343662342D613161622D6662333861343736643438333230323230383138303832343030303030303030303030333530555020434B444F2020202020202020202020202020202020202020202020202020202020202020203230313061626161326435332D613530622D346639322D386338652D346233383738653963373232
2023-01-02 17:01:05,179 DEBUG n.c.b.j.i.Q2: (channel/XXXXXX) [send] Out: 1460
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] 3134383000100000020100003232313131373136323731303030303033381400000000000000313431343030323136303130353338383230323330313032313730313035
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <bitmap>{12, 39, 48}</bitmap>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack]   <value>221117162710</value>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="39" packager="org.jpos.iso.IFA_NUMERIC">
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack]   <value>000</value>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] <unpack fld="48" packager="org.jpos.iso.IFA_LLLBINARY">
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack]   <value type='binary'>1400000000000000313431343030323136303130353338383230323330313032313730313035</value>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (packager) [unpack] </unpack>
2023-01-02 17:01:05,366 DEBUG n.c.b.j.i.Q2: (channel/XXXXXX) [receive]  In: 1480

And my config :

<qmux name="jmeter-466a1a45-mux" logger="Q2">
    <in>jmeter-466a1a45-receive</in>
    <out>jmeter-466a1a45-send</out>
    <unhandled>jmeter-466a1a45-unhandled</unhandled>
    <ready>jmeter-466a1a45.ready</ready>
    <mtimapping>0123456789 0123456789 0022446769</mtimapping>
    <key mti="1460">12</key>
    <key mti="1480">12</key>
    <key>12</key>
</qmux>

[Andrés Alcarraz]

I believe your problem is with the mtiMapping and that the third mapping should be 0022446869 for mapping the response to the third digit from 6 to 8.

Hope this helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/de452ac3-d922-42bf-ab40-0b8a4e060b69n%40googlegroups.com.

​

[Mark Salter]

I would get rid of :-

<key mti="1460">12</key>
<key mti="1480">12</key>

Unneeded and might be confusing something.

No chance the packagers processing the response are different to that handling the request?

I think you have the mtimapping the right way round reading the progguide, but perhaps try reversing the logic as suggested.

-- 

Mark

Sent from Proton Mail mobile




-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/de452ac3-d922-42bf-ab40-0b8a4e060b69n%40googlegroups.com.

[Charlélie Bouvier]

I already tried without the mti + key, I removed them for good now thx.

I tried with  0022446869  and it didn't work either.

I admit that I didn't understand how this MTI mapping works, even with the programmer's guide....

Charlélie

[Mark Salter]

I revisited this after making time to check the code (see https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L246 and https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L285 for the relevant parts for the response key evolution from the request.

*Alcarraz* shared the right solution and I think I managed to confuse myself/you...

...  the mtimapping elements are applied to the request MTI is sent to form a key on which the response should match, so it needs to mtimapping 1460 onto 1480, meaning that your mtimapping setup should be :-

  <mtimapping>0123456789 0123456789 0022448789</mtimapping>

so that the 3rd digit (6) in the request MTI, is mapped to 8 to match what the response is expected to have as its MTI.

So please try as above and I think all will be well.

--

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/dd0c04e1-8658-4f27-9d68-25345e328481n%40googlegroups.com.

[Charlélie Bouvier]

Hi Mark,

Tried with 0123456789 0123456789 0022448789, still not working, thank you for the code link, I'll make a review too, so I can understand how it really works.

Regards,

Charlélie

[murtuza chhil]

Try using 0022446769 in third index of mti mapping.

The mapMti needs to produce the same result for request and response (so 1420 and 1430 both should produe 142 and similarly 1460 and 1480 should both produce 146).

When the request is sent, the mapped mti saved is 146, and when the response 1480 is received the mapped mti should result in 146.

    public static void main(String[] args) throws ISOException {

        String s1 = mapMTI("1460");
        String s2 = mapMTI("1480");

        if (s1.equals(s2)) {
            System.out.println("mapping works");
        }

    }

// JPOS code to map mti with some edits to make it work standalone.
    private static String mapMTI(String mti) throws ISOException {
        String   nomap      = "0123456789";
        String[] mtiMapping = new String[] { nomap, nomap, "0022446769" }; // <-- position 8 is a 6. 8 is the third position from the response 1480 and the 8 in the 3rd mtimapping needs to be changed to 6.

        StringBuilder sb = new StringBuilder();
        if (mti != null) {
            if (mti.length() < 4)
                mti = ISOUtil.zeropad(mti, 4); // #jPOS-55
            if (mti.length() == 4) {
                for (int i = 0; i < mtiMapping.length; i++) {
                    int c = mti.charAt(i) - '0';
                    if (c >= 0 && c < 10)
                        sb.append(mtiMapping[i].charAt(c));
                }
            }
        }
        return sb.toString();

    }

​

-chhil

[Till Neunast]

Hi Charlélie

A mapping of 0022448789 should work just as well as 0022446769 since both request and response are mapped to the same key, regardless what the mapping digit contains. It's a string, so one could even use other characters e.g. 002244A7A9 .

I think the issue is due to how jPOS distinguishes requests and responses, by whether the third MTI digit is odd or even:

https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/iso/ISOMsg.java#L953-L955

    public boolean isRequest() throws ISOException {
        return Character.getNumericValue(getMTI().charAt (2))%2 == 0;
    }

Therefore your response with MTI 1480 gets "stuck" in the QMUX because it is considered a request.

Refer:
https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L203-L208
https://github.com/jpos/jPOS/blob/v2_1_6/jpos/src/main/java/org/jpos/q2/iso/QMUX.java#L223

    protected boolean isNotifyEligible(ISOMsg msg) {
        if (returnRejects)
            return true;

        try {
            return msg.isResponse();


Work-around may be to set the QMUX config flag "return-rejects" to true, however, this is not currently exposed by the JMeter plugin unfortunately.

[Andrés Alcarraz]

Good catch!

I wonder how a configuration to the mux could be added to treat some MTIs as responses, the most obvious would be a property like:

<property name="force-response-mtis" value="1480"/>

Or just response-mtis. Just for the sake of completeness, we could do the same for requests, not sure about we should.

But there sure be a more clever way.

Regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/0fb3aef5-8333-42b5-a895-c94140d695d7n%40googlegroups.com.

​

[Charlélie Bouvier]

Hi,

Thank both of you. I'll give it a try by compiling the plugin on local, if it works I may be able to make a pull request.

Thank you again.

You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/uSYPjJaorQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/a8667cd9-9bd9-9a02-d947-d18c3ce1bfd2%40gmail.com.

[Alejandro Revilla]

Work-around may be to set the QMUX config flag "return-rejects" to true, however, this is not currently exposed by the JMeter plugin unfortunately.

The property can be added to QMUX's configuration.

--

@apr

[Till Neunast]

No need to compile the plugin if you programmatically, via some Groovy snippet in your JMeter script, set the config value on the QMUX like so (assuming you give the Plugin's "ISO8583 Connection Configuration" a "Connection Reference"):

org.jpos.q2.iso.QMUX.getMUX('<INSERT-YOUR-CONNECTION-REFERENCE>-mux').returnRejects = true

which works because Groovy can access the private field.