All inclusive или как "ослики, кролики и редиски" уживаются вместе с 1С

26.07.21

Интеграция - WEB-интеграция

На Infostart Meetup «Интеграционные решения для 1С» выступил замруководителя ИТ-отдела в компании WiseAdvice Евгений Винниченко. Евгений рассказал о том, как «зоопарк» из RabbitMQ, Redis и уживаются вместе с 1С и какую роль в слаженной работе этого ПО играет шина MULE ESB.

Меня зовут Евгений Винниченко, я работаю в компании WiseAdvice на должности замруководителя отделом ИТ. WiseAdvice – группа компаний: есть франчайзи 1С, бухгалтерский аутсорсинг, патентно-адвокатское бюро. Я это рассказываю для того, чтобы слушатели поняли: стек задач, которые приходится решать, находится в разных предметных областях.

 

О теме доклада

 

 

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

История тривиальная. Нашей компании как аутсорсеру бухгалтерских услуг приходится загружать выписки с банковских счетов клиенту в 1С. При этом мы хотим, чтобы наши бухгалтера на эту ежедневную задачу тратили как можно меньше времени.

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

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

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

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

 

Первая итерация

 

 

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

Первая итерация показала, что наш русский язык действительно великий, и его ничем не измерить. Доля успешно разнесенных новых документов при таком подходе – 30-40%. Хороший результат, но этого недостаточно, чтобы помочь нашим бухгалтерам выполнять рутинную задачу по разнесению выписок.

Команда, которая занималась разработкой, восприняла это как провал и попыталась доработать механизм. После нескольких итераций разработки мы поняли, что не знаем ничего лучше конструкций ПОДОБНО в языке запросов 1С. Итоговый результат использовал эту конструкцию везде.

На слайде как раз представлен один из вариантов использования этой конструкции для поиска слов в назначении платежа.

 

Расстояние Левенштейна

 

А потом один из участников команды услышал о такой метрике как расстояние Левенштейна.

 

 

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

В Яндекcе, Гугле, во всех поисковых движках высчитывается расстояние Левенштейна. На его основе выдается рекомендация тем же Гуглом, когда мы в поисковом запросе делаем опечатку.

На слайде показана общая формула для нахождения расстояния Левенштейна.

Команда, которая занималась задачей по автоматическому разнесению банковских выписок, сначала хотела реализовать эту формулу в языке 1С.

Но перед началом разработки один пытливый ум решил поискать, может, существует уже изобретенный «велосипед», который можно использовать в стеке 1С. И, оказалось, что программного обеспечения, где считается расстояние Левенштейна, достаточно много. Например, есть библиотека для Python, которая выполняет данные расчеты.

Но более интересным с нашей точки зрения стало то, что в Elasticsearch есть API, которое умеет выдавать нужные нам рекомендации.

 

Elasticsearch

 

 

Elasticsearch – поисковый движок, основным назначением которого является полнотекстовый поиск. У нас в компании он используется для хранения не1С-ных логов и для поиска контактов при работе с телефонией. То есть, компетенции для работы с Elasticsearch у нас существуют.

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

Понятно, что скорость поиска той или иной записи в журнале регистрации, которая загружена в Elasticsearch, была несоизмерима со скоростью поиска просто в журнале регистраций. Но все-таки 5 раз…

 

 

Вернемся к целевой задаче. Напомню, что мы автоматизируем авторазноску банковских выписок в базах клиента.

Чтобы Elasticsearch посчитал расстояние Левенштейна, ему нужны данные. Мы создали индекс под каждого клиента (по сути, под каждую базу) и наполнили данными проведенных документов.

Итоговая модель работы алгоритма такова:

  • Алгоритм автоматического разнесения банковских выписок обращается к движку Elasticsearch для получения ранее проведенного документа с наиболее похожим назначением платежа.

  • Если алгоритм успешно обработан, реквизиты документа заполняются на основе ранее проведенных документов, и документ проводится.

  • Такие же проведенные документы отправляются в Elasticsearch для формирования корректной работы механизма в дальнейшем. Таким образом, мы пополняем данные, которые улучшат работу нашего механизма от документа к документу. С каждым проведенным документом механизм работает все продуктивнее.

  • Документы, которые алгоритм не смог корректно обработать, заполняются все так же руками. Такие документы тоже отправляются в Elasticsearch для пополнения индекса.

На слайде представлен фрагмент запроса, который отправляется в Elasticsearch.

При использовании Elasticsearch КПД нашего механизма вырос до 60-70%.

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

Целевое КПД достигнуто, внутри корпоративной сети все работает. Но есть нюанс: наши клиенты могут хоститься не только на наших серверах, но и на своих. Значит, механизм должен работать через интернет.

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

 

MULE ESB

 

 

MULE ESB, он же «ослик» – программное обеспечение семейства ESB (сервисная шина предприятия). Основное назначение шин как класса – интегрировать все со всем с минимальными трудозатратами.

Например, в рамках какого-то сервиса на вход принимается информация в JSON, а источник, который отдает эту информацию, отдает ее в формате XML. Шина возьмет на себя преобразование JSON в XML и выполнит конечную отправку данных.

Авторы MULE ESB неслучайно выбрали для своего ПО такое имя, они реально закладывают в это имя значение «осла», так как MULE ESB берет на себя большую разработческую нагрузку, тем самым облегчая разработчику жизнь.

Для MULE ESB существует много коннекторов, с помощью которых можно экономить время разработки. Справа на слайде представлены виды коннекторов, которые я взял из публичного Anypoint Exchange.

 

 

Разработка для MULE ESB ведется в специальной IDE Anypoint Studio: по сути, это как конфигуратор в 1С.

Исходный код MULE ESB – это xml-файлы, в которых прописаны алгоритмы обработки, называемые Flow (потоки).

Anypoint Studio позволяет:

  • вести разработку через графический интерфейс;

  • работать с системами контроля версий;

  • отлаживать проекты с точками останова, с просмотром полученным данных и так далее.

 

 

У нас в компании существует корпоративный GitLab. На слайде показано, как выглядит процесс деплоя готового проекта для MULE ESB.

  • разработчик делает проект на локальном компе в локальном репозитории;

  • готовый проект помещается из контура разработчика в тестовый репозиторий;

  • тестовый MULE ESB обновляет свою конфигурацию из тестового репозитория;

  • и если тестовый MULE ESB успешно запустился, и не произошло критических ошибок деплоя, то конфигурация из тестового репозитория переезжает в продакшн-репозиторий (по сути, это две отдельные ветки одного и того же репозитория);

  • а рабочий экземпляр забирает уже конфигурацию из продакшен-репозитория

 

 

Вернемся к целевой задаче. Нам нужно реализовать механизм автоматической разноски банковских выписок через интернет. Публикуем сервис Elasticsearch на MULE ESB, и наш сервис становится доступным через интернет.

Так как целевое КПД по работе с Elasticsearch было достигнуто ранее, задачу считаем выполненной.

Справа на слайде видно, как эта публикация выглядит в Anypoint Studio – всего лишь три кружочка.

 

 

Но проходит время, и чем больше клиентов подключают наш сервис авторазноски документов, тем больше растет нагрузка на Elasticsearch. В один момент сервер Elasticsearch перестал справляться с потоком запросов и завис.

Справиться с этой проблемой можно двумя способами – либо увеличить железо для Elasticsearch, либо реализовать балансировщик нагрузки.

Мы пошли по второму пути и реализовали балансировщик нагрузки – разработали его на базе менеджера очередей RabbitMQ и Redis, который, по сути, является кэшем.

 

RabbitMQ и Redis

 

 

RabbitMQ, он же «кролик» – это программный брокер сообщений на основе стандарта AMQP.

В рамках «кролика» существует три основных объекта::

  • очередь – Queue

  • точка обмена – Exchange

  • и получатель – Consumer.

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

Получатель сообщения или подписчик (Consumer) вычитывает сообщения из очереди и выполняет его обработку.

Давайте попробуем посмотреть на RabbitMQ глазами простого одинэсника. Если прийти к разработчику и сказать, что нужно поэтапно обрабатывать какие-то сообщения в 1С, то получим регистр сведений «ОчередьСообщений». У меня на одном из предыдущих мест работы в рамках одной информационной базы было 4 или 5 разных регистров очередей, которые возникли из-за того, что задачи делали разные разработчики. Я не говорю, что это плохой подход: он работает, я сам когда-то такие регистры делал.

 

 

Перейдем к Redis, он же «редиска». Если Redis описать одним словом – это кэш. Если рассматривать подробнее, то это – NoSQL-ная база данных, которая работает со структурами типа «ключ-значение». Если говорить в терминологии 1С, то это – Новый Структура() или Новый Соответствие().

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

 

 

Снова вернемся к целевой задаче – нам нужно реализовать балансировщик, чтобы наш сервис работал стабильно.

Сначала замечу, что раньше запрос от клиента отправлялся синхронно:

  • в 1С формировался запрос;

  • запрос отправлялся в MULE ESB;

  • MULE ESB отправлял запрос сразу в Elasticsearch;

  • а 1С все еще ждала результата.

Если Elasticsearch по той или иной причине не возвращал результат – механизм автоматической разноски падал. Поэтому мы решили переделать синхронный механизм работы на асинхронный.

 

Итоговая схема работы

 

 

Итоговая схема работы механизма по автоматической разноске банковских выписок стала следующей:

  • в 1С формируется запрос;

  • он отправляется в MULE ESB;

  • MULE ESB кладет запрос в RabbitMQ, а в 1С возвращает идентификатор запроса, который был присвоен в рамках MULE;

  • в MULE ESB реализован отдельный подписчик RabbitMQ, который берет сообщения из очереди и отправляет в Elasticsearch на обработку, дожидаясь результата;

  • результат обработки помещается в Redis с ключом, равным идентификатору, который был присвоен запросу;

  • клиентская база 1С периодически опрашивает MULE ESB по идентификатору запроса;

  • как только в Redis появляется значение для данного идентификатора, значение возвращается в клиентскую базу 1С, и алгоритм автоматической разноски продолжает свою работу.

По сути, мы просто переделали механизм обработки данных с синхрона на асинхрон. Но наш сервис перестал падать, так как обрабатывает запросы в несколько потоков.

Подведем итоги. Механизм работает штатно, дорабатывать ни на одной стороне почти ничего не пришлось.

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

 

Валидация запросов

 

 

В один из моментов к нам пришло понимание: сервис реализован, доступен через интернет, а авторизации на сервисе мы не сделали.

По сути, бухгалтеров это уже не касается, они спокойно могут переключить свое внимание на другие задачи, но тут на сцене появляются аккаунт-менеджеры. Наша CRM-система тоже построена на 1С, и аккаунты хотели из CRM управлять доступностью сервиса по автоматической разноске.

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

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

На слайде представлена схема первой итерации этого механизма, которая была нарисована на бумажке.

 

 

Сама валидация запросов состоит из двух частей: получения токена доступа и проверка токена доступа при выполнении запроса.

Рассмотрим механизм получения токена – как он реализован.

  • Сначала в нашей внутренней CRM аккаунт-менеджерами для определенных клиентов открывается так называемый «канал на получение клиентом токена».

  • Клиент обращается в MULE ESB за получением токена, передавая информацию о себе как о клиенте (как минимум, ИНН и КПП) и информацию о своей базе.

  • А шина в синхронном вызове запрашивает токен у CRM, передавая туда эту информацию.

  • Если в CRM «канал на получение токена» открыт, токен генерируется и возвращается в MULE. Если канал не открыт – токен не генерируется.

  • Если токен возвращается – шина возвращает информацию клиенту и клиент у себя в базе сохраняет выданный токен.

 

 

Сама валидация запросов происходит по другому алгоритму.

  • Приходит абсолютно любой запрос в шину, если он подключен к системе валидации. Из запроса получается токен.

  • Потом идем в Redis и проверяем, есть ли такой токен на доступ к нашему сервису.

  • Если в Redis такого токена нет – проверяем в CRM.

  • Если в CRM мы получили разрешение на доступ к сервису – сохраняем его в Redis для кеширования дальнейших обращений и маршрутизируем запрос на целевой сервис, к которому реально обратился клиент.

Токены живут порядка 20-30 минут, поэтому самым длительным выполняется первый запрос, который касается нашей CRM, так как она реализована на базе 1С, а потом затраты на валидацию запроса – 0,010-0,015 секунд.

 

Итоговая схема

 

 

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

  • Сначала выполняется валидация запроса, при успехе данные помещаются в RabbitMQ,

  • MULE в асинхронном режиме обращается к Elastic, получает результат работы,

  • одинэсный клиент обращается в MULE для получения результата обработки с интервалом в 5 секунд.

На схеме выглядит сложно: куча точек и разных систем, но работает быстро. С точки зрения 1С – это пара строчек кода: выполнить запрос, реализовать цикл с ожиданием и опросить.

Я преднамеренно не выносил в доклад данные о логировании, чтобы не нагромождать картинки. Но скажу, что абсолютно все ошибки на любом этапе работы механизма отправляются в специальные индексы Elastic, а в асинхронном режиме – через RabbitMQ. Если появится такая возможность, я расскажу об этом в другой раз.

 

Особенности «зоопарка» разных систем (почему не свой «велосипед» на 1С)

 

Система получилась обширной, использует разное программное обеспечение. Но основа – MULE ESB. С помощью MULE ESB получается в короткие сроки реализовывать сервисы, которые покрывают потребности нашего бизнеса, особенно в интеграционных вопросах и в период, когда требования меняются 5 раз на день.

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

Вы спросите, разве нельзя было реализовать этот «зоопарк» через 1С? Пять лет назад, когда я делал первую интеграцию с мобильным приложением, я так и сделал. Но это было менее эффективно, особенно, если говорить про интеграционные моменты.

У многокомпонентного подхода тоже есть недостатки: этот «зоопарк» нужно поддерживать, нужны специалисты, мониторинг, администраторы, которые понимают хотя бы 50% из этого зоопарка. Все эти сервисы мониторит Zabbix в том числе RabbitMQ, который информирует в Telegram при возникновении проблем.

«Зоопарк» или одна система – это такой же холивар, как монолит vs микросервисы. Идеальное решение где-то посередине.

 

Вопросы

 

Что значит «ослик обновляет конфигурацию в продакшен»? Имеется в виду конфигурация в 1С или что-то в гитлабе?

Имеется в виду конфигурация MULE ESB – она у нее, по сути, такая же, как у 1С. Выглядит как xml-файлики. И как раз эта конфигурация и обновляется в продакшен MULE ESB посредством GitLab, которая используется как система контроля версий. Когда появляется новая версия, MULE ESB забирает себе новую версию конфигурации и обновляет у себя конфигурацию. Это не касается 1С.

Сколько было RPS до балансировки и сколько стало держать RPS после оптимизации?

Я могу сказать только в клиентах. У нас проблемы начали возникать на обработке ежедневных документов для 40 клиентов. После балансировки мы смогли количество клиентов увеличить в два раза. И пока проблем с этим больше нет – они возникают, но больше из-за инфраструктурных внутренних проблем, а не из-за проблем самого Elasticsearch.

Нельзя ли применить машинное обучение для решения определенной части данной задачи?

Можно. И это наша следующая итерация, которая сейчас уже в работе. На текущий момент у нас действительно уже в работе машинное обучение, с его помощью мы сможем поднять процент автоматической разноски с 70% хотя бы до 95. Мы стремимся именно к этому.

За счет того, что посередине применяется RabbitMQ и MULE ESB, эти компоненты в принципе можно заменять один на другой. Можно вытащить из розетки этот компонент поиска по Elasticsearch по скорингу в Elasticsearch и воткнуть туда какой-нибудь веб-сервис с искусственным интеллектом. А все остальное переписывать не придется – оно сохранит свои интерфейсы и будет точно так же работать. В этом тоже своя прелесть есть. Поэтому адаптировать это к машинному обучению может быть очень просто – вытащить один «умный компонент» и вставить вместо него другой, а все остальные оставить как есть. Это одно из преимуществ MULE ESB как «шины предприятия».

Почему RabbitMQ, а не Kafka?

MULE ESB все равно, с кем коннектиться – AMQP-коннектор там без привязки к программному обеспечению. Выбрали RabbitMQ, потому что было больше информации о том, как его применить в сфере 1С.

Почему Redis, а не Memcached?

Потому что у MULE ESB свой собственный встроенный Memcached, но он не подпадает под OpenSource, он за деньги. Купить MULE ESB в рамках России невозможно, он стоит каких-то космических денег. А Redis – это Open Source-решение и там есть коннектор, который можно поставить. Это вопрос экономической целесообразности.

Сколько стоит MULE ESB?

Два года назад мы оценивали, сколько стоит приобрести платформу Anypoint Studio с публикацией онлайн – это все работает только через подписку, купить целиком экземпляр нельзя, а подписка стоит порядка 40 тысяч долларов в год. Сам по себе MULE ESB – бесплатен. Нам достаточно бесплатной части MULE ESB, он работает стабильно, падений нет. Поэтому по деньгам MULE ESB нам обошелся бесплатно. Мы за него никаких денег не платили. Если смотреть в рамках каких-то других шин, то я в своей жизни работал с еще двумя шинами – это WSO2 и Zato. WSO2 – это шина чисто на Java, без какого-то юзерфрендли-интерфейса, разработчику только кодом писать, у Zato почти то же самое. А у MULE ESB все те же самые возможности, только графический интерфейс позволяет буквально в пару кликов разворачивать новые сервисы, маршрутизировать их и спокойно использовать. По крайней мере, порог входа для 1С-ников намного ниже, чем во все остальные.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Интеграционные решения в 1С".

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс 24. Разработка имеет двухстороннюю синхронизацию 1С и Bitrix24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (платформа начиная с 8.3.23). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    19037    10    16    

16

Управление взаимоотношениями с клиентами (CRM) WEB-интеграция Анализ продаж Системный администратор Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Подсистема интеграции Amo CRM с 1С: технические требования, порядок работы, возможности, доработки и обновления. Бесплатный период техподдержки - 1 месяц.

60000 руб.

07.05.2019    31889    62    40    

23

Сайты и интернет-магазины WEB-интеграция Системный администратор Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020    16780    15    19    

15

WEB-интеграция Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    17018    45    49    

26

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    13387    36    8    

15

Прайсы WEB-интеграция Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Автомобили, автосервисы Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Программа с заданным интервалом времени (или по ручной команде) скачивает файлы (например, прайс-листы поставщиков) из различных источников: письма электронной почты, FTP или HTTP-адреса, и сохраняет их в каталог упорядоченной структуры. При этом извлекает файлы из архивов, может переименовывать файлы и менять их формат (csv, xls, txt). Можно настроить выгрузку обработанных файлов на сайт (через FTP-подключение). Программа будет полезна компаниям, у которых есть большое количество поставщиков и/или прайс-листы поставщиков обновляются часто (необязательно прайс-листы, файлы могут быть любого назначения). Собранные таким образом актуальные версии прайс-листов можно выгрузить с помощью программы себе на сайт (или на любой FTP-сервер) или выполнить другие необходимые задачи.

25200 руб.

28.05.2015    87310    26    51    

50
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. insurgut 207 29.07.21 13:52 Сейчас в теме
Правильно ли я понял, что в результате удалось добиться точности разнесения до 70%? Не нашел просто раздела с итоговыми результатами, только итоговая схема.
2. hamsar 16 30.07.21 06:57 Сейчас в теме
я бы, для самостоятельно хостящихся клиентов, поднимал бы эластик на их серверах. по сути, нужно хранить в эластике пару "номер документа, назначение платежа" => очередь бы вынес, в регистр для этих клиентов. Так получилось бы

1) Обособленное решение. для установки на любой сервер клиента.
2) Очередь обрабатывалась бы в 1с. регламентным заданием.

Редис мул, лишние в этой задаче.(только для клиентов, которые хостяться у себя на серверах)

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

Пытался понять, что мне не нравится. Осознал, что ради эластика вы построили инфраструктуру, которая по сути не нужна. Или я чего, то не понимаю. В чем проблема, обычный insert, select делать напрямую из 1с в эластик для платежных поручений? по кнопке, а потом и по заданию.

Да и и тот же питоновский скрипт через орм в sql, можно было запускать в рамках sql базы(отдельной с таблицей назначений платежей по клиентам), это позволило бы вообще отказаться от elastic

Нельзя ли применить машинное обучение для решения определенной части данной задачи?

facepalm
3. user1454516 02.08.21 12:04 Сейчас в теме
(2) "Осознал, что ради эластика вы построили инфраструктуру" - там смысл именно в полнотекстовом поиске Эластика. Но возможно решение на просто MS SQL полнотекстового запроса будет дешевле/быстрее. Тут же ограниченная задача.
4. hamsar 16 02.08.21 15:58 Сейчас в теме
(3) да можно напрямую эластик из 1с вызывать, из локально установленной копии, без редиса осла и кролика
5. NikeeNik 78 02.03.22 09:35 Сейчас в теме
С лицензированием Mule ESB все не очень просто - есть Mule ESB Community edition (который теперь Mule Kernel) и есть Mule ESB Enterprise Edition, первый бесплатный, второй весьма (даже ВЕСЬМА) дорогой. Так вот в лицензии к замечательному Anypoint studio написано следующее: "MuleSoft grants to Customer bla-bla license to use bla-bla but solely in connection with and to facilitate Customer’s permitted use of (i) the Enterprise Edition of MuleSoft’s runtime enterprise service". Что по русски означает, что Anypoint studio бесплатный конечно, но использовать его можно только с купленным Mule ESB EE (окромя двух недель триала).
И остается только два выхода: не использовать студию, типа все можно ручками (или с костылями) написать в xml-ках и как-то прикрутить это к мулу, используя тайные знания, ну и второй наш стандартный - забить, потому что без студии может и можно наверное, но только если уже долго там крутился и знаешь что там делать.
Оставьте свое сообщение