search

tilln / jmeter-iso8583

ISO8583 Plugin for JMeter
MIT License
64 stars 33 forks source link

iso 8583: Getting invalid bitmap for my ISO message in JMeter for POS Purchase transaction #48

Closed mdzeyaullah closed 2 years ago

mdzeyaullah commented 2 years ago

I am new to ISO 8583 message. I am getting Invalid bitmap error in LB balancer logs where I am sending the request from JMETER.

2.01.12 21:44:19.462 [     blr:16449792]D-BLR-10013: Read 12 bytes
 22.01.12 21:44:19.462 [     blr:16449792]CCTClient::check_after() - actived
 22.01.12 21:44:19.462 [     blr:16449792]CCTClient::check() ret:None
 22.01.12 21:44:19.462 [     blr:16449792]L-BLR-10017: Recv 12 bytes from 
 [265], ID[269616260] at 1642013059 462
 22.01.12 21:44:19.462 [     blr:16449792]D-ISOHDL-0001: Process field: h1
 22.01.12 21:44:19.462 [     blr:16449792]D-ISOHDL-0001: Process field: mti
 22.01.12 21:44:19.462 [     blr:16449792]E-ISOHDL-2005: Exceed end of msg, field[mti]
 22.01.12 21:44:19.462 [     blr:16449792]E-ISOHDL-0004: Error in parsing iso8583 msg, no

msgid generated 22.01.12 21:44:19.462 [ blr:16449792]E-BLR-70003: Retrieve MsgInfo failed, src port: 

22.01.12 21:44:19.462 [     blr:16449792]D-BLR-70024: Handler resp method return -1
22.01.12 21:44:20.589 [     blr:16449792]D-BLR-10013: Read 15 bytes
 22.01.12 21:44:20.589 [     blr:16449792]L-BLR-10017: Recv 15 bytes from 
[265], ID[2797415146] at 1642013060 589
22.01.12 21:44:20.589 [     blr:16449792]D-ISOHDL-0001: Process field: h1
22.01.12 21:44:20.589 [     blr:16449792]D-ISOHDL-0001: Process field: mti
22.01.12 21:44:20.589 [     blr:16449792]D-ISOHDL-0001: Process field: 0
22.01.12 21:44:20.589 [     blr:16449792]E-ISOHDL-1000: Invalid bitmap field, at msg offset[e]
22.01.12 21:44:20.589 [     blr:16449792]E-ISOHDL-0004: Error in parsing iso8583 msg, no msgid 
  generated
  22.01.12 21:44:20.589 [     blr:16449792]E-BLR-70003: Retrieve MsgInfo failed, src port: 
.
  22.01.12 21:44:20.589 [     blr:16449792]D-BLR-70024: Handler resp method return -1
 22.01.12 21:44:20.589 [     blr:16449792]CCTClient::check() ret:None'

I am seeing in JMeter debug log.

This is the packed request it is forming.

'313230304632333030374331323843323841303531363434303634373030313430323135373730303030303030303030303030303032303030313132323134323031303031343432323230313132303934323031373130333031373033333443303130303332303030343139393030333734323036353838383437303233373334383433353137383234393633363636363636363636363636363638353237343139363633333120202030303652414a425031303336383234374646463031303030303430303030303033373137305f2a020682820219808407a0000002281010950500000080019a032112149c01009f02060000000050009f03060000000000009f10120110a040002a00000000000000000000ffff9ff1a0206829f2608cfef18b5eaecb9949f2701809f3303e008089f34031f03029f3501229f3602003b9f3704055b6e3b50046d6164619f6e07068200003030009f120a6d6164612044656269744f07af00000022810109f1e08353030313030343830303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303131303232303330303431303530343030353030374e30303030303045303030303030303039303130303030303030303030313130303030303030303031323130333431383030303133313033343139303030313431333438313033343030313531353036303030393136303130313031303232423439313137424646464646464646' JMeter request message:

<isomsg direction="outgoing">
   <!-- org.jpos.iso.packager.GenericPackager[/] -->
  <header>6000376D25</header>
  <field id="0" value="1200"/>
  <field id="1" value="F23007C128C28A05"/>
  <field id="2" value="4406470014021577"/>
  <field id="3" value="000000"/>
  <field id="4" value="000000000200"/>
  <field id="7" value="0112212717"/>
  <field id="11" value="1442"/>
  <field id="12" value="220112092717"/>
  <field id="22" value="71030170334C"/>
  <field id="23" value="0"/>
  <field id="24" value="200"/>
  <field id="25" value="1990"/>
  <field id="26" value="742"/>
  <field id="32" value="588847"/>
  <field id="35" value="37"/>
  <field id="37" value="147987678722"/>
  <field id="41" value="6366666666666666"/>
  <field id="42" value="852741966331"/>
  <field id="47" value="BANBP1"/>
  <field id="49" value="682"/>
  <field id="53" value="47FFF010000400000037" type="binary"/>
  <field id="55"  
  <field id="62" 
  <field id="64" value="2B49117BFFFFFFFF" type="binary"/>
  </isomsg>

Hex dump generated from request

<!--

0000 31 32 30 30 46 32 33 30 30 37 43 31 32 38 43 32 1200F23007C128C2 0010 38 41 30 35 31 36 34 34 30 36 34 37 30 30 31 34 8A05164406470014 0020 30 32 31 35 37 37 30 30 30 30 30 30 30 30 30 30 0215770000000000 0030 30 30 30 30 30 32 30 30 30 31 31 32 32 31 32 37 0000020001122127 0040 31 37 30 30 31 34 34 32 32 32 30 31 31 32 30 39 1700144222011209 0050 32 37 31 37 37 31 30 33 30 31 37 30 33 33 34 43 271771030170334C 0060 30 31 30 30 33 32 30 30 30 34 31 39 39 30 30 33 0100320004199003 0070 37 34 32 30 36 35 38 38 38 34 37 30 32 33 37 31 7420658884702371 0080 34 37 39 38 37 36 37 38 37 32 32 36 33 36 36 36 4798767872263666 0090 36 36 36 36 36 36 36 36 36 36 36 38 35 32 37 34 6666666666685274 00a0 31 39 36 36 33 33 31 20 20 20 30 30 36 52 41 4A 1966331 006BAN 00b0 42 50 31 30 33 36 38 32 34 37 46 46 46 30 31 30 BP10368247FFF010 00c0 30 30 30 34 30 30 30 30 30 30 33 37 31 37 30 5F 000400000037170_ 00d0 2A 02 06 82 82 02 19 80 84 07 A0 00 00 02 28 10 .............(. 00e0 10 95 05 00 00 00 80 01 9A 03 21 12 14 9C 01 00 ..........!..... 00f0 9F 02 06 00 00 00 00 50 00 9F 03 06 00 00 00 00 .......P........ 0100 00 00 9F 10 12 01 10 A0 40 00 2A 00 00 00 00 00 ........@...... 0110 00 00 00 00 00 FF FF 9F F1 A0 20 68 29 F2 60 8C .......... h).. 0120 FE F1 8B 5E AE CB 99 49 F2 70 18 09 F3 30 3E 00 ...^...I.p...0>. 0130 80 89 F3 40 31 F0 30 29 F3 50 12 29 F3 60 20 03 ...@1.0).P.). . 0140 B9 F3 70 40 55 B6 E3 B5 00 46 D6 16 46 19 F6 E0 ..p@U....F..F... 0150 70 68 20 00 03 03 00 09 F1 20 A6 D6 16 46 12 04 ph ...... ...F.. 0160 46 56 26 97 44 F0 7A F0 00 00 02 28 10 10 9F 1E FV&.D.z....(.... 0170 08 35 30 30 31 30 30 34 38 30 30 30 30 30 30 30 .500100480000000 0180 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0190 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01a0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01b0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01d0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01e0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 01f0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0210 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0220 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0230 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0240 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0250 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0260 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0270 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0280 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0290 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02a0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02b0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02d0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02e0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 02f0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0300 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0310 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0320 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0330 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0340 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0350 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0360 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0370 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0380 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0390 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03a0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03b0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03d0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03e0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 03f0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0400 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0410 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0420 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0430 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0440 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0450 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0460 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0470 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0480 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 0490 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 04a0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 04b0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 04c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 04d0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000 04e0 30 30 30 30 30 30 30 30 30 30 30 30 30 31 31 30 0000000000000110 04f0 32 32 30 33 30 30 34 31 30 35 30 34 30 30 35 30 2203004105040050 0500 30 37 4E 30 30 30 30 30 30 45 30 30 30 30 30 30 07N000000E000000 0510 30 30 39 30 31 30 30 30 30 30 30 30 30 30 30 31 0090100000000001 0520 31 30 30 30 30 30 30 30 30 30 31 32 31 30 33 34 1000000000121034 0530 31 38 30 30 30 31 33 31 30 33 34 31 39 30 30 30 1800013103419000 0540 31 34 31 33 34 38 31 30 33 34 30 30 31 35 31 35 1413481034001515 0550 30 36 30 30 30 39 31 36 30 31 30 31 30 31 30 32 0600091601010102 0560 32 42 34 39 31 31 37 42 46 46 46 46 46 46 46 46 2B49117BFFFFFFFF --> Can any one guide us where is the issue with my request. Header we are passing is like this - 6000376D25 Is passing message length is mandatory? How to pass the message length in the beginning of the hex dump if it is mandatory?

mdzeyaullah commented 2 years ago

@tilln Could you please help in this. I am a kind of stuck here in absence of sufficient information online.

tilln commented 2 years ago

Hi @mdzeyaullah

There could be several reasons that your message fails to process at the Bitmap field. Any of the bytes sent before the Bitmap could cause the following bytes to be interpreted incorrectly.

  1. Channel Class: Which one are you using and are you sure it's appropriate? Depending on the class, there may be other bytes sent before the actual message header, such as the message length and possibly other header bytes. Based on your logs it looks like your server expects some 12 bytes header information or it only reads 12 bytes based on the message length it received (or rather based on the bytes it interpreted as the message length).

  2. Packager configuration: Have you got sufficient information to define Field Packager classes for all message fields? If a field is not packaged correctly, the server will misinterpret it, which could be the case for the MTI field or Bitmap as well. Make sure that the ASCII encoding of the MTI and Bitmap are appropriate.

  3. Header data: Is the static header data you're sending correctly encoded? Is it supposed to be static (like a station ID etc)? Sometimes dynamic header data is required (that the underlying jPOS framework may be able to generate).

The Channel Class is the most important setting to get right, followed by the Packager configuration.

Unless you have good documentation I'm afraid you'll have to experiment with at least the above settings quite a bit.

What I would also recommend is to use a simpler message than your 1200 financial transaction message, but I'd start with an 1800 Echo request. Perhaps the server side logging level could also be increased (to include debug information), so you can see what data is actually processed for those fields

22.01.12 21:44:20.589 [ blr:16449792]D-ISOHDL-0001: Process field: h1
22.01.12 21:44:20.589 [ blr:16449792]D-ISOHDL-0001: Process field: mti
22.01.12 21:44:20.589 [ blr:16449792]D-ISOHDL-0001: Process field: 0
mdzeyaullah commented 2 years ago

@tilln Thanks for the response. I am working on echo message 1800. Will it be 1800 itself for iso 8583: 1993? Do I need to share any other information to confirm the issue? Is bitmap required to send in JMeter request or bitmap is generated by JMeter? and what about header? Could you please share one sample JMeter script for 1800?

tilln commented 2 years ago

@mdzeyaullah

You'll have to find out from your documentation, specification and/or server logs how to build your 1800 message.

As I doubt there is an issue with this plugin I don't think you need to share more information.

Bitmaps will be generated by JMeter, as documented.

As for headers, some Channel classes generate dynamic headers, for others you can specify static headers in the Connection Config or Sampler.

Here you'll find a sample echo message: .

mdzeyaullah commented 2 years ago

@tilln Thanks for your quick response. Is there any way to add the message length and TPDU before the iso message in JMeter?

tilln commented 2 years ago

@mdzeyaullah There are ways to do that, though why would you need to and not just let jPOS generate all that for you? I'd suggest you try to find a Channel class that suits your needs. Otherwise you might have to implement your own, though I doubt that'll be necessary.

mdzeyaullah commented 2 years ago

The only challenge we have is to send the message length as 2 bytes before the message header. I am using NACChannel in my request.

NACChannel | Talks with TCP based NACs Sends [LEN][TPDU][ISOMSG] (len=2 bytes network byte order)

mdzeyaullah commented 2 years ago

@tilln Is MUX setting mandatory ? I was going through this https://github.com/tilln/jmeter-iso8583/blob/master/src/main/resources/nz/co/breakpoint/jmeter/iso8583/ISO8583ConfigResources.properties

Mux.displayName=Mux Settings mtiMapping.displayName=MTI Mapping mtiMapping.shortDescription=3 ten-digit numbers representing how the first 3 MTI digits are mapped between request and response muxKeyConfig.displayName=Mux Key Configuration muxKeyConfig.shortDescription=Each row contains the key fields for a message type as per the MTI column, or for all messages if the MTI column is empty muxKeyConfig.tableHeaders=MTI|Key Fields

tilln commented 2 years ago

@mdzeyaullah

The only challenge we have is to send the message length as 2 bytes before the message header. I am using NACChannel in my request.

Ok, though other Channel classes do that as well. You'd have to experiment. Hope that NACChannel is working for you now? Or are you still getting Bitmap errors?

@tilln Is MUX setting mandatory ? I was going through this https://github.com/tilln/jmeter-iso8583/blob/master/src/main/resources/nz/co/breakpoint/jmeter/iso8583/ISO8583ConfigResources.properties

Mux settings are optional (as per documentation). Often times, it just works with the sensible jPOS default settings, otherwise you can do some tweaks there, e.g. when you're getting timeouts due to the Mux not being able to match incoming response messages to previously sent out request messages.

mdzeyaullah commented 2 years ago

Thanks @tilln for your response.

About NAC Channel: At least we are able to send the request to reach to the backend application server. Earlier it was rejected from the first interface like LB itself. Is there different test packager for NAC Channel? As we see its different for base24 etc.

Actually, our data element 3 is getting the value of data element 4 at backend server and data element 4 is taking the value of next data element after 4 which is data element 7. So it seems the application expects some more initial bytes before the actual message. Still I am getting bitmap errors. Actually I am passing bitmap as 723007C128C28A05 but its converting to F23007C128C28A05 in hex dump generation.

As I experimented till now I am seeing that only through NAC Channel our request is able to reach till the backend server. Perhaps I am repeating my question - where exactly In JMeter we can set the whole ISO message length if it can be handled by JMeter? Otherwise, how we will send the 2 byte message length before the ISO message if there is no place holder in JMeter.

tilln commented 2 years ago

@mdzeyaullah

Perhaps I am repeating my question - where exactly In JMeter we can set the whole ISO message length if it can be handled by JMeter? Otherwise, how we will send the 2 byte message length before the ISO message if there is no place holder in JMeter.

I don't think you'll have to set the message length as this will be automatically calculated and sent by the Channel (see here and here).

About NAC Channel: At least we are able to send the request to reach to the backend application server. Earlier it was rejected from the first interface like LB itself. Is there different test packager for NAC Channel? As we see its different for base24 etc.

Not sure what you mean, but what Channel you are using is pretty much independent of the Packager. You'll have to define all message fields in your packager configuration file or find a suitable one from the samples included in jPOS.

Actually, our data element 3 is getting the value of data element 4 at backend server and data element 4 is taking the value of next data element after 4 which is data element 7. So it seems the application expects some more initial bytes before the actual message. Still I am getting bitmap errors. Actually I am passing bitmap as 723007C128C28A05 but its converting to F23007C128C28A05 in hex dump generation.

It would be helpful if you could post some message and log details here, otherwise I'd just be guessing what could be off.

chhil commented 2 years ago

Please list the packager you are using, your initial message dump shows

<!-- org.jpos.iso.packager.GenericPackager[/] --> You need to use a packager that matches what the receiver expects and not use the generic one.

e.g. My custom packager xyz.xml being used <!-- org.jpos.iso.packager.GenericPackager[cfg/xyz.xml] -->

Still I am getting bitmap errors. Actually I am passing bitmap as 723007C128C28A05 but its converting to F23007C128C28A05 in hex dump generation.

Leading 72 from 723007C128C28A05 in binary is 0111 0010 [Fields 2,3,4,7 are present] Leading FF from F23007C128C28A05 in binary is 1111 0010 [Field 1,2,3,4,7 are present

The field data follows your bitmap and are assigned based on the which ones are '1'/set So in the case of F23007C128C28A05 what was field 2 is put in field 1 so on and so forth.

The problem is your packager file which you probably have not configured and the generic bitmap packing is causing it to get packed incorrectly.

I do hope you are not manually setting the bitmap and letting jpos packager do it for you.

All you need to do is set the fields (do not try and update the bitmap, it taken care of by jpos). Use the correct channel. NACCChannel is working for you, and the receiver is unpacking the data so there is no need for TPDU etc. Use the correct packager file with correct field level pckagers configured in it. Which seems to be a problem as the reciver is unpacking it based on how you packed it and the fields are off. So fix your packager.

if understanding JPOS interests you http://jpos.org/doc/proguide-draft.pdf