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

[TOPOC]

Наигравшись с аппаратной частью банкоматов мне стало интересно, а как-же пишутся конфиги и сценарии для банкоматов. Откопал информацию, что пишут их на WAY4 ATM Configuration Builder, а вот документацию по нему найти не могу!
Может кто нибудь толково обьяснить вообще про написание конфигов, сценариев?
И может быть у кого нибудь завалялась документация по этой программе? или придется довольствоваться только HELP

Буду очень благодарен!

[gy1610]

Так сценарии пишут под конкретный процессинг. Конечно, стандартные стейты есть у каждого вендора банкоматов. Но дальше надо смотреть на процессинг.

[TOPOC]

А где вообще можно скачать эту программку?? Меня интересует в этой программе свой язык написания или просто наборы параметров, которые устанавливаешь по своему усмотрению?

[gy1610]

Вот нарыл у себя. Вроде похоже на то, что Вы просили.

[TOPOC]

Спасибо за старание)) Но вот именно этот хелп у меня есть уже(( А вот где найти саму программу теперь?

[gy1610]

Не уверен, что её просто так найдёте. Это программа входит в состав проццессинга, и отдельно от неё мало проку.

[TOPOC]

Спасибо за небольшую консультацию) Буду пока перечитывать хелп)

[sloginova]

TOPOC, с помощью этой программы Вы получите конфигурацию, которая может быть прогружена на банкомат только с хоста под управлением WAY4. Вы работаете с WAY4?

[cirik]

Может немного не в тему.. Вопрос к тем кто занимается рисованием сценариев...
Есть ли альтернативы ATM Configuration Builder-у? Может есть какие-то варианты софта ещё которые позволяют рисовать сценарии?

На Wincor-е, к примеру, использую стандартный Configuration Manager (View CI - View State, View Screen's), и тут же в реестре можно изменить параметры состояний и экранов.

[Solovei_razboinik]

Добрый день! Возникла такая ситуация: сказали написать конфигурацию, дали утилиту эту, одну конфигу для изучения и всё. Хелп зачитал до дыр, но не помогает. Мне бы какой-нибудь учебник, мануал или любой другой полезный материал, как написать конфигурации. Сам чутка разобрался, но вот отладку адекватно запустить не могу: не получается привязать картинки к стейтам, в итоге при отладке картинки не показывает. Буду очень благодарен, если кто поможет)

[gy1610]

Тут слишком много нюансов. Просто так на коленках конфигурацию с нуля не создашь. Вы под WAY4 работаете? А протокол какой, NDC или DDC? Что должен делать сценарий, только cashout, balance, pin change, statement или ещё и payment сервисы? И это далеко не все вопросы. Для начала почитайте параллельно документацию Wincor с описанием стейтов, скринов и других параметров(User Guide). В принципе, можно понять как работают стейты.
Я больше скажу, почти 10 лет собираю сценарии, но сейчас далеко не всё знаю.

[Solovei_razboinik]

gy1610 Работаю под WAY4 на NDC протоколе. Для начала cash out сценарий. Если бы были хоть какие-то уроки или учебник по написанию конфигураций, а так, как в свободном плавании. Как стейты работают я понял, насчет экранов не понимаю, почему не могу в режиме просмотра увидеть картинку.

[Venique]

Писать сценарии с нуля - дело неблагодарное, т.к. процесс будет построен исключительно на методе проб и ошибок, а учитывая нюансы девайсов и самого Way4... даже если всё изначально заработает, то не факт, что потом не вылезет какой-нибудь косяк (буфер не очистился, повторной инициализации чипа не было и ещё 100500 вариантов). А если ещё тестовый контур "так себе" и чем-то отличается от промышленной базы, то о таких "сюрпризах" вообще по факту узнавать будете. Поэтому самое оптимальное - подгрузить уже готовый сценарий и на его основе добавлять услуги\платежи. Там уже должен быть отработанный state flow, учитывающий нюансы конкретной поставки - работа с emv, буферами, транзакционными запросами и пр. На это накручивать дополнительные меню\услуги\платежи гораздо проще. Некоторые - при поддержке самого OpenWay Support, они дают рекомендации по внедрению того или иного функционала. Обязательно нужен доступ к тестовому контуру - лучше не только эмулятор, но и банкомат, а также доступ к файловой системе контроллера, куда подкладывается файл со сценарием и доступ в DB Manager, чтобы этот самый сценарий на тестовый банкомат прогрузить.

Внешний вид и юзабилити у конфигуратора OW примерное такие же, как и у самого DB Manager'а, поэтому при работе с ним лучше закрывать глаза. В не самых последних версиях было полно багов, из-за которых он мог самопроизвольно схлопнуться. А потом не запуститься. Нынешняя версия (1.12.34 \ 2338), в целом, стабильна. Альтернативы? Serenare Configurator, FIS Open Test Solutions, BP-ATM Load Builder, ещё где-то самопальный ATM Editor проскакивал. Все эти утилиты, как правило, имеют ещё и среду тестирования (если до тестового банкомата лень идти). В Serenare (на счёт остальных не уверен) также есть возможность подключения эмулятора к реальному хосту для получения Transaction Response, чеков и пр., что есть ещё один камень в огород родного конфигуратора OW. Всё это платно, конечно же, и вряд ли компания будет разоряться на дополнительные утилиты, только если это не бОльшая часть рабочего времени её сотрудников (т.е. аутсорс). К тому же, сейчас всё уходит в веб (html-сценарии на основе NDC web-exit state'ов) и альтернативных вариантов ПО (пред-процессинг а-ля платёжный хаб + агент на устройстве + html-сценарий), так что NDC-разработчики, к сожалению, всё менее актуальны. Из фриварного и опенсорсного есть только банкоматный эмулятор - https://github.com/timgabets/electron-atm Лично не тестировал, но наверняка всяко лучше будет, чем OW. С этим подспорьем отлаживать сценарии будет проще, но для финальных тестов лучше всё-таки иметь полноценный банкомат.

Что касается отладчика в конфигураторе OW - для начала смотрите, какой путь у картинок в самом сценарии. Если, например, картинки хранятся в C:\SSDS\DLL\, то этот путь надо прописывать для всех картинок в Объекты -> Параметры -> Настройки NDC -> Экраны -> Картинки из файла для экранов. Т.е. создаёте столько строк, сколько картинок, в "Файл" прописываете, например, C:\SSDS\DLL\1.bmp, а в "Соответствие" 1.bmp, и так для каждой строки. Если помимо этих картинок есть ещё и предопределенные (т.е. описанные в сценарии без абсолютного пути, просто как G01, G02 etc), то их аналогичным образом прописываете в пункте "Предопределенные картинки для экрана" - слева G01, справа G01.bmp. Далее, необходимо импортировать сами картинки через Объекты -> Картинки -> Импорт всех картинок из каталога. Если после их импорта они отображаются в этом списке, то идём в сам сценарий, открываем блок с Экранами, выбираем любой и выставляем режим "Просмотр". Если картинка отобразилась, значит, и в отладчике будет отображаться.

Документация для самого конфигуратора при написании сценариев бесполезна чуть более, чем полностью. Тут нужно ревёрсить уже готовые сценарии, чтобы разбираться, как они работают, а также читать документации по самому протоколу NDC, где досконально описано - какой стейт для чего нужен, какие параметры в нём необходимы и как он работает. Документация по NDC должна быть настольной книгой. Преимущественно - NCR'овская дока по AANDC. Если есть Wincor, то можно ещё почитать их доку, там кое-какие стейты имеют свою реализацию. К сообщению прикрепил актуальные версии (про Wincor не уверен). Если хорошо в них разобраться, то и конфигуратор не нужен, можно весь сценарий прям в старом-добром FAR'е писать, но это медленно и неудобно. По сути, ничего сложного нет, каждый стейт выполняет определённое действие, у каждого стейта есть экран с картинкой, из каждого стейта можно перейти на другой, а всё остальное в нём - какие-то параметры, характерные для конкретного стейта. Для кешина - набор доступных кнопок, для чтения карты - условия чтения дорожек\чипа и пр. Для многих стейтов есть "расширения", где указываются дополнительные параметры. Например, у того же стейта кэшина может быть до пяти стейтов расширения - в одном указываются картинки для того или иного состояния, в другом - список переходов на следующие стейты в зав-ти от условий или список доступных для принятия купюр. Как-то так.

Основной нюанс, наверное, больше в грамотном state flow, который без опыта да с нуля отрисовать проблематично, но когда пару сценариев просмотришь - то вроде бы и ничего сложного, как оказывается. Конкретно кэш-аут будет состоять из стейтов чтения карты (A) -> начало инициализации ICC (+) -> инициализации ICC (,) -> выбор ICC-приложения (.) -> завершения работы с ICC (/) -> ввод PIN (B) -> установка опкода, по которому контроллер и хост поймут, что это за операция (D) -> экран fast cash (выбор или ввод суммы, X) -> ещё раз работа с чипом (/) -> установка транзакционных данных (?) -> отправка запроса на хост (I). Далее эта транзакция с опкодом и буферами (сумма и пр. данные) уйдут на контроллер, с контроллера в Way4, там операция авторизуется и через контроллер, согласно его конфигурационным файлам, Way4 ответит Response Code'ом и соответствующим Next State ID, на который должен будет перейти банкомат. Это д.б. номер какого-то J-стейта (завершение сеанса). В целом, без обвязки, минимальный state flow для выдачи по чиповой карте такой. Но это без основного меню с выбором операции, без выбора языка, без перехода по типу (своя\чужая) карты, без выбора операции с чеком, описания настроек самих стейтов и пр. Если полноценного доступа к контроллеру нет и задача только в "написать конфигурацию", то необходимо узнать, под каким опкодом сейчас заведена операция выдачи, чтобы в сценарии формировать такой же. И какой номер присваивать стейту J как для RC=000 (успешно), так и для ряда RC, соответствующих неуспешному завершению операции.

[booby]

Основной нюанс, наверное, больше в грамотном state flow, который без опыта да с нуля отрисовать проблематично, но когда пару сценариев просмотришь - то вроде бы и ничего сложного, как оказывается.

В доке b6-6297 Aptra EMV Exits есть пример конфигурации для кешаут.

Работаю под WAY4 на NDC протоколе.

NDC - это протокол прикладного уровня. Задача WAY4 - поддерживать этот протокол. К конфигурированию банкоматов WAY4 относится опосредовано. Его задача - прогрузить заданную конфигурацию в банкомат и указывать в TReply номер следующего стейта в таблице стейтов для данной конфигурации. В банкомате конфигурацию отрабатывает прикладной софт, например Aptra. По сути, конфигурирование банкомата - это конфигурирование Аптры.

[Venique]

booby
Всё это справедливо для идеального мира, а по факту имеем абстрактный ndc, некую поставку way4, какую-то сборку софта и костыли между ними на разных уровнях. Ну, или костылики, всё зависит от восприятия этого несовершенного мира. Из коробки оно почти никогда не работает, всегда нужно что-то допиливать на том или ином уровне. Где-то в сценарии костыль поставить, где-то сам вей патч выпустит или скажет, как конфиг контроллера лучше изменить, а где-то от вендора заплатка придёт. Ну, наверное, оно везде так, система-то сложная.

[Solovei_razboinik]

Добрый день! Разобрался с картинками, изучаю стейты. Venique, можете повторно выслать b6-6180 APTRA Advance NDC_Reference Manual_2015, файл поврежден похоже, и если есть у кого b6-6297 Aptra EMV Exits, буду очень благодарен.

[Venique]

docs.zip

[Solovei_razboinik]

Venique, Благодарю!

[Venique]

Solovei_razboinik
перекачайте ещё раз, случайно два одинаковых пдф в архив положил.

[booby]

Интересно, существует ли у NCR дока, которая рассматривала бы Transaction Flow в контексте обмена сообщениями между хостом и банкоматом?
Трудно представить, как используя AANDC Reference Manual разработчики WAY4 писали сервер для Аптры. Ведь Аптра - это клиент-серверное приложение, где в качестве сервера выступает хост с тем же WAY4.