WAY4 ATM Configuration Builder пишем конфигурацию

[Venique]

Нет никакого сервера для Аптры. Есть ПЦ, который занимается авторизацией транзакционных запросов. Перед ПЦ стоит банкоматный контроллер, который принимает трафик и, отделяя от него ISO часть, направляет её в ПЦ. Логика же контроллера обеспечивает поддержку NDC\DDC протоколов, которые по сути и есть расширенное ISO. А что там за софт крутится на железке - без разницы.

1.jpg

Нюансы реализации протоколов крупных вендоров, наверняка, делали либо при их прямом содействии, либо просто по запросам от использующих их банков, т.к. это всё решается гибким конфигурированием контроллера. Вендора поменьше, чем NCR или Diebold-Nixdorf адаптируются сами, заставляя свой транзакционный софт слать Request таким образом, чтобы он понравился Way4.

[booby]

Нет никакого сервера для Аптры.

Там же даже на картинке написано "NetServer".
Банкоматные сети - это сети с архитектурой клиент-сервер. NDC/DDC - это протокол прикладного уровня по модели OSI-7. ISO 8583 - это также спецификация протокола прикладного уровня, на основе которой разработаны проприетарные протоколы MasterCard CIS, Visa BASE I.

ATM Controller - это и есть сервер Аптры (или другого банкоматного софта, который взаимодействует с сервером по протоколу NDC). В терминологии NCR он называется Central. И никакую ISO часть он не отделяет, потому что никакой ISO части в протоколе NDC нет. Сервер генерирует ISO-сообщения из данных, полученных от банкомата в NDC-сообщениях. И аналогично генерирует NDC-сообщения из данных, полученных от ПЦ в ISO-сообщениях. Плюс обмен между сервером и Аптрой системными сообщениями, об ошибках, настройках конфигурации и пр.

При включении банкомата Аптра открывает ТСР-сокет по заданному адресу/порту и начинает обмен NDC-сообщениями с сервером. Разработчики процессингового софта, в том числе WAY4, для взаимодействия с банкоматами по протоколу NDC написали собственный сервер, который является частью WAY4. Поэтому возник вопрос с докой по протоколу NDC, потому что инфы в AANDC Ref Manual явно недостаточно для написания сервера Аптры.

[Venique]

Нет никакого сервера для Аптры.

Там же даже на картинке написано "NetServer".

...

ATM Controller - это и есть сервер Аптры.

Так сервер Аптры - это NetServer или ATM Controller? Не существует такого понятия, как сервер Аптры. NS - лишь частная реализация программного комплекса (по сути - маршрутизатора), находящегося перед ПЦ, один из модулей которого - банкоматный контроллер. Его логика работы поддерживает взаимодействие с NDC/DDC, включая нюансы реализаций конкретных производителей ПО. Поэтому что на железке будет поднятно - Аптра

или другого банкоматного софта, который взаимодействует с сервером по протоколу NDC

хоть эмулятор - ему абсолютно не важно. Он обслуживает не конкретное ПО, а лишь обеспечивает обмен NDC-сообщениями, которыми любое совместимое ПО общается. Что такое NDC OW, думаю, и без чьих-либо документаций знает, а поддержку NCR'овской реализации наверняка вместе с ними и делали.

[booby]

Не существует такого понятия, как сервер Аптры.

Central, ATM Controller, ATM Switch - это синонимы сервера Аптры для банкоматов, на которых крутится Аптра. Не нравится название сервер Аптры - назовите его NDC-сервером. А Аптру назовите NDC-клиентом. По аналогии с HTTP-сервером и HTTP-клиентом. Большинство называет HTTP-сервер веб-сервером, а HTTP-клиента веб-браузером.

Кстати, в доке AANDC Ref Manual приведена картинка SST Start‐Up Sequence обмена NDC-сообщениями между Аптрой и сервером при включении банкомата. И на картинке показаны сообщения, которые не описаны в самой доке.

[Solovei_razboinik]

Добрый день ещё раз! Хотел спросить, у кого-нибудь есть тестовая конфига по NDC протоколу для NCR (буду очень рад, если ещё будут картинки, с ними намного легче) и кто-нибудь может объяснить как работает операционный буфер и за что отвечает каждый байт?

[Venique]

В доке по ICC см. Appendix A. Просто перенеси всё это по пунктам в конфигуратор, а потом экспортни. Экраны там тоже есть, но в виде псевдо-графики, этого хватит за глаза для принципиального понимания.

Стейт D позволяет задавать в операционном буфере символы от A до D. Если использовать стейт расширения, то на нём дополнительно можно задать символы от I до F. Т.е. со стейтом расширением это будет выглядеть так:

200000001DXXXXXXXXXXXXXXXXXXXXX002
200000002ZXXXXXXXXXXXXXXXXXXXXXXXX

где 2 - обозначение, что это стейт, 001 и 002 - номера стейтов, D и Z - стейт опкода и стейт расширения, 002 в стейте D - указывает номер стейта-расширения, Х - маска байтов, которую нужно будет задать (её тебе конфигуратор посчитает). В такой конфигурации стейтов можно задать символы от A до F, по одному символу на каждый байт. Всего у тебя восемь байтов => восемь символов.

При помощи этих стейтов ты задаёшь конкретный операционный буфер или только какие-то из значений (т.е. маску). Этот операционный буфер отправляется в транзакционном запросе на стейте I, если там взведён соответствующий бит (то бишь выставлена соответствующая галка в конфигураторе). Например, ты задал опкод ABCDIHGF и отправил его в запросе. Этот запрос попадает на контроллер, тот его парсит и в своём конфиге видит, что операция с опкодом ABCDIHGF - это выдача денег, после чего посылает нужный запрос уже в Way4, там происходит магия и банкомат начинает шуршать диспенсером. Про маски и смысл шаблонизированного state flow для сохранения нажатий fdk-клавиш в определённые позиции буфера потом можно будет рассказать, пока начни с основ.