NORD POS. История о том, зачем мне нужен был ещё один форк Openbravo POS

    Вступление


    В прошлой статье я рассказал читателям краткую историю десяти лет развития проекта Openbravo POS. В течении 7 лет я принимал активное участие в нём и совместно с другими участниками разрабатывал систему управления торговой точкой с открытым исходным кодом. Но в этом году я решил перенести все свои накопленные наработки в самостоятельный проект nordpos.mobi и развивать их уже в рамках собственного форка, созданного на базе открытого исходного кода Openbravo POS.



    Истоки


    Ключевой причиной остановки развития Openbravo POS, стал фактический уход из проекта её основателя Эдрина Ромера, он полностью переключился на разработку коммерческой версии Openbravo Web POS и с 2010 года к исходному коду оригинальной версии больше не прикасался. По этому больших надежд на возрождение проекта я не питал, а необходимость в развитие приложения у меня была.

    Практически с первых дней параллельно с общественной работой по локализации Openbravo POS, я вёл разработку внутреннего проекта для бизнеса своей семьи под названием NORD POS. Так как семейный бизнес у нас связан с техническим обслуживанием кассовой и прочей торговой техники, то и в дальнейшем развитие собственного приложения, которое может с этим оборудованием работать, мы были немало заинтересованы. Что и подтолкнуло меня в 2012 году выложить исходный код NORD POS сначала в репозитарий Mercurial на Bitbucket, а затем на GitHub после перехода на Git. Нумерацию версий пришлось начать сразу с цифры 3 по причине того, что одной из главных особенностей моего приложения стала возможность миграции с последней версии Openbravo POS. В итоге, первой версией NORD POS стала версия за номер 3.0.0, в неё вошли не только косметические изменения интерфейса и обновления версий библиотек, но и изменения влияющие на структуру всего проекта в целом.

    Разделение базиса и надстройки


    Само по себе приложение Openbravo POS было в общем самодостаточно для задач организации кассового учёта. В нём присутствовал полный набор функций выполняемых на рабочем месте кассира, но пользователям всё время не хватало возможностей и гибкости подстройки их под специфику того или иного бизнеса. Хотя что-то можно было решить с помощью написания встроенных скриптов, но их сфера действия была ограничена только панелью продаж. Если требовалось как-то изменить бизнес-логику и подключить новое оборудование, то приходилось вносить изменения в ядро приложения. А так как изначально оно было монолитным и разрабатывалось по сути только одним человеком, эти изменения могли затрагивать значительную часть исходного кода. Хотя с версии 2.10, где Эдриан Ромеро выделил генерацию отчётов в отдельный подключаемый ресурс, начался постепенный переход к модульности и расширяемости с помощью выведения части ресурсов из ядра исходного кода приложения, но к сожалению с 2009 года проект был по сути заморожен и этот процесс не получил дальнейшего развития. Также это направление не нашло развитие и в форках основанных на Openbravo POS и мне стало интересно попробовать самому это осуществить.



    Текущая версия десктоп приложения: NORD POS 3.0.1 Community Edition
    Системные требования: ОС Windows или Linux с Java SE 7.
    Интерфейс: Java Swing в десктоп приложении и jQuery Mobile в мобильных веб-приложениях.
    Базы данных: Apache Derby и MySQL в качестве основных, но доступно использовать СУБД PostgeSQL, HSQL, Firebird или Oracle.
    Языки интерфейса: английский и русский.
    Исходный код: github.com/nordpos/nordpos
    Бинарные сборки: sourceforge.net/projects/nordpos/files/app-platform
    Лицензия: GNU GPL v3.

    Подключаемое оборудование в драйверах периферии

    Это решение я подсмотрел в коммерческой версии Openbravo Web POS, где интерфейсы были вынесены с помощью Java SPI в отдельные пакеты для каждого типа оборудования. Это дало возможность разрешить проблему с подключением оборудования, присутствовавшим только на нашем локальном рынке, для которого теперь нет необходимости делать отдельный форк всей системы, а достаточно внести изменения только в один вынесенный в самостоятельную библиотеку драйвер. Таким-же образом в NORD POS реализовано подключение к платёжным шлюзам карточных процессингов.



    На диаграмме представлены реализованные интерфейсы для отдельных типов торгового оборудования. При этом управление дисплеем покупателя, фискальным регистратором, чековым и этикет принтером осуществляется через специальные XML-шаблоны, структура этих шаблонов описана в Schema.Printer.xsd. Также, для реализации работы через подключаемые драйверы, была изменена структура каталогов приложения для правки ресурсов без необходимости компиляция основного пакета.
    • ./services, файлы с объявлением вызываемых сервисов;
    • ./templates, пользовательские шаблоны;
    • ./lib-ext, сами библиотеки драйверов.

    Кроме того, как и в Openbravo POS, к NORD POS могут быть подключены без проблем в режиме клавиатуры сканеры штрих-кодов или магнитных карт.

    Бизнес-логика в мобильных дополнениях

    Про саму идея я уже подробно рассказывал в статье Компактный Java сервлет для мобильного веб, в дальнейшем она могла бы стать флагманом развития Openbravo POS, но к сожалению кроме меня она никем не была подхвачена, и на сегодня является основной для проекта nordpos.mobi отличительной особенностью. При этом, в нём не только размещён исходный код для создания собственных Java-сервлетов, но и есть возможность попробовать работу демонстрационных версий для каталога товара и рабочего места официанта, которые уже скомпилированы и развёрнуты на виртуальной машине в облаке Windows Azure. И сейчас у меня в планах сделать для NORD POS мобильный онлайн магазин и мобильный терминал сбора данных для склада.



    С технической точки зрения, это самостоятельные веб-приложения, имеющие с десктоп-версией NORD POS только общую базу данных, при этом, база данных не сильно отличается от оригинальной, и веб-приложения от NORD POS могут использоваться в связке и с другими форками Openbravo POS. В отличие от десктоп-версии, где взаимодействие с системой управления базой данных осуществлялось через SQL-запросы, в Java-сервлетах для доступа к информации через модель данных используются Java-аннотации библиотеки ORMLite. Список поддерживаемых баз данных через JDBC-драйвер достаточно обширный, а всё что нужно для подключения, это в /WEB-INF/web.xml сервлета указать параметры подключения. При этом единственное условие, чтобы в папке /WEB-INF/lib был JDBC-драйвер для соответствующей СУБД. Вот пример настроек для MySQL:

        <context-param>
            <param-name>db.URL</param-name>
            <param-value>jdbc:mysql://localhost:3306/nordpos?useUnicode=yes&characterEncoding=UTF-8</param-value>
        </context-param>    
        <context-param>
            <param-name>db.user</param-name>
            <param-value>nordposuser</param-value>
        </context-param>    
        <context-param>
            <param-name>db.password</param-name>
            <param-value>nordpospassword</param-value>
        </context-param>
        <context-param>
            <param-name>db.application.id</param-name>
            <param-value>nordpos</param-value>
        </context-param>
    


    Визуальные схемы для синхронизации данных

    Ещё одной необходимой особенностью POS программ является наличие в них средств интеграции с другим программным обеспечением уже внедрённым или планируемым к внедрению. У нас это обычно 1С, за границей это различные ERP-система, также очень часто это бывают интернет магазины, построенные как на популярных CMS, так и самописные. Чаше всего разработчики POS в качестве универсального решения используют выгрузку и загрузку в текстовой файл, который затем обрабатывает внешняя система. Но мне понравилось решение, использовать специализированное программное обеспечением для ETL. В версии Openbravo POS 2.30 использовался комплекс программ Pentaho Data Integration. Так как это более универсальный подход, то в нём можно как подстраивается под API чужих систем, так и реализовывать собственные варианты обмена данными. В Pentaho Data Integration используется визуальный подход к процессу извлечению, преобразованию и выгрузки данных. Например, схема для выгрузки из базы данных NORD POS таблиц товаров, категорий и налогов будет выглядеть следующим образом.



    Схемы преобразований Pentaho Data Integration можно запускать несколькими способами: из графической оболочки, командной строки, по расписанию, через веб-сервер или встроенный в другое приложение API. Для NORD POS я выбрал последний вариант, так как он наиболее удобен пользователям.

    Реализована интеграция схем трансформации была аналогична интеграции шаблонов отчётов JasperReports. В визуальном редакторе создаётся схема трансформации.



    После чего в текстовом редакторе или IDE для её вызова из приложения создаётся скрипт.

    transformation = new com.nordpos.sync.panel.PanelTransformationBean();
    
    transformation.setTitleKey("Menu.SyncImportProducts");
    transformation.setTransformation("/com/nordpos/transformations/csv/IMPORT_PRODUCTS.ktr");
    
    transformation.addTransVariable("db.URL", this.app.getProperties().getDBURL());
    transformation.addTransVariable("db.driver", this.app.getProperties().getDBDriver());
    transformation.addTransVariable("db.user", this.app.getProperties().getDBUser());
    transformation.addTransVariable("db.password", this.app.getProperties().getDBPassword());
    
    transformation;
    

    В нём, как даётся ссылка на схему, так и задаются параметры переменных необходимые для выполнения преобразования. Если преобразование будет связанно с обработкой информации из базы данных, то обязательно необходимо задать параметры подключения к ней. Затем в ресурсе приложения Menu.Root задаётся кнопка и вызов панели выполнения скрипта в меню приложения.

            submenu.addPanel("/com/openbravo/images/database_imp.png", "Menu.SyncImportProducts", "/com/nordpos/transformations/csv/import_products.bsh");
    

    А в правах роли пользователя разрешается доступ к ней.

        <class name="/com/nordpos/transformations/csv/import_products.bsh"/>
    

    Перезапустив приложение можно будет уже непосредственно из него выполнять по схемам Pentaho Data Integration загрузку данных из внешних файлов в NORD POS.



    Встроенные серверы


    Сервер базы данных

    Базой данных по-умолчанию в Openbravo POS была Apache Derby, но не сетевая версия, сразу с возможностью нескольких одновременных подключений, а встроенная версия от JDBC-драйвера только с одним одновременным подключением. При этом для подключения нескольких POS-систем к одной базе данных необходимо было либо устанавливать сервер Apache Derby, либо выбирать другую СУБД в которой функция для одновременного подключения нескольких соединений поддерживалась изначально. Также использовать несколько подключений было необходимо для обменна данных через Pentaho Data Integration. Так как функция миграции с Openbravo POS на NORD POS была у меня запланирована изначально, то в качестве удобного средства обновления базы данных я решил использовать встроенную версию Apache Derby Network Server. Теперь для обновления достаточно скопировать папку с базой данных от Openbravo POS в папку .derby-db каталога пользователя, прописав в URL JDBC-драйвера её наименования, и обновление пройдёт автоматически. Если в качестве хранилища используется другая СУБД, то запуск встроенного сервера можно отключить.

    Сервер веб-приложений

    Так как основной аудиторий NORD POS будут всё-таки простые пользователи, неискушённые в вопросах установки веб-серверов и развёртывания веб-приложений в контейнерах сервлетов, то по аналогии с встроенным сервером базы данных в приложение был интегрирован веб-сервер Jetty 9. Запускается он опционально, если в настройках это задано.



    Веб-приложения устанавливаются в папку ./webapps непосредственно в каталоге NORD POS, при установке необходимо предварительно скомпилированное содержимое war-файла распаковать в папку с соответствующим названием. После запуска NORD POS, по названию этой папки в строке браузера, будет доступно установленное веб-приложение.

    Ещё изменения и планы


    Кроме перечисленных выше достаточно глобальных изменений, есть в NORD POS и не столь кардинальные:
    • обновлены полностью все библиотеки, в том числе, RXTX заменён на Neuron Robotics Java Serial, а JasperReports обновлён до 4.8.0;
    • поддержка двумерных штрих-кодов DataMatrix и QR-код;
    • возможность использовать скидки на всю сумму чека или на отдельные позиции;
    • новые отчёты;
    • подсветка синтаксиса в ресурсах и скриптах;
    • набор иконок Faenza и тема Сream по-умолчанию.

    Ещё планировалось, но пока осталось нереализованным, перевести работу с базой данных на ORMLite, а расчёты делать в BigDecimal, также как это уже сделано в мобильных веб-приложениях.
    В остальном я хочу сейчас больше сконцентрироваться на отработке уже сделанного и создании расширений к тому базису, что удалось создать в первой публичной версии NORD POS(например, уже сейчас существует ветка для реализации в ней оплаты с помощью Bitcoin). Но при этом, я больше всего заинтересован в привлечении новых участников к работе над проектом. Так что, если после прочтения этой статьи у вас появилось вопросы по автоматизации в торговле, то всегда рад помочь и рассказать больше о том, как это можно сделать используя открытый код NORD POS.
    Поделиться публикацией

    Похожие публикации

    Комментарии 17

      +2
      Приветствую, Андрей! Спасибо за подробный рассказ.

      Скажи, на твой взгляд решения на базе wi-fi микро компьютеров (vocore, blackswift) применимы в нише торговли? (может быть только в складских задачах)

      Как успехи с RPi?
        +1
        Илья, спасибо за первый комментарий. Рад, что статья получилась интересной, а то я всё думал публиковать её сейчас или уже после НГ.

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

        По факту сейчас, у каждого производителя железа свой интерфейс управления, и каждый раз приходится в приложение писать отдельно интеграцию под него, да есть стандарты типа Java POS и OPOS, но для них если и есть драйвера, то только у крупных и дорогих брэндов, а у китайских более дешёвых аналогов с этим всегда проблемы. Я вижу решение в том, чтобы на уровне ПО микрокомпьютера реализовать эту интеграцию с оборудованием, а уже с микрокомпьютера для управления с тех-же POS-систем использовать веб-интерфейса типа JSON или Google ProtoBuffer. В этой схеме микрокомпьютер будет выступать в качестве сервера оборудования. Эта идея была уже реализована в коммерческой версии версии Openbravo Web POS, но там из-за необходимости запуска Java SE клиента приходится использовать как раз RPi.

        К сожалению на RPi запустить NORD POS можно, но из-за интерфейса на Java Swing, он страшно тормозить. Сейчас правда пробую использовать RPi в качестве локального сервера для развёртывания Java-сервлетов, наверное и следующая статья будет об этом. Также хочу попробовать, в качестве альтернативы тяжеловесной графической оболочке сделать текстовую, к тому-же сейчас появился интересная библиотека Lanterna для реализации консольного GUI на Java.
          +1
          Если есть драйвера для устройства под dos и x86 то можно сэмулировать с помощью qemu
            0
            Для меня проще сразу просить описание протокола нижнего уровня, а если у железа он закрыт, то лучше поискать другой вариант железа, благо это не ракетные технологии и предложений торгового оборудования всегда в избытке. Но если другого выхода нет, то можно попробовать через эмуляцию и драйверы идущие в комплекте. Я как-то так мучился с одним терминалом сбора данных, в итоги прослушал параллельный порт, посмотрел в каком виде он шлёт байты при обмене и сделал тоже самое напрямую без участия драйвера.
              +1
              Это логично, но в случае миграции со старой проприетарной POS системы о варианте поиска другого железа можно не мечтать. Reverse engineering может стать дорогой и сложной задачей
                +1
                Огромное спасибо вам за развитие открытого проекта! И вдвойне комфортнее что это привычная java
          +4
          BarcodeString, строки 44 и 52: не используется результат String.substring.
          JTicketsFinder, строка 142: не используется результат Throwable.getMessage. Как следствие, двумя строками ниже будет NullPointerException, а информация о реальном исключении потеряется.
          VectorerBuilder, строка 75: используется результат toString для массива: получится строка вроде "[B@aec71234". Вряд ли это то, что действительно хотелось.
          TicketLineInfo, строка 285: при выполнении этого кода гарантировано будет NullPointerException. Видимо, хотели написать attributes.remove(«product.attsetdesc»);
          TaxesLogic, строка 58: сравнивать объекты типа Integer по == скорее всего некорректно. Это может работать правильно, если они все меньше 127 и создаются через Integer.valueOf (то есть берутся из кэша), но в один прекрасный день может сломаться.

          Используйте статический анализ :-)
            +1
            Спасибо! Учту и честно признаюсь, что до чистки кода пока руки не дошли.
              0
              Вот так исправил, ещё раз спасибо за подробное замечание. А ссылки на код в GitHub делали вручную или чем-то автоматическим пользовались?
                +1
                Вручную.
                Сравнение Integer можно было короче написать:

                return o1.getApplicationOrder().compareTo(o2.getApplicationOrder());

                Зачем возиться с больше-меньше и писать три ветки, когда это давно написано за вас? :-)
                  0
                  Ещё спасибо за статью про класс Comparator, а то код не мой и не до конца было понятно, почему сделано было так, как сделано :)
                    0
                    Пожалуйста :-) Вообще этот ваш код и натолкнул меня на написание детектора для FindBugs, хотя у вас и не double.
              0
              Скажите, а какое количество внедрений OpenbravoPOS в реальные торговые точки за эти 10 лет? И как часто отказываются в пользу традиционных платных решений?
                +2
                К сожалению таких цифр у меня, но если брать с форками, то думаю порядка 50.000+ по миру уж точно наберётся. Точно не меньше, так как например даже в России фискальные регистраторы СПАРК шли вместе с ККС: РМК 3.0, которая была основана на версии 2.10.
                  +2
                  А по второму вопросу. Как любой OpenSource, это относительно бесплатное решение, так как вы будете либо своё время тратить на внедрение и освоение системы, либо нанимать специалиста, который это сделает за вас.

                  Из своего опыта скажу, что Openbravo POS обычно выбирают небольшие магазины, где хозяин готов сам освоить и внедрить систему. Более крупный ритэил выбирает Openbravo POS только если уверен, что сможет поддерживать систему самостоятельно, в этом случае экономия на стоимости лицензии при тиражировании.
                    +2
                    Вы же наверное и есть тот самый специалист? Скажите, реально ли заработать на внедрении и поддержке Openbravo или форков? По моему личному опыту что-то продать мелкому бизнесу (в том числе и услуги по внедрению) крайне сложно: они как сидели на своем АМС и вели товароучет в тетрадке, так и сидят, и не понимают зачем им что-то менять.
                    А те кто покрупнее, вы абсолютно правы, обычно покупают популярные решения с поддержкой производителя.
                      +1
                      Впрямую вполне реально, но к сожалению пока не у нас. Приходится придумывать схемы, платите за железо, а софт бесплатно. Но даже это на наш малый бизнес чаще всего не срабатывает, так как зачастую и за железо не готовы платить. Я чаще всего сталкиваюсь с рассуждением, что нам проще ещё одного продавца нанять, чем 400-500 у.е. за компьютер+сканер штрих-кодов заплатить. У нас именно малый бизнес выигрыша в скорости обслуживания от автоматизации не видит. За границей немного всё по другому, с теми с кем я работал, зачастую сами за прилавком стоят и делают автоматизацию под себя, для них СПО решение это самое то. Да это не ERP, но для ежедневного ведения учёта подходит, так как оперативно можно отслеживать товарно-денежный поток проходящий через твой магазин.

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

                Самое читаемое