Возникли проблемы с моим упаковщиком ISO8583 при подключении к каналу jpos

После упаковки моих данных и при попытке отправить на канал JPOS (сервер) я получаю следующую ошибку.

Length = 0030 Byte length(b): 48 :: Incoming data HEX(d): 3830300238000000C2820000303030303130303732323137313934363030303030363030303231383030303631373139 org.jpos.iso.IFA_LLNUM: Problem unpacking field 33 (java.lang.ArrayIndexOutOfBoundsException: 48) unpacking field=33, consumed=42 org .jpos.iso.ISOException: org.jpos.iso.IFA_LLNUM: проблема с распаковкой поля 33 (java.lang.ArrayIndexOutOfBoundsException: 48) распаковка поля = 33, потребление = 42 в org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java :273) в org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416) в org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903) в org.jpos.iso.BaseChannel.receive(BaseChannel. java:671) в org.jpos.iso.ISOServer$Session.run(ISOServer.java:130) в org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:71) --- данные --- 0000 38 30 30 02 38 00 00 00 С2 82 00 00 30 30 30 30 800,8.......0000 0010 31 30 30 37 32 32 31 37 31 39 34 36 30 30 30 30 1007221719460000 0020 30 36 30 30 30 32 31 38 30 30 30 36 31 37 31 39 060002171900

org.jpos.iso.IFA_LLNUM: проблема с распаковкой поля 33 (java.lang.ArrayIndexOutOfBoundsException: 48) распаковка поля = 33, потребление = 42 org.jpos.iso.ISOException: org.jpos.iso.IFA_LLNUM: проблема с распаковкой поля 33 ( java.lang.ArrayIndexOutOfBoundsException: 48) поле распаковки = 33, потребляемое = 42 в org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:273) в org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416) в org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903) в org.jpos.iso.BaseChannel.receive(BaseChannel.java:671) в org.jpos.iso.ISOServer$Session.run(ISOServer.java :130) в org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:71)

И я использую приведенный ниже класс Java для транспортировки упакованных данных.

public static String networkTransport(String isoMessage) throws UnknownHostException, IOException {
        Socket connection = new Socket("192.168.3.118", 1010);
        BufferedOutputStream bos = new BufferedOutputStream(connection.getOutputStream());

        OutputStreamWriter osw = new OutputStreamWriter(bos);
        int len = isoMessage.length(); // get the length of the data
        // SInce your packager name says Postilion, I think this will work.
        osw.write(len >> 8); // send the length bytes in 2 bytes. this is the byte 1
       // osw.write(len);// send the length bytes in 2 bytes. this is the byte 2

        osw.write(isoMessage);
        osw.flush();

        byte[] arrOutut = new byte[4096];
        int count = connection.getInputStream().read(arrOutut, 0, 4096);

        String clientRequest = "";
        for (int outputCount = 0; outputCount < count; outputCount++) {
            char response = (char) arrOutut[outputCount];
            clientRequest = clientRequest + response;
        }

        connection.close();

        return clientRequest;
    }

Проблема, с которой я сейчас сталкиваюсь, заключается в том, как я могу обеспечить плавный поток с моим каналом JPOS. Все предложения приветствуются.


person Israel Meshileya    schedule 26.07.2016    source источник
comment
Ваша проблема не связана с упаковкой сообщений iso8583. Это чисто проблема разработки, потенциально связанная с внешними библиотеками, когда обрабатывается непредвиденная/неподдерживаемая упаковка/анализ данных. Из-за ваших журналов ошибок Это может быть проблема упаковки данных EMV, когда вместо данных TLV используются некоторые неожиданные данные мусора.   -  person iso8583.info support    schedule 27.07.2016
comment
Спасибо большое за Ваш ответ. но то, что мне еще предстоит понять, это то, что. Я вижу, что было упаковано в моей консоли Android Studio. но на другом принимающем конце он только подключается... не показывая, что уже было упаковано... прежде чем фактически вернуть нулевую ошибку.   -  person Israel Meshileya    schedule 27.07.2016
comment
как сказал @iso8583.infosupport, это должна быть ошибка программирования. Но проверили ли вы дважды, встречается ли исключение в элементе данных ISO 55 или в каком-то другом элементе данных? Можно ли регистрировать элементы один за другим по мере их обработки, чтобы увидеть, на каком именно этапе происходит сбой.   -  person Adarsh Nanu    schedule 28.07.2016
comment
Что я заметил, так это то, что мой упаковщик упаковывает все необходимые поля, но при переходе к тому, который не нужно упаковывать... он возвращает ноль.... Означает ли это, что я должен отправить все необходимое в моем isoPackager . потому что у меня есть структурированный дизайн для моего isoField, который находится в этом формате /* 01 ПРОДАЖА */ { F02_PAN, F03_PROC, F04_AMOUNT, F11_STAN, F14_EXP, F22_POSE, F23, F25_POCC, F26_CAPTURE, F35_TRACK2, F36_TRACK3, F38_AUTH, F39_RSP, F41_ F42_ACCID, F49_CURRENCY, F52_PIN, F53_SCI, F55_ICC, F60, F64_MAC},   -  person Israel Meshileya    schedule 29.07.2016
comment
В запросе вы можете увидеть, как вы заполняете приведенный ниже трек 3 DE36 - он устарел. -- DE38 Authnum и DE39 Response Code – они обычно доступны в запросе на уведомление и в ответе на финансовую авторизацию. Не в запросе авторизации. -- Блокировка PIN-кода DE52 – это транзакция на основе PIN-кода, и у вас есть блокировка PIN-кода -- F64 MAC – вы рассчитали MAC-адрес --   -  person Adarsh Nanu    schedule 29.07.2016
comment
К вашему сведению, в интерфейсе n ISO8583 вы определяете растровые изображения (которые указывают, что является обязательным, необязательным, не обязательным) и поля по спецификациям полей. Все обязательные поля должны быть заполнены, иначе сообщения будут отклонены получателем с ошибкой формата. Везде, где это не является обязательным, бит следует сделать необязательным.   -  person Adarsh Nanu    schedule 29.07.2016
comment
большое спасибо за ваш комментарий @libadarsh.so.1.0.1 я очень ценю. то, что я также хотел бы спросить это. Я использую чистый упаковщик класса JAVA для упаковки своего сообщения, но есть демонстрационный сервер для проверки того, что я упаковываю. хотя в моей консоли журнала я вижу, что я упаковал, и что было распаковано, но на моем сервере я вижу только length = 3038. ПРИМЕЧАНИЕ. JPOS использовался при написании этого демонстрационного сервера. теперь я хочу спросить, должен ли я использовать JPOS для упаковки и распаковки ???... чтобы я мог увидеть это на этом демонстрационном сервере.   -  person Israel Meshileya    schedule 08.08.2016
comment
вопрос решен. и если да, можете ли вы опубликовать проблему и отметить ее закрытой.   -  person Adarsh Nanu    schedule 08.08.2016
comment
я не знаю, как это сделать, @libadarsh...буду очень рад, если вы сможете помочь мне.   -  person Israel Meshileya    schedule 08.08.2016
comment
@IsraelMeshileya, можете ли вы опубликовать журнал элементов данных, которые вы упаковываете.   -  person Adarsh Nanu    schedule 08.08.2016
comment
@libadarsh.so.1.0.1 Я разместил там журнал ... но на стороне сервера JPOS я всегда вижу length = 3038 ...   -  person Israel Meshileya    schedule 09.08.2016
comment
@IsraelMeshileya, возможно ли, что вы можете отключить бит 55 и попробовать   -  person Adarsh Nanu    schedule 09.08.2016
comment
но я отправляю только поля 7, 11, 12, 13 и 41..... пытаюсь проверить свое эхо-сообщение..   -  person Israel Meshileya    schedule 09.08.2016
comment
@IsraelMeshileya, вы можете распечатать и посмотреть дамп растрового изображения?   -  person Adarsh Nanu    schedule 10.08.2016
comment
@IsraelMeshileya убедитесь, что вы не включили какой-либо бит случайно, и по совпадению его данные недоступны? и, кстати, у вас есть данные и определения членов для ISOPacker? проверьте определение растрового изображения для размера типа и кодировки данных   -  person Adarsh Nanu    schedule 10.08.2016
comment
Спасибо за ваше время @libadarsh.so.1.0.1 то, что я сейчас выражаю, обновлено в моем вопросе ... я до сих пор не понимаю, где я ошибаюсь.   -  person Israel Meshileya    schedule 11.08.2016


Ответы (3)


Вот как я бы разделил ваши данные.

383030                          //echo message type as you said 0800. 
                                But where is the starting 0 (0x30) ? 
0238000000C28200                //bitmap 8 bytes -  packed BCD
00303030303130303732323137313934363030303030363030303231383030303631373139 - data

Ниже приведены биты, которые вы включили. Можете ли вы проверить, есть ли у вас все данные поля для включенных ниже битов? Я не понимаю, зачем вам DE55 в эхо-сообщении.

0   0000
2   0010 7
3   0011 11, 12
8   1000 13
0   0000
0   0000
0   0000
0   0000
0   0000
0   0000
C   1100 41, 42
2   0011 47, 48
8   1000 49
2   0011 55, 56  
0   0000 
0   0000

Предположим, я бы разделил ваши данные, как показано ниже:

00 30 30 30 30 31 30 30 37 32   -   transmission date mmddhhmmss 
32 31 37 31 39                  -   trace number
34 36 30 30 30 30               -   local time
30 36 30 30                     -   local date
30 32 31 38 30 30 30 36         -   terminal id
31 37 31 39                     -   this is all the remaining data for bits 42, 47, 48, 49,
                                    55 and 56. 

Таким образом, получение нулевого указателя вполне очевидно.

person Adarsh Nanu    schedule 11.08.2016
comment
Поскольку я не использую jpos для упаковки и распаковки своих данных.... но... я подключаюсь к серверу jpos... что вы предлагаете мне делать??? - person Israel Meshileya; 12.08.2016
comment
независимо от того, какой сервер работает на другом конце или какой метод вы используете для упаковки и распаковки сообщения, в эмпирическом правиле iso8583 обе стороны должны быть согласны с битами, необязательными, обязательными и необязательными, и если они присутствуют, каковы их типы данных и длина. под разделением вашего сообщения я имею в виду, что в растровом изображении вы указали, например, для. элемент данных 55. но у вас нет данных. в данных сообщения, которые я разделил для вас, можете ли вы разделить и показать мне поле за полем по порядку. это объяснит вам проблему. - person Adarsh Nanu; 12.08.2016
comment
isofields.put(7, 0722171946); isofields.put(11, 000218); isofields.put(12, 171946); isofields.put(13, 0722); isofields.put(41, 27002368); isofields.put(47, 442); это данные, которые я отправляю... для выполнения моего эхо-сообщения. - person Israel Meshileya; 12.08.2016
comment
47 последний элемент, который вы упаковываете? - person Adarsh Nanu; 12.08.2016
comment
тогда как 49,55,56 добавляется в растровое изображение. Вы жестко кодируете растровое изображение, которое используется для сообщения аутентификации? - person Adarsh Nanu; 12.08.2016
comment
Давайте продолжим это обсуждение в чате. - person Israel Meshileya; 12.08.2016
comment
@libadarsh... не против поболтать с тобой в комнате, которую я создал.... Я буду очень признателен за твое присутствие там. - person Israel Meshileya; 12.08.2016

Я смог решить эту проблему, используя библиотеку JPOS, но мне пришлось упростить ее, чтобы использовать только то, что мне понадобится на моем собственном конце.

Если вы можете использовать этот метод на своем устройстве Android, это папки, которые я действительно использовал

  1. Канал
  2. Фильтр
  3. Гуй
  4. Заголовок
  5. Упаковщик
  6. Валидатор и весь класс Java здесь

или еще лучше, используйте все файлы и папки здесь

person Israel Meshileya    schedule 13.09.2016

При упаковке данных для сервера jpos вы должны проверить две детали:

1) тип канала сервера jpos (начальные или конечные данные)

2) упаковщик jpos-сервера

Обратите внимание, что сервер jpos не ожидает необработанных потоковых данных от клиентов. На сайте jpos.org вы можете найти очень хорошо написанное руководство по jpos.

person Amit Vujic    schedule 16.09.2016