Gnc mdb ölklrinin mdniyyt paytaxtı

Что если в качестве протокола, связывающего монетник, банкнотник и систему безналичной оплаты, использовать протокол MDB?

Шина mdb что это

Речь пойдёт о двух основных протоколах, или даже — философиях, реализации информационного взаимодействия торговых автоматов и платежных систем. Сразу оговоримся: об «умных протоколах», поскольку мы не будем рассматривать простейшие варианты подключения платёжных систем к торговым автоматам. В простейших вариантах платёжные системы, по существу, исполняют роль датчиков, например: принял монетоприемник монетку — выдал импульс по проводку.

Если у Вас стоит монетоприемник с функцией выдачи сдачи, плюс банкнотоприем- ник, да еще считыватель ключей безналичной оплаты, то, скорее всего, соединение платежной системы с торговым автоматом реализовано либо по протоколу EXECUTIVE (он же SIMPLEX V, он же PROTOCOL «А»), либо по протоколу MDB (ICP — почти то же самое). На самом деле, протоколов намного больше, но, во-первых, наибольшее распространение в мире, и в нашей стране в частности, получили именно эти два протокола. А во-вторых, все остальные протоколы реализуются на аналогичных идеях. Мы думаем, нижеизложеная информация будет интересна и тем, кто только собирается войти в вендинговый бизнес, и тем, кто в нем уже давно находится.

1. Немного истории

Протокол EXECUTIVE был разработан компанией MEI Global (Mars Electronics). Стандарт был окончательно определён в начале 80-х, в дальнейшем подвергся некоторой доработке, связанной с появлением устройств безналичной оплаты (cashless systems). В настоящее время наиболее распространён в странах европейского региона. Протокол MDB разработан в начале 90-х компанией CoinCo (США), о которой мы писали в предыдущем номере, специально по заказу компании Coca-Cola. Он был разработан с целью снизить стоимость монетоприёмника, путем переноса части вычислительных и диспетчерских функций в контроллер торгового автомата. В 1994 году протокол был официально принят NAMA (National Automatic Merchandising Association, USA) после того, как был доработан и адаптирован для подключения банкнотоприемника, а также системы безналичной оплаты. Позднее EVMMA (European Vending Machine Manufacturers Association) сертифицировала протокол ICP (Internal Communications Protocol); фактически, это тот же самый MDB, только с некоторыми доработками для систем безналичной оплаты. Позднее, в 1998 году, появился унифицированный протокол MDB&ICP, который сегодня является стандартом таких организаций как NAMA, EVMMA, EVA (European Vending Association). Наибольшее распространение протокол MDP&ICP получил в США, Латинской Америке и России.

2. Описание работы протоколов

Для начала несколько слов о принципиальном различии этих двух протоколов. Платёжная система и торговый автомат взаимодействуют друг с другом по схеме master-slave, или «ведущий- ведомый»; другими словами, кто кем командует: автомат платежной системой или платежная система автоматом, соответственно, где находится «мозг» платежной системы — в автомате или в самой платежной системе.

На рис. 1 показана схема подключения монетоприёмника, работающего по протоколу EXECUTIVE (далее ЕХЕ), к торговому автомату. Как интерфейс Executive, так и MDB являются по существу протоколами с последовательной передачей данных (serial), то есть данные передаются последовательно по каналам «монетоприемник — автомат» (Тх) и «автомат — монетоприёмник» (Rx). В протоколе ЕХЕ мозгом платежной системы является, как правило, монетоприемник. Бывает также, что управляющим, контроллером может выступать система безналичной оплаты, но это встречается крайне редко. Торговый автомат в этом случае занимается только своими прямыми обязанностями, то есть готовит напиток или выдает продукт.

2.1. Стандартный сценарий работы автомата

Вы подошли и опустили энную сумму в монетоприемник. Монетоприемник ее принял, подсчитал ее значение и вывел информацию о ней на дисплей, то есть выдал несколько управляющих команд по линии Тх (см. рис. 1). Далее вы нажимаете кнопку интересующего Вас продукта. Торговый автомат по линии Rx отправляет некоторую последовательность сигналов, таким образом сообщая монетоприемнику, что у него выбран, например, кофе эспрессо.

Монетоприемник анализирует информацию о цене данного продукта и выдает автомату по линии Тх последовательность команд, суть которых сводится к следующему: выдать, или не выдать, но показать недостающую сумму, или показать стоимость данного товара.

Читайте также: В качестве шины можно использовать полотенце гибкий кабель

Если с кредитом все в порядке, и пошла команда от монетоприемника на выдачу товара, торговый автомат начинает выдачу, о чем сообщает монетоприемнику. Получив этот сигнал, монетоприемник производит подсчет необходимой сдачи. Далее в зависимости от того, как настроена функция продажи (одиночные продажи — выдача сдачи после выбора товара, множественные продажи — остаточный кредит высвечивается на дисплее), происходит либо выбор товара на сумму остаточного кредита, либо нажатием кнопки «получение сдачи» покупатель инициирует выдачу сдачи. В альтернативном варианте автомат, вычитает стоимость товара из суммы кредита.

После выдачи товара автомат посылает сигнал монетнику: выдача товара прошла удачно (или неудачно); в первом случае всё возвращается в начальное положение, во втором — монетник выдает стоимость товара сдачей.

Существует два режима работы торгового автомата:

В этом случае цена на товар устанавливается на торговом автомате. При этом фактически диапазон цены может быть изменен от 1 до 250, но перед тем, как отправить это число монетоприемнику, оно умножается на некоторый коэффициент, который в вендинге принято называть scaling factor (коэффициент масштабирования).

Автомат сообщает: «нажата кнопка стоимостью: цена-«scaling factor»

Монетник выдает команду: «выдать» или «не выдавать».

2. Executive Price Holding Mode «режим удержания цены»

В этом случае все цены устанавливаются на монетоприемнике, а каждому продукту на торговом автомате присваивается ценовая линия. При этом в данном случае, перед передачей значения ценовой линии в монетоприемник, оно делится на scaling factor.

Общение автомата с платежкой происходит следующим образом:

Автомат сообщает: «выбран товар: ценовая линия / scaling factor»

Монетоприемник анализирует стоимость этой ценовой линии, далее все, как в Executive standard

2.2. Протокол MDB

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

Все устройства (монетоприемник, банкнотоприемник, системы безналичной оплаты) подсоединяются к общей шине (набор проводов). При включении торгового автомата (ТА), контроллер ТА производит опрос по этой шине и таким образом узнает о наличии различных платежных устройств в системе. После этого ТА непрерывно опрашивает каждое устройство и узнает его состояние.

Например, Вы подошли к автомату и опустили 10 рублей в банкнотоприемник; ТА последовательно опрашивает каждый компонент платёжной системы одним вопросом: «у тебя что?»

Монетник отвечает: «у меня ничего», то же самое отвечает и система безналичной оплаты.

А вот банкнотоприемник ответит: «у меня 10 рублей». ТА проанализирует ответ и выдаст команду: «принять» или «не принять» банкноту. После принятия купюры Вы выбираете напиток, ну, предположим, за 6 рублей; ТА его Вам выдаст, после чего даст команду монетоприемнику выдать 4 рубля сдачи.

В общем, главным думающим элементом в этом случае является торговый автомат.

Законный вопрос: а как быть с банкнотоприемником при подключении по протоколу Executive?

Ответ очень прост: поскольку управляющим устройством в данном случае является монетоприемник, то давайте присоединим к нему банкнотоприемник в качестве устройства, которое будет принимать купюры и передавать информацию о принятой купюре монетнику, а тот, в свою очередь, будет всего лишь выдавать обратно два управляющих сигнала: «работай» или «не работай». Так и поступили.

Но сразу возникли 3 проблемы:

1. Допустим, в монетоприемнике кончилась сдача, он выключил банкнотник, но если у нас цены все по 10 рублей, то десятирублевые купюры тоже не будут приниматься, хотя могли бы.

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

3. Такая же проблема и с подключением систем безналичной оплаты.

Читайте также: Как правильно рассчитать размер шины

Выход был найден

Что если в качестве протокола, связывающего монетник, банкнотник и систему безналичной оплаты, использовать протокол MDB?

То есть с одной стороны монетник является управляющим устройством для автомата, а с другой — MDB мастером для банкнотоприемника и системы безналичной оплаты; на рис.3 показано именно такое подключение.

Данное решение является наиболее распространенным на текущий момент, но существуют и другие.

Например, система безналичной оплаты подключается к торговому автомату как управляющее устройство Executive, а к ней подключается все остальное как MDB-ведомые устройства и.т.д., и.т.п.; короче говоря, комбинировать можно до бесконечности.

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

Монетоприемники EXE или MDB: какой протокол выбрать и почему

Сегодня предлагаю поговорить о протоколах монетоприемников. Посмотрим какие они бывают, чем отличаются, какие предпочтительнее и выгоднее в работе и т.д.

Следует отметить, что протоколы монетоприемников бывают, в основном, двух видов:
— протоколы взаимодействия с исполнительными устройствами вендингового автомата (контроллером, ПК и пр.);
— протоколы аудита, которые используются для сбора статистической информации с платежки (к примеру, DEX/UCS).

Нас интересуют протоколы первого типа, а точнее, самые распространенные из них – протоколы последовательных интерфейсов MDB и EXE. Оба сертифицированы Европейской вендингового ассоциацией, широко распространены в Европе, в России, да и в мире в целом.

Протокол Executive (EXE, Protocol A) разработан производителем платежных систем Mei (Mars Electronics International) в начале 80-х годов. Первоначально протокол использовался исключительно в работе монетоприемников, позже на нем стали работать и устройства безналичной оплаты. В дальнейшем, на его основе, был создан протокол BDV, преимущественно для немецкоговорящих стран, хотя сейчас BDV поддерживают и автоматы других производителей, к примеру, итальянские Saeco.

Протокол MDB/ICP (MDB) использует абсолютное большинство производителей торговых автоматов. Его спецификация окончательно принята в 1998 году и поддержана всеми основными вендинговыми организациями (EVA, NAMA, EVMMA). Создателем первой версии MDB является известный производитель платежных систем CoinCo. Именно к этому разработчику, в начале 90-х годов, обратилась корпорация Coca-cola, а впоследствии сделала крупный заказ на разработку новых и более дешевых монетоприемников для использования в своих торговых автоматах. CoinCo справилась с задачей, в итоге на свет появился монетоприемник, работающий по протоколу MDB.

За счет чего же монетоприемник стал дешевле?

Для того, чтобы ответить на этот вопрос, достаточно понять общий принцип взаимодействия монетоприемника и вендингового автомата по протоколу MDB/ICP и сравнить его с работой оборудования по протоколу EXE.

Как монетоприемник «общается» с торговым автоматом

При работе по протоколу MDB, ведущим (главным) в связке «автомат – платежка» выступает контроллер (ПК или другое управляющее устройство). В процессе работы именно автомат посылает монетоприемнику команды на выполнение транзакций.

Происходит это примерно так: Торговый автомат циклически опрашивает все подключенные платежные устройства, а в ответ, получает от них информацию о том или ином состоянии. К примеру, о внесенной сумме денег, об опустошении тубы монетоприемника, о переполнении бокса купюроприемника, о неисправностях и т.д. Команды на выполнение действий (подсчет сдачи, выдача сдачи и проч.) отдает автомат. Монетоприемник является ведомым оборудованием: все основные операции производит исполнительное устройство автомата, и, соответственно, вся статистическая информация накапливается и хранится в памяти торгового автомата.

Абсолютно противоположная ситуация наблюдается при работе с монетоприемником по протоколу Executive. Монетник принимается решения, а автомат занимается только своими прямыми обязанностями – готовит напиток, выдает товар, оказывает услугу. Цены на товары и услуги могут храниться либо в платежном устройстве (режим Price Holding), либо в торговом автомате (режим Standart). Монетоприемник опрашивает автомат и отдает ему команды, принимает аванс, рассчитывает и выдает сдачу, а также собирает в своей памяти всю статистику.

Читайте также: Шины зимние 17565 зимние

Именно такая повышенная функциональность монетоприемников Executive и объясняет их более высокую стоимость по сравнению с mdb-монетниками.

Какая разница в цене

Чтобы посмотреть разбег в цене предлагаю сравнить цены на модель NRI Currenza Blue для вариантов MDB и Exe:

Mdb – от 350€
Exe — от 355.00€
Отдельно модификация exe в продаже встречается редко, обычно поставщики предлагают мультипротокольные монетоприемники, которые поддерживают одновременно несколько протоколов, среди которых MDB и Exe.
Стоимость мультипротокольного монетоприемника NRI Currenza Blue EXE/MDB начинается от 385€.

Мультипротокольный монетоприемник NRI Currenza Blue

То есть разница в цене будет порядка 30€ за один монетник. Кроме того, для снятия статистики с монетоприемников, работающих по протоколу Executive, потребуется дополнительное устройство. Например, для NRI – это USB Audit stick, его стоимость начинается от 230 евро:

Преимущества и недостатки монетоприемников Exe и MDB

Преимущества EXE:
— Универсальность статистики. При работе по MDB форматы и объем статистики напрямую зависит от разработчика вендингового автомата и может сильно отличаться.
— Возможность перестановки монетоприемника с одного автомата на другой без потери статистических данных
— Независимость денежных расчетов от прошивки автомата. Даже на самом «сыром» торговом автомате сдача покупателю будет выдаваться правильно.
— Использование сервисов онлайн-мониторинга и компьютерных программ и т.д. для всей сети разношерстных автоматов. Справедливости ради, следует отметить, что взаимодействие автоматов и платежных систем по протоколу MDB также постепенно идет по пути унификации. Однако для Executive этот вопрос решен изначально.
— Контроль работы наемного персонала однозначно выше при использование протокола Exe.

Недостатки EXE:
— Стоимость монетоприемников выше на 10-15% + необходима покупка дополнительного оборудования и/или оплата обслуживания автомата в системах онлайн-телеметрии.
— не все вендинговые автоматы умеют работать с этим протоколом. На сегодняшний день протокол mdb используется в около 70% автоматов, соответственно Exe поддерживает чуть более 30% производителей.

Преимущества MDB:
— более дешевая стоимость
— практически все современные торговые автоматы работают с монетоприемниками по протоколу MDB
— нет необходимости в дополнительных устройствах для снятия статистики.

Недостатки MDB:
— разные объемы и форматы статистики для разных моделей автоматов.
— снятие статистики «на бумажку» при росте сети создает проблему контроля за наемным персоналом.
— все денежные операции напрямую зависят от правильной работы прошивки автомата.
— отказ контроллера торгового автомата почти всегда означает потерю накопившихся данных.

Что выбрать EXE или MDB?

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

Если сеть автоматов большая и предполагает наличие наемного персонала, то предпочтительнее работать c монетоприемниками Executive. Это обеспечит усиленный контроль за работой операторов и частично обезопасит от воровства.

Также удобно использовать Exe в том случае, если сеть состоит из разнородных торговых автоматов разных производителей, так как можно будет всю статистику отправлять в одну программу или систему онлайн-статистики. Конечно, это при условии, что большинство автоматов сети работают с монетоприемниками по протоколу Executive.

Для однородных небольших сетей, без наемных операторов и претензий на серьезный рост, особого профита от использования exe-монетников не будет. Надежность и производительность обоих типов монетоприемников одного и того же производителя находится примерно на одном уровне.

Рекомендую подписаться на обновления, чтобы первыми получить новый материал от Вендоведа на свой E-mail:

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  Gnc mdb ölklrinin mdniyyt paytaxtı

  Çağırır indi bütün milləti imdada Vətən, Dəyişilməz ey oğul, cənnətə dünyada Vətən.

  B.Vahabzadə

  You are here

  Qırğızıstanın Karakol şəhəri 2022-ci il üçün MDB-nin mədəniyyət paytaxtı elan edilib

  Sədrəddin Ayni adına Tacikistan Dövlət Akademik Opera və Balet Teatrında “Düşənbə-MDB-nin mədəniyyət paytaxtı-2021” ilinin bağlanış mərasimi keçirilib.

  Xudaferin.eu AZƏRTAC -a istinadən xəbər verir ki, bağlanış mərasimində MDB İcraiyyə Komitəsi sədrinin – icraçı katibin müavini Beketjan Jumaxanov, Düşənbə şəhəri sədrinin müavini Amirxon Kurbanzoda öz çıxışlarında il ərzində Düşənbədə görülən işlərdən danışıblar.

  Sonra onlar Qırğızıstanın İssık-Kul vilayətinin Karakol şəhərini 2022-ci ildə MDB-nin mədəniyyət paytaxtı elan ediblər.

  Cavab nitqi ilə Qırğızıstanın Tacikistandakı Səfirliyinin müşaviri Meder Soorbekov çıxış edib, estafetin Karakol şəhərinə keçməsindən məmnun olduğunu bildirib, 2022-ci il ərzində planlaşdırılan layihələrdən danışıb.

  Qulu Kəngərli

  Работа с JMS сообщениями и MDB в JEE

  Работа с сообщениями подразумевает взаимодействие между компонентами системы посредством передачи сообщений. JMS позволяет реализовать это взаимодействие в java приложении, а MDB бины позволяют асинхронно обрабатывать получаемые сообщения на сервере приложений без дополнительных усилий по асинхронной обработке.

  Ниже представлен простой пример обработки JMS сообщения с помощью MDB.

  Немного теории

  Для работы с сообщениями используется вспомогательное программное обеспечение, обычно входящее в поставку сервера приложений.
  Компоненты системы могут посылать сообщения (producer) и получать их (consumer). Сообщение
  отправляет producer на пункт назначения (destination), являющимся на сервере queue или topic, после чего consumer может забрать оттуда сообщение
  В зависимости от того, какой тип имеет destination, разделяют две модели работы с сообщениями.

  Первая модель — Point-to-Point

  В случае если на сервере destination имеет тип queue, то сообщение, которое отправил producer, получает единственный consumer. Если на эту очередь сообщений подписано несколько получателей, то сообщение получит только один из них.

  Вторая модель — Publish-subscribe

  В случае если на сервере destination имеет тип topic, то одно сообщение может быть прочитано неограниченным количеством consumer, подписанных на этот на этот destination.

  Структура JMS сообщения

  Сообщение состоит из заголовка, поля свойств и тела.
  Заголовок хранит мета информацию сообщения, заполняемую автоматически.
  Поле свойств схоже с заголовком, но оно заполняется программно, и позже получатель сможет прочитать эту информацию.
  Тело содержит полезную нагрузку сообщения. Тип нагрузки определяется при создании сообщения. Конкретные типы унаследованы от интерфейса javax.jms.Message

  Создание очереди на сервере.

  Для примера создадим topic на сервере. Использовать я буду glassfish 3.1.
  Для начала создадим Connection Factory. Возможны несколько типов в зависимости от того, какой тип очереди сообщений будет использоваться.

  Затем создаем destination с указание типа.

  Создание отправителя сообщений

  В данном случае producer будет находиться на сервере приложений. В случае если вам необходимо отправлять сообщения из отдельного клиента, то необходимо будет стандартным образом получить доступ к объектам по их JNDI имени из контекста.

  //получаем ресурсы сервера для отправки сообщений @Resource(name="jms/TutorialPool") private ConnectionFactory connectionFactory; @Resource(name="jms/TutorialTopic") private Destination destination; public String getEnterString() < return enterString; >public void sendString(String enterString) < try < //создаем подключение Connection connection = connectionFactory.createConnection(); Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE); MessageProducer producer = session.createProducer(destination); TextMessage message = session.createTextMessage(); //добавим в JMS сообщение собственное свойство в поле сообщения со свойствами message.setStringProperty("clientType", "web clien"); //добавляем payload в сообщение message.setText(enterString); //отправляем сообщение producer.send(message); System.out.println("message sent"); //закрываем соединения session.close(); connection.close(); >catch (JMSException ex) < System.err.println("Sending message error"); ex.printStackTrace(); >> 

  Message-Driven Bean

  Для обработки приходящих сообщений на сервере мы будем использовать MDB.

  Сообщения можно было бы получать и обрабатывать и с помошью pojo, выступающего как consumer. Но использование MDB позволит параллельно обрабатывать сообщения, не заботясь о сложности асинхронной обработки и дополнительного кода для подписки на очередь сообщений.
  Асинхронная обработка реализуется через пул объектов, из которых на обработку сообщения сервер выделят объекты при необходимости.

  Для реализации MBD достаточно унаследовать бин от интерфейса javax.jms.MessageListener, реализуя метод onMessage(), и аннотировать соответствующим образом класс.

  Сделаем пример MDB, который выводит в консоль сервера информацию о поступившем сообщении.

  @MessageDriven( //имя topic, на который подписан бин mappedName="jms/TutorialTopic", name = "ExampleMDB") public class MDBExample implements MessageListener < //метод, вызываемый при получении нового сообщения @Override public void onMessage(Message msg) < try < TextMessage message = (TextMessage)msg; //считываем свойство из соответствующего поля, заданное вручную в consumer System.out.println("FROM MDB - client type IS " + message.getStringProperty("clientType")); //считываем само сообщение System.out.println("FROM MDB - payload IS" + message.getText()); >catch (JMSException ex) < ex.printStackTrace(); >> > 

  В onMessage метод добавляется необходимая бизнес логика, в зависимости от типа сообщения, его содержания и тд.
  При необходимости, для ручной обработки сообщений можно самостоятельно создать обработчика.
  Например так:

   @Resource(name="jms/TutorialPool") private ConnectionFactory connectionFactory; @Resource(name="jms/TutorialTopic") private Destination destination; void onMessage() < try < Connection connection = connectionFactory.createConnection(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer consumer = session.createConsumer(destination); connection.start(); while(true)< Message msg = consumer.receive(); //обработка сообщения >//закрыть connection > catch (JMSException ex) < ex.printStackTrace(); >> 

  Для более подробного изучения JMS и EJB в целом, могу рекомендовать книги:
  EJB 3 in Action — Debu Panda, Reza Rahman, Derek Lane
  Пару книг от Adam Bien

  Related posts:

  1. Azrbaycan dili kiçik summativ qiymtlndirm ksq 1 9 sinif
  2. Pərinuş sənii mənim payım
  3. Beynelxalq iqtisadi teskilatlar
  4. Güləbatın