Онлайн-чеки по федеральной сети посредством RabbitMQ, 1С и черной магии


    В прошлом году к нам обратился ИТ-директор одного из крупнейших аграрно-промышленных холдингов в России. Подход к бизнесу, который реализовал наш клиент, был впечатляющим. Он одним из первых реализовал идею предприятия полного цикла – от поля до полки в продуктовом магазине. Благодаря доступности и высокому качеству продукции этот холдинг стал признанным брендом, который знают и выбирают. В тот момент в холдинг входило более 650 торговых точек и более 20 000 сотрудников, распределенных по всей территории РФ.


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


    С учетом указанной специфики решение задачи превратилось в увлекательное приключение с бубном, шаманами и кроличьими лапками в лице RabbitMQ. Как мы строили федеративный кластер очередей и с чем столкнулись – под катом.


    О проблематике заказчика


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


    В действующей системе время доставки чека от кассы до центральной системы доходило до 3-х суток. При этом периодически фиксировалась не доведение информации о совершенной покупке (потеря чека).


    Требовалось обеспечить получение информации о продажах «здесь и сейчас» для оптимизации доставки продукции в торговые точки и оперативного реагирования на изменение остатков товара и спроса. Эта информация должна одновременно попадать в центральную ИС холдинга на базе 1С и на компьютер товароведа в конкретном магазине/торговой точке.


    Кроме того, требовалось обеспечить централизованную и оперативную переоценку товаров по сети, а также, подключить к BI-системе холдинга поток онлайн-данных со всех торговых точек.
    В итоге, были сформированы критерии успешности проекта:


    • чеки, пробитые на кассе магазина, должны быть видны в центральной системе 1С не более, чем через 1 секунду от момента его «фискализации» на кассе при наличии (исправной работе) связи;
    • при временных сбоях связи обеспечить оперативную гарантированную доставку чеков в центральную систему после восстановления канала связи.

    Для команды «Серебряной Пули» это была очень заманчивая штука, поскольку мы на тот момент уже разработали наш адаптер 1С для RabbitMQ и возможность запустить его в бой на больших расстояниях и нагрузках манила гиковские умы. Сама концепция “позиция чека в центре за 1 секунду” не так уж нова, мы еще в 2013 году презентовали идеи применения очередей в 1С, и даже аппробировали ее на одной торговой сети, но на тот момент это были сильно экспериментальные костыли, включавшие помимо Rabbit+1С еще C#, WCF и даже немного С++.


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


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


    Ныряем с головой


    Никто лучше владельца бизнеса не знает о его сильных и слабых сторонах, поэтому все интеграционные проекты начинаются с аудита процессов клиента, понимания отправной точки (AS IS). Обычно, обследование бизнеса включает в себя:


    • анализ информации о том, как бизнес-процессы протекают сейчас;
    • сбор требований к системе путем опроса ключевых сотрудников с целью понять, как, по их мнению, должны быть устроены бизнес-процессы;
    • формализацию и оптимизацию бизнес-процессов.

    Чтобы исключить разночтения мы используем формализацию бизнес-процессов AS IS и TO BE в виде схем BPMN. Так и самим разбираться легче, и заказчику проще ничего не упустить, когда совместно с ним проходим по схеме процессов.


    Из технических особенностей, в процессе аудита выяснили, что:


    • торговые точки используют Windows-машины – с установленными разнородными операционными системами (в зависимости от года создания) от Windows XP до Windows 7, 8, 10;
    • кассовые аппараты работают под управлением встроенного ПО «Frontol» с Windows Embedded на борту;
    • контур управления розничной торговлей использует разнородное ПО, включающее как решения от вендоров 1С, так и собственные разработки;
    • каналы связи реализованы по принципу «что есть, то есть» в диапазоне от кабельных линий до USB модемов-свистков;
    • розничные торговые точки обслуживаются местными компаниями-аутсорсерами, а не централизованной службой холдинга;
    • функционирование системы существенным образом зависит от исправности (надлежащего функционирования) компьютера товароведа на каждой торговой точке.

    Схема интеграции AS-IS


    Схема интеграции AS-IS


    Аудит также показал, что бизнес-процессы компании практически не нуждаются в корректировке, но требуется доработка инфраструктуры, обеспечивающая бесперебойное прохождение информации.


    В общем и целом, перед нами стояла задача надежной доставки документов между тремя компонентами процесса: кассовым аппаратом, компьютером товароведа и центральным офисом. При этом, компьютер товароведа – это машина «под столом». Она может включаться/выключаться по желанию товароведа. Или вообще быть выключенной 23 часа из 24-х. Однако, при выходе из сумрака товаровед должен видеть актуальный набор цен, остатков, номенклатурных позиций и т.п.


    Выбор решения, сбор граблей и расстановка костылей


    Событийная интеграция на очередях уже давно стала общеупотребимым паттерном. Когда вам нужно передавать что-то куда-то, со многими звеньями, в ненадежной среде, и при этом потоки данных маршрутизировать – вам нужны события и очереди. Поэтому, мы выбрали RabbitMQ, поскольку он легко интегрируется в любую (нам так казалось) среду, включая платформу 1С, для которой у нас уже был собственноручно сделанный адаптер AMQP-протокола.


    RMQ является своего рода менеджером потоков данных и позволяет обеспечить интеграцию в режиме «почти реального» времени, сохраняя при этом слабую связанность систем, выдерживая нагрузки, и прочее и прочее… Хороший сервер, одним словом, на Хабре про него написано немало.


    Одной из приятных особенностей является кластеризация «из коробки» и возможность построения распределенных кластеров серверов, работающих совместно.


    image


    Мне всегда нравились картинки с архитектурой интеграции на очередях. Они всегда состоят из трех кубиков, в центре которых – брокер сообщений. Пусть такая картинка будет и в этой статье, дабы не нарушать канон.


    При построении схемы встал вопрос – а где должен располагаться сервер очередей? В каких состояниях у нас может оказываться система? Выяснили, что существует 5 штатно-нештатных ситуаций при которых работа не должна останавливаться.


    1. Все блоки включены.
    2. Отключен центр, есть доступ к товароведу.
    3. Отключен товаровед, есть доступ к центру.
    4. Отключены и товаровед и центр.
    5. Отключена система 1С.

    Чеки во всех этих ситуациях должны пробиваться, торговля не должна останавливаться. При восстановлении канала – чеки должны прибывать подписчику. Напомню, что торговая точка – это может быть и сельский ларек. Там не установлен отдельный сервер, на который можно было бы поставить RMQ. Получалось, что брокер сообщений должен стоять непосредственно на кассе. Сервера – это непозволительная роскошь, а Rabbit достаточно легковесный и вполне может работать на маленьком POS-терминале. Так почему бы и не да?


    Разумеется, мы не стали делать POS единственной нодой кластера RMQ, но один из узлов федеративного кластера разместили прямо на торговом терминале, под управлением Windows Embedded. Сказать это было несколько легче чем сделать, но мы весело и азартно справились. О чем сейчас и расскажу.


    Как поставить RMQ терминал Frontol


    Надо сказать, что Erlang и сам сервер RMQ на винду терминала встал практически без проблем. Проблемы возникли в клиенте, который должен взаимодействовать с сервером из кассового ПО.


    Кассовое ПО Frontol имеет достаточно годную документацию, из которой мы выяснили, что имеется возможность кастомизировать поведение с помощью Javascript. «Йухху!» — сказали мы и принялись гуглить JS-клиент для RabbitMQ. Довольно быстро выяснилось, что нас ждет облом. На фронтоле не совсем Javascript. Ну т.е. формально да, синтаксис там такой же, но сама машина JavaScript там от Windows Script Host, того самого, который VBScript, cscript.exe и прочее. Если кратко, то он очень старый, микрософто-специфичный, и ни один вменяемый JS-клиент кролика на нем не заработает.


    Однако, в экосистеме WSH можно использовать COM-объекты, и мы направились в сторону клиента RMQ для .NET.


    Современные версии этого клиента уже не поддерживают .NET 3.5, который имелся в нашем распоряжении на POS-терминале, но к счастью, исходники клиента открыты, а кроме того, на гитхабе проекта сохранились теги, в которых .NET 3.5 все еще поддерживался. Слава Опенсорсу! Оставалось выкачать исходники старой версии .NET клиента, поставить там галочку Com-Visible и задеплоить на терминал.


    Взаимодействие с кассой Frontol


    Кассовое ПО имеет API, который можно использовать для взаимодействия.


    function init() {
        frontol.addEventListener("openDocument", "beforeOpenDocument", true);
        frontol.addEventListener("closeDocument", "beforeCloseDocument", true);
        frontol.addEventListener("closeDocument", "afterCloseDocument", false);
        frontol.addEventListener("closeSession", "beforeCloseSession", true);
        frontol.addEventListener("closeSession", "afterCloseSession", false);
    
        addPolyfills(); // полифиллы рулят )
        initRmqVariables();
        createRMQConnection();
    }

    Возможности родного JS, который есть на борту Windows – крайне бедны. Например, там нет Array.indexOf или JSON.stringify. Но мир ведь не без добрых людей. Мы вспомнили популярный браузерный костыль по имени «полифиллы», и радостно встроили их в кассу. Если отбросить шутки в сторону, то все магические трюки с JS намеренно дотошно комментировались, чтобы поколения будущих админов могли четко и быстро понять – что происходит, откуда взялось и как работает.




    Довольно быстро выяснилось, что JS-API не покрывает часть наших кейсов, однако, поскольку Frontol имеет в своем составе СУБД Firebird, а к ней существует ODBC-провайдер, то с помощью того же самого ADODB мы сможем из Javascript обращаться сразу в базу кассы и доставать там нужные нам данные.


    function afterCloseSession() {
    
        var connection = getDatabaseConnection();
    
        var qSelect = new ActiveXObject("ADODB.Command");
        qSelect.ActiveConnection = connection;
        qSelect.CommandText =
            "SELECT ChequeNumber " +
            "FROM Document " +
            "WHERE " +
            "   State = 1 " +
            "   AND(ChequeType IN(0, 1, 2)) "
    

    Ну и наконец, непосредственная работа с сервером очередей из нашего JS выглядит следующим образом:


    function createRMQConnection() {
        factory = new ActiveXObject("RabbitMQ.Client.ConnectionFactory");
        factory.UserName = rmqUser;
        factory.Password = rmqPass;
        factory.VirtualHost = "/";
        factory.HostName = "localhost";
    
        try {
            rmqConnection = factory.CreateConnection(0);
        } catch (e) {
            throw new Error("Ошибка подключения к локальному серверу очередей. Обратитесь к администратору!\n" + e.message);
        }
    
        rmqChannel = rmqConnection.CreateModel();
    
        rmqMessageProperties = rmqChannel.CreateBasicProperties();
        rmqMessageProperties.ContentType = "text/plain";
        rmqMessageProperties.ContentEncoding = "string";
        rmqMessageProperties.DeliveryMode = 2;
    }

    Общая картина решения


    В архитектуру заложили следующие принципы:


    • федерация RabbitMQ серверов — режим серверов RMQ — Federation, чтобы события были доставляемы всем получателям;
    • локальная выживаемость кассы – если событие произошло на кассе, то оно должно быть доставлено в любом случае, даже если в настоящий момент кассовое рабочее место недоступно по сети;
    • 2 доставщика данных – в обычном режиме данные доставляется через сервер (компьютер товароведа), в случае недоступности (в результате аварии или по другим причинам) компьютера товароведа – доставку осуществляет сама касса, когда компьютер товароведа будет включен он получит свою порцию событий позже центра, но гарантированно;
    • RMQ – служба RabbitMQ сервер с отрытыми TCP портами для кластеризации и обмена сообщениями;
    • для обеспечения гарантированности доставки сообщений применено резервирование потоков данных. Таким образом обеспечивается минимизация влияния сетевого соединения между узлами системы;
    • в 1C: Центр было решено установить комплект серверов RMQ в режиме НА — высокая доступность центрального сервера, в т.ч. есть двойное резервирование и репликация событий, для гарантии доставки.


    В соответствии с архитектурным решением создана следующая схема потоков данных:


    • Frontol, 1C – начальная и конечная точки обмена – объекты являющиеся источниками и получателями сообщений;
    • федеративная очередь – специальный тип очереди, позволяющий создать распределенную систему для передачи сообщений, в которой публикация в очередь может выполняться в узле, расположенном на торговой точке (upstream), а их получение из очереди в центре (downstream). За передачу сообщений от upstream к downstream отвечает специальный плагин (Federation PlugIn), устанавливаемый на центральном сервере очередей;
    • Shovel — (буквально «лопата») – механизм передачи сообщений из одного объекта (очереди) в другой. Объекты могут принадлежать как одному серверу, так и разным;
    • архитектура системы предусматривает дистанционное управление развёртыванием, то есть возможность установки серверов RabbitMQ на любой компьютер сети холдинга из единого центра;
    • настройка и соединения в федерацию проходится с помощью так называемых Post-Install скриптов, которые штатно идут с поставкой RMQ серверов, с необходимой настройкой сетевых параметров, принятых в сети Заказчика.

    Полученная в результате схема обеспечивает заказанные характеристики по скорости и стабильно работает при выпадании любого из компонентов. После пропадания и восстановления связи накопленные данные уходят в центр в течении 5-10 секунд. На практике доказала свою эффективность технология слабо связанных систем. Все события происходят как будто в одном офисе, без учёта различного вида задержек, связанных с территориальной распределённостью и свойственной ей различной степенью доступности каналов связи.


    Краткое заключение


    Хочется отдельно порадоваться тому, в какое удивительное время мы живем. Еще недавно применение Open Source в продуктиве было этакого рода подвижничеством. «У вас открытое ПО работает? Ну и как вам по вкусу этот кактус?» Сегодня же, это абсолютная максима.


    Я не могу себе представить компанию, в которой бы не было в продуктиве продуктов с открытым исходным кодом. Благодаря доступности информации, открытым исходникам, реализовывать бизнес-идеи стало намного проще и быстрее. Нужно поставить RMQ на древний нестандартный Javascript и Windows? Нет ничего проще. Нагугленное решение немного не подходит? – посмотри, как сделано и добавь недостающее. Time-to-Market при применении открытых продуктов сокращается в разы. А все знают, что быстрый выпуск решения означает конкурентное преимущество.


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


    Ну и конечно, отдельно радует, что сообщество 1С-ников с каждым годом все дальше выходит из своего закрытого мирка и вливается в глобальный IT. Например, «1C:Enterprise» на сегодня – это один из официальных языков, поддерживаемых Github, и «научили» его этому языку люди из сообщества 1С. Эта история, наверное, заслуживает отдельной статьи, возможно, я когда-нибудь ее напишу. А пока – всего вам доброго и удачи!


    Спасибо за уделенное время!

    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 53

      0
      История интересная, но у меня вопрос из «области общих знаний» :)
      По моим воспоминаниям из прошлой жизни, вот такое требование:
      чеки, пробитые на кассе магазина, должны быть видны в центральной системе 1С не более, чем через 1 секунду от момента его «фискализации» на кассе при наличии (исправной работе) связи

      в основном нужно для гордой демонстрации, и слабо нужно для реальной жизни.
      Т.е. когда люди хотят оперативно иметь z-отчеты — понятно, когда чеки используются в системах лояльности — тоже плюс/минус понятно, а вот когда для «оперативного принятия управленческих решений» — тогда не очень
      А ваш клиент озвучил, зачем ему данные с такой точностью? Или мои воспоминания можно сдать в архив и чековая лента из 650-ти точек в базе может чему-то реальному помочь?
        0
        Чеки нужны оперативно. Зачем — ну можно много придумать зачем. Те же резервы товаров, например. В данном конкретном случае, 1 секунда это не бизнес-критичная величина. И 1.5 секунды и 5 секунд, на самом деле, подойдут. Просто у нас получалось за секунду. Не замедлять же теперь )
          0
          Придумывать неинтересно :) Резервы в продуктах на розничных точках — это что-то новое :)
          Андрей, речь не о вашем решении, как таковом. Речь идет о том, чем заказчик мотивировал необходимость такой оперативности обменов.
          Если вы не вникали и решали такую задачу просто как технологический вызов — это тоже ответ и он ± понятен.
            +1
            Резервы в продуктах на розничных точках — это что-то новое

            Видимо вы мало работали с ритейлом. Обычное дело, вообще-то. Разве что с едой пример неудачный. А в целом по торговле — запросто.

            «Просто технологический вызов» — это мимо. Любое внедрение начинается с целей, это аксиома. Я не участвовал на самом старте проекта и природу цифры в 1сек. уже не назову (или напутаю). Думаю, коллеги, которые больше в теме, подтянутся в топик и расскажут.
              +2
              Речь идет о том, чем заказчик мотивировал необходимость такой оперативности обменов.


              Вы же понимаете, что мотивация была — при таких проектах без бизнес-обоснования никуда. Другое дело почему мы на технологическом портале публично должны обсуждать бизнесменов и их мотивацию, а также как они на проекте «чек за секунду» заработали денег… мне это несколько неожиданно.

              Я так понимаю — то что вы хотите спросить это ТЭО проекта и откуда взялись целевые показатели которых нужно было добиться.

              Вообще данный проект — лежит в плоскости BI и «Онлайн анализа данных.

              Чем могу поделиться вот прямо сейчас — это фразой из прошлогоднего сентябрьского исследования компании Nuclear Research

              “Companies don’t have the luxury any more to wait weeks for reports on the profitability of business decisions in increasingly fast paced markets. New analytics solutions are being developed around this need where businesses can make better decisions, faster”


              Отсюда:

              Ключевые слова тут — faster и don't wait. То есть быстрей и меньше ждать.
              Сейчас исследователи (обоснованно причем) заявляют следующее:

              * компании которые не вкладываются в повышение скорости принятия решений на основе анализа данных не получают „ништяков“
              * на каждый вложенный доллар „сейчас“ ожидайте возврата инвестиций в размере 13 долларов в течении трех лет.

              Но я все таки вынужден спросить — зачем вам исходная бизнес-задача и бизнес-мотивация? Почему вас например не волнует — как администрировать 2000 инстансов RabbitMQ в сложной топологии сети…

              Кстати Z-Отчет и закрытие смены — это тоже событие и тоже прилетает за секунду.

              Лично персонально я уже неоднократно рассказывал, что онлайн продажи — позволяют запускать в компании онлайн платежный календарь, потому как можно в реальном времени планировать график платежей и на этом зарабатывать. Потому что если мы уже знаем информацию о выручке на кассе, эти деньги мы можем спокойно отправлять на банковский счет с процентами „на сутки“.
              В прошлом году я столкнулся с одной компанией которая на подобном механизме зарабатывала столько процентов по вкладу, что этого хватала на возмещение расходов по аренде помещений.
                0
                А какие были сложности в администрировании 2000 RMQ серверов?
                  0
                  При администрировании любых серверов возникают сложности, а уж если их несколько сотен или тысяч, да еще на Винде, тогда совсем непросто :)
                    0
                    НЕ администрирования — как настройки. Тут как раз все штатно и хорошо.

                    rabbitmq-ctrl --help

                    речь идет о http management api в удобном едином интерефейсе, такого у rabbitMQ не предусмотрено. Pivotal.io искренне убеждены что управление и оркестрация сервисов rmq-xx должно ложится на внешний сервис управления инфраструктурой. Например в OpenStack это делается спец UI в режиме администратора облака.

                    Вообщем решения то есть, но найти их оказалось проблематичным.
              0
              чековая лента из 650-ти точек в базе может чему-то реальному помочь


              Есл вопрос из области общих знаний, то делюсь информацией — очень даже может помочь…

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

              первая:

              * центральная товарная система — назовем её «товарка». Например её задача в режиме реального времени рассчитывать потребности в товаре по компании, чтобы снизить возвраты «скоропорта» например хлеба. Обратная логистика очень дорогая. Для решения такой задачи — скорость доставки данных с физических точек продажа очень важна — даже «час» здесь слишком мног, не говоря уже о днях и неделях.

              вторая:

              * система расчета розничных цен компании — назовем её «прайс-лист». Её задача в режиме реального времени обеспечивать такую предлагаемую цену в компании, которая позволяла была достигать планового объема продажа, при сохранении прибыльности по позиции (номенклатурной группе) не ниже точки-безубыточности+норма-прибыльности-в-среднем по рынку. Таким образом переоценка-переназначение розничных цен по отдельным позициям в компании можем происходить достаточно часто в течении дня, соответственно для такого алгоритма данные о продажах также нужны в режиме близком к реальному.

              Это кстати — 2 реальные системы из 2012 года и их 2 реальные бизнес-задачи. Заказчик правда другой (если перейти по ссылке на доклад в статье — можно даже понять кто этот волшебный заказчик).
                +1
                Переоценка. Несколько раз в день. А вот интересно как заказчик проблему с ценниками решил?
                — Продавцы эти (бумажные) ценники несколько раз в день переписывают?
                — Покупателю если что говорят «Вы мне ценник и что там — дешевле, не показывайте! У нас в базе другая цена! Компьютер не может продать по той что на ценнике» (при том что по закону — должны продать по цене на ценнике...)
                — Ценники сами обновляются с того самого компьютера товароведа (потому что они на eInk).
                Ой что-то мало верится в последний вариант. Больше — во второй.
              –2
              Непонятно, зачем было тянуть полифиллы в кассовое ПО. Если там есть поддержка ES3 — ее вполне достаточно, чтобы выбрать данные о чеке и переслать их дальше. Добавление ES5/6 выглядит как бессмысленное усложнение. Тем более что ничего незаменимого там не добавлено. Или ваши разработчики не знают отличий версий JS и не способы писать под определенную версию?
                +2
                Я наверное непонятно донес. Там не JS, там весьма специфичное микрософтовское видение этого языка. Там даже не ES3
                  –1
                  Что мешало использовать Node.js?
                    0
                    Где именно?
                  +2
                  там даже до es3 было далеко. Это майкрософтовский JScript ХРшного разлива с выпиленными библиотеками к тому же. Там не то, что какого-нибудь Math нет, там даже JSON пришлось целиком полифилить
                  Где-то треть полифилов была добавлена действительно для удобства эээ меня в том числе, как привыкшего к typescript и es6 и с содраганием вспоминающего эпоху pre-es5. Но остальное приходилось добавлять для реально нужных вещей или для работы других более высокоуровневых полифилов (не переписывать же официально рекомендованные от Mozilla)

                  Если честно, я не понимаю изначального «наезда». Ну скопипастили несколько готовых полифилов, они все упакованы в немешающие функции где-то «внизу», на производительность влияют минимально, а скорость и стоимостью разработки сокращают. В чем проблема-то?

                  P. S. На скриншотах в статье не все полифилы, которые были добавлены.
                  0
                  Интересно было бы узнать исходную бизнес-задачу.
                  С технической стороны все в выигрыше — и клиент доволен, и исполнитель за счёт клиента «прокачался».
                    +3
                    Странно слышать такой вопрос. Зачем публично обсуждать исходную бизнес-задачу — это уже лежит в плоскости коммерческой информации, а не технической — на мой взгляд Хабр не то место где обсуждаются бизнес-цели, бизнес-задачи и способы заработка. Хотя на мой взгляд исходная бизнес-задача читается между строк сама собой.

                      0
                      Я к тому, что в исходной задаче, например, было не 1 секунда, а 1 минута. И тогда логичен вопрос — а стоило ли такой огород городить? Но решение хорошее, конечно, знание что «так можно» пригодиться.
                        +2
                        Вообще-то очереди сообщений, это давно известный и общеупотребимый паттерн.
                        Насчет оперативности, ну представьте, что вы торгуете чем-нибудь в розницу и у вас 4000+ торговых точек по стране. Кроме того, люди покупают товары у вас на вашем же сайте и оформляют там доставку. Покупает человек, например, розовый айфон с доставкой. Откуда ему удобнее привезти? С центрального склада за 2-3 дня? Или с магазина в его собственном же подъезде, сократив таким образом расходы на логистику и обеспечив сервис «доставка за 20 минут»?

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

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

                        Можно ли называть это «огородом»? Обычно это называют качественным преимуществом.
                          0
                          Есть альтернатива — работа всех точек в общей базе, например Деловые линии пошли по такому пути. Ну и доставку в течении минуты можно и без очередей обеспечить. Если реально надо в течении секунды — да, скорее всего альтернатив очередям нет.
                            0
                            Не забывайте про разные торговые точки.
                            Были точки на селе, или на окраинах, где простые 3G-свистки, частенько работающие в режиме 2G.
                            Какая уж тут ЕБД??
                              0
                              Я безгранично уважаю ДЛ за умение работать с большой ЕБД на 1С в режиме Highload 24/7. Мой прагматизм говорит, что проще делать распределенные системы. Но это я исключительно за себя говорю. Возможно, ДЛ когда-нибудь опубликуют цифры — во что им обходится владение их системой. Я на коленке считал ЕБД vs МиниСервисы — получилось в пользу сервисов.
                                0
                                Ну и доставку в течении минуты можно и без очередей обеспечить


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

                                * RemoteAppPublication — от Microsoft
                                * Citrix (Дай ему бог здоровья)
                                * Тонкий клиент 1С по HTTP с поддержкой сжатия и режима нестабильных каналов связи (напомню что тут очень сильно может помочь использование Varnish)

                                НО — помимо доставки данных в течении секунды, в ритейле важны 2 вещи

                                * локальная выживаемость места продажи — принять деньги от клиента и продать ему важней всего остального
                                * слабая связанность места продажи в распределённой федеральной сети — регламетные работы в центральной БД не должны останавливать работу всей федералки…

                                «что они делаю на КАМАЗе» — в сообществе уже неоднократно посмеивались над одним волшебным розничным ритейлером сотовых телефонов который расскатал на федералку единую базу 1С: Розницы в режиме удаленных тонких клиентов и что потом получилось с этой базой и почему там пришлось делать тюннинг почти на уровне ассемблера ;-) центрального сервера 1С

                                У Деловых другой портрет — они же торгуют другим: им главное чтобы сайт был доступен 24/7 и мобильные приложения где клиенты резервируют машинки. И я вангую что как раз на сайте либо rabbitMQ либо Kafka.
                                  0
                                  Про ритейлера с единой базой — этот случай? infostart.ru/public/857978
                                  Если этот — то они вроде как всем довольны :)
                                    0

                                    Не скажу ни да ни нет… чтобы не нагнетать. Кстати автор по указанной ссылке хитрит — во второй части статьи он немного срывает покровы



                                    Но вскрываются не до конца… открытым остается вопрос:


                        0
                        Я конечно понимаю желание, когда хочется все сделать на встроенных компонентах системы, но всегда наступает момент выбора, или добавлять новый внешний компонент, или продолжать пытаться запихать сложный функционал в эту древнюю систему.
                        В итоге вы добавляете внешние компоненты для .NET и ODBC-провайдер на кассы, и при этом продолжаете писать магию на встроенном Jscript. Что мешало написать свой .net-класс и его вызвать из Jscript.
                        В любом случае будет наступание на грабли, как развернуть на все кассы .net-компоненты
                          0
                          Магия JS была обусловлена тем, что Фронтол позволяет его использовать.
                          В итоге было разделение — Net-часть обеспечивала работу с кроликом, а JS-часть — специфику Фронтола + обращение к серверу Кролика.

                          Мы как раз не стали смешивать в единую компоненту специфику Фронтола и специфику кролика.
                            0
                            Ну и напомню, что работа с «древней» системой — это одно из ограничений проекта.
                            Т.к. подобное ПО развернуто было давно и вполне себе успешно работало на всех кассах заказчика.
                            0
                            Ну блин… Писать текстовые сценарии всяко же проще, чем компилируемые сборки, не?
                            0
                            А пробовали ли для отправки сообщений использовать REST-интерфейс Рэббита? Сейчас хотим запустить своими силами интеграцию 1Ски с шиной — подписку на сообщения я реализую через прокси-сервер на Java, а вот отправку похоже что придется делать через REST.
                              0

                              Не советую. Rest не обеспечит вам ту пропускную способность, которую даст чистый amqp. Да еще и писать прокси-сервер. Кажется что дешевле будет просто купить наш адаптер к 1С

                                0
                                Обращались к вам. Мое руководство отложило все на 4й квартал (возможно). Поэтому быстрее свое решение сделать.
                                А как вам решение Связного?(привет бывшим коллегам).
                                  0
                                  Странное руководство у вас. Написать с нуля и отладить сервер, обучить админов его поддержке и мониторингу, передать падаванам компетенции по его развитию… Все это быстрее и дешевле покупки компоненты ценой в ползарплаты программиста?

                                  Решение Связного также содержит внешний сервер и требует governance со стороны Java команды. А так хорошее решение все пользуются.
                                    0
                                    Какое такое решение Связного — их там 3. Я прям изнываю от любопытства какое решение имелось ввиду — дживс, вустер или индийский комплект софта.
                                      0

                                      Ну Андрей правильно понял — то которое с Apache Flume.

                                        0

                                        Которое с индийским комплектом + flume + mssql +

                                          0

                                          Кстати, а как должен был работать невзлетевший вустер? Про дживсы-то я в курсе, благо дорабатывал DRP)

                                            0

                                            Мы немного не узнаём вас в гриме )

                                              0
                                              О мертвых либо ничего, либо хорошо и не публично ;-)
                                            0
                                            Тогда я могу ответить почему НЕ решение на базе Apache Flume + Индусы.

                                            Во первых — тому кто прикрутил flume лично я бы хотел при случае задать несколько нескромных вопросов откуда он нарисовался. Почему НЕ nats.io или deepstreamhub.com/open-source/?io — уже несколько лет прошло, а выбор этот для нас очень сильно неоднозначен.

                                            Во вторых — индусы то развиваются и на сегодняшний день лучше запускать ballerina.io, потому как сами индусы выбрали это направлении приоритетным и пилят и пилят.

                                            В третьих — к RMQ можно прикрутить штатно и быстро (за сутки)

                                            * бизнес-приложения QliickView, SAP.Hibris, SAP, Microsoft Dynamics, Oracle OEBS, Oracle DB, PostgreSQL.DB, MSSQL.DB, — весь код и релизы лежит на github
                                            * программы на 1C, С#, C++, Java, GoLang, Node.JS, python, etc — весь код и релизы лежит на github

                                            Вот как раз экосистема адаптеров к RMQ и самая главное — горизонтально-распределенная архитектура с закосом под слабую связанность и есть самые главные преимущества.
                                      0
                                      REST интерфес Рэбита предназначен для менеджмента сервера, для работы в виде транспорта данных предназначены протоколы AMQP 0.9 (1.0), MQTT, Stomp (WebStomp). Смысл пробовать если в документации напрямую написано — НЕ надо.
                                        0

                                        В документации написано чуть иначе:)
                                        Please note that the HTTP API is not ideal for high performance publishing; the need to create a new TCP connection for each message published can limit message throughput compared to AMQP or other protocols using long-lived connections.

                                      0
                                      Если мне память не изменяет, то в итоговой схеме федеративную очередь если не полностью выпилили, то минимизировали её использование и максимально задействовали showel (конкурс на лучший перевод этого слова). И наверное стоило добавить что был реализован еще и обратный канал: установка цен номенклатуры из центра.
                                        0
                                        По состоянию на сегодня федеративная очередь вернулась обратно, и ты прав переоценка таки поехала вниз.
                                          0
                                          shovel — перебросчик
                                          0
                                          Поясните такие моменты.

                                          1) С вводом онлайн касс у нас все ведущие поставщики касс имеют на борту ФН с отправкой данных напрямую в ОФД. Данные по чекам можно брать через их API. Или у вас ОФД без API? Вторая приходящая в голову причина — требуется детализация чека в разрезе содержания в нем товарных позиций. Или вы этот самый внутренний ОФД писали?

                                          2) Как решается вопрос с длительной недоступностью кассы (по сути данных с неё), больше суток допустим, и построением отчета? Ведь он по сути искажен. Делалась ли какая подсветка/подсказка в духе "… по данным с ХХ% касс"? Делалась ли какая-то агрегация данных (часовая? суточная? месячная?) для отчетов данные по котором 100% докатились до центральной системы?
                                            0

                                            1) Эта история была до появления ОФД и онлайн-касс. Как сейчас обстоит дело, я не знаю.
                                            2) отчеты были самые разные, в том числе и по "недогруженным кассам", но вообще — принимать какие-то стратегические решения по оперативным данным в течение дня, это вообще странноватое занятие. День в учете не зря формальным образом "закрывается" z-отчетом кассы. Даже безо всякой недоступности кто-то может просто придти и сделать возврат товара например.

                                              0
                                              1) Просто статья опубликована в 2018 году, а кассы ввели с середины 2017-ого. Видимо история еще более давняя?
                                                0

                                                Да, статья написана пост-фактум

                                              0
                                              Отвечу коротко — у меня чуть больше информации «на сегодня»

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

                                              И вы правы — похожесть позволяла бы спаразитировать на API оператора фискальных данных. «В короткую» это скорее было бы верно.

                                              НО — задача «Единая фискальная память» по компании и «Онлайн розничные чеки» немного разные задачи. Собственно в итоге была добавлена и функциональность обратного RPC для «онлайн опроса кассовых аппаратов» о текущем состоянии. Вместе с этим на основе данных системы стали строиться и BI отчеты в специализированной системе — а там простор для диаграмм как мы знаем велик.

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

                                              И если подытожить коротко ответы на ваши вопросы:

                                              1. Нет — это не внутреннний ОФД — задача шире.
                                              2. Решается — простым DWH+Dashboard (назовем это BI с большой натяжкой)
                                                0
                                                А я правильно понимаю, что плагин Federation по сути использовался для организации кластера и коробочный механизм кластеризации erlang-а не использовался? И очередь внутри RMQ находящегося в POS кассе (под управлением WinXP) через этот плагин просто переливалась в другую очередь другого RMQ сервера в моменты когда связь с торговой точкой восстанавливалась? А пока со связью были перебои пробитые чеки копились в RMQ кассы (по сути реализация ФН)?
                                                  0
                                                  В финальном варианте (август 2019 года) используется связка Federation+Shovel — удалось ее понять и настроить. Она ответственна за поток бизнес-интеграции.
                                                  Штатный кластер на базе Erlang используется как основа для HA — но ни в коем случае не для потоков интеграции.
                                                  Со связью перебои всегда — это же в не которых местах GPRS связь.
                                                  P.S. Насчет «просто переливалась» — я бы на вашем месте так не думал: я думал также на старте — там «перелив по правилам». Совсем не просто.
                                                    0
                                                    Совсем не просто.

                                                    На статью может потянет?

                                            Only users with full accounts can post comments. Log in, please.