1C + Python + Django Rest Framework + Vue.js. Опыт несложной full-stack разработки

21.04.2019 62 Comments

Практика программирования, Разработка

, , , ,



    scheme.png
    1c-profile.png
    price-vue.png
В этой статье мы рассмотрим путь и основные моменты создания небольшого вэб-сервиса, который мы называем «Онлайн Прайс-лист». Выгрузка из 1С, бэкенд, фронтенд, получение заказов в 1С.

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

 

 Лирика

И прежде, чем начать этот долгий рассказ, сразу хочу акцентировать ваше внимание на следующем:

  • Статья не претендует на best-practice. Описано все на примере одного проекта со своими нюансами и допущениями.
  • Да, можно сделать более технологично, улучшить часть моментов, что-то доавтоматизировать и т.д. 
  • Я пытаюсь показать, что иногда простую вещь не нужно делать сложно, как это часто нам пытаются навязать "конторы с мировым именем", томными вечерами изобретая дизайн и адаптируя верстку сайта-одностранички. 

Схема

Если вы задавались целью найти себе разработчика на какой-то сайт — вы писали ТЗ (Техническое задание). Если у вас есть ТЗ, значит вы уже представляете себе, как это должно выглядеть, каким функционалом обладать, как оно должно вести себя в той или иной ситуации. И, в принципе, этого достаточно, осталось лишь определиться с инструментами.

Дано:

  • Сервер 1С, расположенный в офисе компании.
  • VPS, арендованный у хостинг-провайдера. На нем будет размещен итоговый сайт, БД сайта и бэкенд на DRF.

Если вы поднимаете VPS с нуля и он у вас тоже будет на debian 9, рекомендую мой мануал по развертыванию LEMP + DRF.

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

  1. Раз в день, в определенное время, из 1С выгружается информация о товарах, ценах и остатках + сервисные справочники. Она сохраняется локально на сервере в формате XML, рядом кладутся изображения номенклатуры.
  2. Получившиеся файлы загружаются на VPS по протоколу FTP, тем же регламентным заданием в 1С.
  3. Раз в день, в определенное время, на VPS происходит обработка новых XML файлов и загрузка информации из них в СУБД. Загрузка производится средствами python. СУБД — MariaDB 10.1
  4. К той же базе подключено приложение на Django + Django REST Framework. Задача DRF — по запросу отдавать на фронтенд нужную информацию из базы.
  5. Фронтенд на Vue.js. Его задачи — отрисовать сайт, общаться с бэкэндом на предмет: авторизации, получения информации о товарах и добавления новых заказов.
  6. DRF, получив новый заказ, отправляет ответственному за клиента менеджеру письмо с уникальным ID заказа.
  7. Менеджер открывает в 1С обработку, вставляет в нужное поле полученный ID и заказ загружается, создается документ в 1С.
  8. Менеджер управляет пользователями на сайте из 1С. Создает новых пользователей, назначает им тип цены и т.д. Общение 1С и DRF по части пользователей происходит через HTTP POST и GET запросы. Управление пользователями на самом сайте становится ненужно, а значит и админку для этого писать не придется.

Как видите, ни разу не прозвучало слово "дизайн". Это потому, что сайт у нас в первую очередь функциональный, и только потом — презентативный. Его красивость мы обеспечим бутстрапом, спецификой фреймворка и популярной оболочки для него — vuetify. Забавный факт вам скажу — попробовав эту связку один раз, вы будете видеть аналогичный дизайн везде. 

Нарисуем нашу схему и приступим уже к реализации.

 

Часть 1. Выгрузка из 1С и загрузка на FTP

 

Основная задача, которая стоит перед этим этапом — выгрузить так, чтобы в дальнейшем не заниматься каким-либо изменением этих данных. Каждая дополнительная операция на других слоях разработки — увеличение времени обработки, увеличение нагрузки и размазывание области траблшутинга. Поэтому мы должны сформировать такие XML, чтобы потом их можно было просто взять и "вставить" в нашу БД на VPS.

На том, как формировать XML в файлы, останавливаться не буду. На эту тему есть достаточно материалов. Остановлюсь лишь на паре моментов.

Выгрузка изображений

Наверняка, картинок у вас много. У нас порядка 30 тысяч. Если положить их все в один каталог, вы его потом с трудом откроете. Возможно, вы уже замечали, как некоторые сервисы или CMS хранят картинки в подпапках из одной двух букв, по 100-1000 штук в каждой. Сделать такую структуру средствами 1С не сложно.

 

 Код 1С

Получается, что для номенклатуры с GUID bf0d2eb7-5caa-11e3-a144-001e6711eb85 картинка будет лежать сначала в папке b/, потом в папке f/ и только потом будет сама картинка bf0d2eb7-5caa-11e3-a144-001e6711eb85.jpg. С увеличением числа изображений мы просто увеличиваем в этом коде наш уровень вложенности до 3-4-5 каталогов. В XML же мы сразу пишем путь, по которому эта картинка будет доступна на сайте.

<ImagePath>/static/images/b/f/bf0d2eb7-5caa-11e3-a144-001e6711eb85.jpg</ImagePath>

Числа с плавающей точкой

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

 

 Код 1С

Иерархические справочники

С одной стороны, структура справочника номенклатуры в самой СУБД в любом случае будет храниться двумерно, с другой — распарсить питоном иерархический XML в список, а потом этот список обратно преобразовать в иерархический объект — не сложно. Поэтому выгружаем иерархически. Получаем запросом список каталогов, формируем древо значений через Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкамСИерархией) и обходим

 

 Код 1С

Блок Info в каждом XML

Представим, что выгрузкой будет заниматься один программист, а загрузкой данных — другой. С одной стороны, они могут договориться, что будут сформированы вот такие файлы и с вот такими именами, с другой — такая договоренность может через года забыться, имена файлов вдруг изменятся и вообще. Поэтому, в каждый файл в самом начале будет неплохо добавить какие-то флаги, маркеры, объясняющие — что это и как с этим работать.

<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Info>
<Key>PriceValues</Key>
<Description>Значения для типа цены - 1234</Description>
<Argument>000001234</Argument>
</Info>
<Items>
<Item>
<ID>bb5b71eb-3915-11e7-80b7-001e6711eb85</ID>
<Value>899.99</Value>
</Item>
...
</Items>
</Root>

И на той стороне уже увидят, что в каждом файле есть некий ключ Key, который можно использовать как идентификатор — что это за файл и как его обработать. А если появится программист, который будет что-то менять в выгрузке, он увидит этот блок и (будем надеяться) поймет, что это важно.

Выгрузка на FTP

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

Все это находится в двух корневых каталогах: IMAGES для картинок и XML для всех получившихся XML-файлов.

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

Сразу предостерегу вас — не используйте для этих задач встроенные механизмы FTP-клиента 1С. Он ужасен, он неэффективен, он ненадежен. Проверено. Вместо него в windows лучше воспользоваться сторонним приложением, вызывая его через COM-объект. Например, WinSCP.
Просто посмотрите, насколько лаконичнее и, поверьте, эффективнее, становится код в 1С. Приведу его полностью.

 

 Выгрузка на FTP средствами WinSCP

 

Итог

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

Часть 2. Загрузка в СУБД

В принципе, вовсе не обязательно, чтобы данные из XML были загружены в СУБД именно с помощью pyhton. Этот этап полностью изолирован от всех остальных, он чисто сервисный. Я выбрал python потому, что понимал, как это нужно сделать. Основу скрипта составит библиотека SQLAlchemy. Для ее работы сначала мы создадим модели наших таблиц. Делать это мы будем декларативно, потому что мы не хотим заниматься ручным созданием таблиц в нашей базе, SQLAlchemy сделает это для нас. От нас на подготовительном этапе потребуется только создать саму базу и пользователя для работы с ней.

 

 Пример модели Goods (Товары) 

 

 Пример модели Prices (Цены)

Обратите внимание на блоки init в каждой модели. Дело в том, что при чтении наших XML, False, True, Null будут представлены для python в виде текста и для дальнейшей работы с этими полями уже из самой БД нам нужно преобразовать их в типы, понятные python. Поэтому мы и проверяем, что если поле == ‘null’, то эквивалентом для python будет тип None и т.д. Если этого не сделать, мы столкнемся с проблемой при загрузке, когда попытаемся в поле БД с типом TINY_INT засунуть строку с текстом ‘False’.

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

Чтобы не заниматься прописыванием методов и полей в коде загрузки, сделаем некий словарь, где по ключу в XML будем определять, какие там поля и как они должны быть загружены в БД.

 

 Описание Dict

Для того, чтобы получить данные из наших XML не сплошным текстом, а неким объектом, воспользуемся библиотекой lxml.

 

 Чтение XML 

Когда механизм чтения готов, можно приступать к самой загрузке.

 

 Главный метод, которым все и загружается

 

 Код _sql.py

Вы могли заметить, что вызов загрузки также вызывает очистку всех таблиц в базе данных. Да, это так. Специфика нашего проекта позволяет нам просто взять и удалить данные из всех таблиц, в которые мы собираемся что-то загружать. Поэтому мы не тратим время и ресурсы на какую-то сложную логику по определению уже существующих данных, их соответствие загружаемым и т.д. (ON DUPLICATE UPDATE создаст дополнительный слой операций) Мы точно знаем, что перед загрузкой таблица будет пуста и точно знаем, что нужно загрузить абсолютно все. А это, в свою очередь, позволяет нам формировать INSERT-команды пачками по 100-1000 штук и засылать в commit. Таким образом, загрузка данных общей протяженностью около 400.000 строк занимает секунд 15. Если в других таблицах нашей БД (например, в заказах) будут использоваться ключи от очищенных таблиц — они будут оставлены как есть (потому что перед загрузкой мы отключаем для БД ForeignKeyChecks) и после загрузки снова станут актуальны.

Итог

Данные загружены в СУБД, теперь с ними можно работать.

Часть 3. Django, REST Framework

Прежде чем начать, рекомендую обзавестись удобным инструментом для отладки HTTP-запросов — Postman

С помощью него вам будет гораздо удобнее отлаживать свои запросы к API.

Models

Django (Джанго), как и SQLAlchemy, в своей работе тоже использует ORM-принципы, поэтому для того, чтобы научить наш бэкенд понимать таблицы в нашей БД, нам снова придется описать все модели. По одной на каждую таблицу. Но, в отличие от загрузки из XML, тут мы также будем описывать такие модели как "Profile, Order, OrderItems". Опять таки, мы ничего не будем создавать непосредственно в СУБД, механизмы Django сделают это для нас (python manage.py makemigrations и pyhton manage.py migrate).

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

 

 И снова пример для Goods и Prices

 

 А это уже новая таблица — Profiles

 

 Ну и последние две таблицы — Orders и OrderItems

 

Serializers и Views

Когда с описанием моделей закончено, мы приступаем к написанию необходимых нам сериализаторов (Serializers) и представлений (Views).

В этих двух местах будет заключена вся логика нашего бэкенда. Именно тут мы будем определять, как выводить данные, кому их показывать, в каком виде, как фильтровать и т.д. И не только показывать, но и модифицировать HTTP-запросами.

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

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

 

 Класс для отображения товаров в прайсе

Тем, кто плотно занимается 1С, эта логика будет вполне понятна. Есть некий отчет view, написанный программно на построителе. Есть запрос — queryset, есть фильтры и отборы построителя, которые могут применяться, а могут и не применяться — search_fields, filterset, есть поля сортировки — ordering_fields. Ну и, конечно, наш построитель — serializer_class. Все это, естественно, несколько сложнее, но любое понимание сложного начинается с раскладывания его на простые части.

Выбор полей для нашего отчета — это как раз к сериализации.

 

 Вот так выглядит наш класс MainGoodsSerializer

И, естественно, мы можем эти поля модифицировать еще на этапе получения.

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

id_brand = SvcBrandsSerializer(required = False)

Который очень прост 

class SvcBrandsSerializer(serializers.ModelSerializer):
class Meta:
model = SvcBrands
fields = ('id', 'name')

Если мы еще раз взглянем на нашу модель товаров, то увидим

class MainGoods(models.Model):
    ...
id_brand = models.ForeignKey('SvcBrands',
models.SET_NULL,
related_name = 'goods',
db_column = 'id_brand', blank = True, null = True)

Т.е. поле id_brand — это ссылка, ForeignKey на соотв. запись в таблице SvcBrands, one-to-many relational field. Поэтому на этапе сериализации мы можем при получении объекта автоматически получить не только ID нашего брэнда, но и все остальные сериализуемые поля из связанной таблицы. И view отдаст нам данные не в виде представления поля:

id_brand: '123123'

А уже как объект:

id_brand: {
id: '123123',
name: 'SAKURA'
}

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

 

 ViewSet профиля

И запросмодификация к нашим моделям Order и OrderItems:

 

 ViewSet заказов и товаров заказа

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

Авторизация пользователей

Авторизацию мы полностью отдаем на расширение для Django — Djoser. Как только мы зарегистрировали его в своем конфиге, добавили его url в urls.py — нам уже доступны методы управления пользователем через HTTP-запросы. Мы можем получить authorization_token, отправив правильный POST-запрос с логиномпаролем на нужный url, а потом добавлять этот токен в наш ajax.headers, и наш бэкенд будет видеть нас как авторизованного пользователя. У Djoser нет механизмов token_expiration, однажды выданный пользователю токен будет валиден, пока его не уничтожат или пока пользователь не запросит для себя новый токен. Token_expiration можно реализовать самостоятельно, но для нашего проекта в этом не было необходимости.

Отправка почты

То, что мы используем DRF, никак не ограничивает нас в использовании всех остальных возможностей python. Наши "представления" (Views) вовсе не обязаны ссылаться на какие-то модели и сериализации. Мы можем объявить любой удобный для нас url и привязать к нему свою процедуру обработки. Так и происходит в нашем случае с отправкой почты.

 

 urls.py нашего API

 

 Соотв. view из views.py

 

 Код отправки email

 

Итог

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

Для входа в Django и DRF я рекомендую пройти начальный курс на youtube. Например, вот этот русскоязычный канал. Потратьте на него недельку и вы уже будете понимать, что вы делаете и что вам нужно сделать. Там же вы найдете и практические применение написанного бэкенда при разработке фронта на том же Vue.js 

Часть 4. Фронтенд и Vue.js

До этого я не сталкивался с фронтенд фреймворками на javascript. Только всякие CMS типа джумлы, ворпресса или битрикса. Я не стал останавливаться на REACT.js или Angular.js в виду того, что Vue позиционирует себя как очень простой, легкий как в работе, так и в освоении инструмент. Достаточно понять его логику, пройти пару туториалов и вы готовы начинать. Все ваши дальнейшие вопросы будут скорее касаться непосредственно JS, а не самого Vue. И в некоторых случаях ваша идея уже будет иметь практически готовое решение в виде компоненты для Vue. 

При выборе инструментов помимо Vue, я остановился на популярном Material Design компонентном фреймворке Vuetify. Здесь вы найдете практически все необходимые компоненты, чтобы нарисовать ваш сайт.

Для хранения и модификации глобальных переменных, я использовал Vuex. Тоже общепринятая практика, рекомендуется один раз понять, как им пользоваться и больше не искать ответ на вопрос "а как взять переменную А и чтобы она была единой для компонента Б1 и Д2? И чтобы оба компонента реактивно реагировали на ее изменение?"

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

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

  • template
  • script
  • style *scoped

В template вы расписываете визуализацию вашей страницы. С использованием тэгов html или тэгов компонент.

 

 App.vue #template

В script — код вашего компонента, переменные, методы и т.д.

 

 App.vue #script

В style — css для каких-то элементов, если это необходимо. Если добавить scoped — эти css будут применяться только для элементов, описанных в данном компоненте.

 

 App.vue #style

Как вы уже, наверное, поняли, style — необязательный.

Как именно и с какой логикой вы будете строить свой сайт — это уже ваша фантазия.

Ниже будет ссылка на итоговый проект. Могу показать, как выглядит структура фронтенда.

И больше всего кода тут всегда сконцентрировано в .vue-файлах. И то только из-за толстых template секций.

Если вас интересует, как же происходит общение с бэк-эндом. Очень просто — через ajax и jquery

 

 Выжимки из script компоненты PriceTable

 

 Простой пример POST запроса из секции script в компоненте NewAccount.vue

Да, оно все настолько просто. Главное, это заслать на бэкенд информацию в нужном виде, как и получить от DRF информацию в нужном виде, а значит и хранить эту информацию в БД в нужном виде, а значит и выгрузить ее из 1С в нужно виде.

Тем не менее, создание фронтенда заняло у меня больше всего времени. Для меня эта была самая интересная часть и если на все, что было до этого я потратил две недели, то vue я занимался месяц и даже брал две недели отпуска, чтобы плотно за ним посидеть (читай "сутками").

Как и в Django, development-mode Vue (npm run serve) позволяет реагировать на изменения в коде и автоматически обновляться отображение страницы в браузере. Т.е., вы сидите за двумя мониторами, в одном открыт ваш сайт на localhost, в другом IDE (pycharm, в моем случае). Вы что-то меняете в компоненте vue и это сразу визуализируется в окне браузера. Вы сразу видите результат. А еще для chrome и firefox есть расширение, которое в dev-mode на вашем сайте может показать прямо в браузере, в page-inspection, все ваши переменные отображаемого компонента. Поищите Vue.js devtools

Я не буду больше расписывать какие-то элементы с этого этапа, в конце концов, там все сводится к стандартной js-акробатике. Преобразование и манипуляция с данными, их обработка по событиям, хранение каких-то значений в local storage браузера и т.д.

Часть 5. Возвращаемся в 1С и заканчиваем

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

Сейчас нам нужно решить две вещи:

  1. Управление пользователями сайта из 1С
  2. Загрузка заказов с сайта в 1С

Управление пользователями

Для этого мы создадим в нашей конфигурации новый справочник — ПользователиОнлайнПрайса. Он у нас будет подчиненным справочнику Контрагенты.

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

Мы больше не будем заниматься формированием каких-то XML, зачем, ведь у нас уже есть API, который готов обрабатывать HTTP-запросы.

 

 Код кнопки "Создать профиль"

 

 Код общего модуля "ОнлайнПрайс", часть процедур

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

Менеджер копирует этот ID и вставляет его в поле обработки в 1С.

 

 Функция получения товаров заказа с сайта

На этом все, если фронтенд готов, можно начинать тестировать, а потом и работать.

Итог

Менеджер управляет аккаунтами своих клиентов прямо из 1С. Ему сайт в принципе не нужен, он на него не заходит и ничего там не делает. Менеджер как работал в 1С, так и продолжает в ней работать, необходимости осваивать какой-то новый инструмент и быть в каких-то местах еще у него нет. Для абсолютного удобства, функционал загрузки заказов был добавлен в ту же обработку, которой раньше менеджер грузил excel-прайсы с количествами заказа от клиента.

Покупатели теперь могут всегда получать актуальную (в разрезе дня) информацию о товарах, остатках и ценах, видеть историю своих заказов, изменение цен на товары из заказов в сравнении с ценами на текущую дату, ну и, конечно, менять свой логинпарольemail. И самое главное — ему не нужно ждать актуальный прайс-лист на свою почту от менеджера, заполнять в нем колонку "Заказ", как и не нужно потом отправлять его менеджеру обратно. 

Заключение

Если кого-то интересует, как оно в итоге выглядит — пожалуйста. Без авторизации сайт работает как публичное предложение.

Просьба не кидаться тухлыми яйцами, у меня тонкая ранимая натура (нет). У меня уже сейчас есть идеи, как сделать лучше там, как оптимизировать тут, улучшить безопасность здесь и т.д. Работа над сайтом будет продолжаться. Суть в том, что, зачастую, не все так сложно, как нам пытается преподнести подрядчик. Когда мы искали разработчика и озвучивали сроки с ценником (месяц за пятизначный), в одной компании мне ответили: "если вам где-то говорят, что оно стоит столько и готовы сделать это в такой срок — задумайтесь, это явно какие-то разводилы." Я более чем уверен, что опытный full-stack программист (без 1С) сделал бы все за этот месяц, сделал бы лучше и явно не за полмиллиона.

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

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

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

Да, Vue и DRF, по сути своей, тоже можно называть "конструктором для программиста" (фреймворки же) и они не идеальны, но на выходе вы получите проект, который будет работать так и только так, как вы его описали кодом. И ничего лишнего.

Ну а тем, кому еще и важен внешний вид и анимации фронтенда — рекомендую посмотреть, какое кунг-фу в нем исполняют на Vue.js некоторые опытные люди. Заметьте, там тоже говорят, что это все "просто".

 

В разделе для скачивания будет архив. В нем вы найдете:

  • Две обработки для 1С: 1. Выгрузка в XML и загрузка на VPS через FTP. 2. Загрузка заказа покупателя. Она еще умеет excel грузить, но это, как я и говорил, мы расширили функционал того, что уже было. Вырезать его мне лень, поэтому отдаю как есть.
  • Тексты общих модулей, которые мы используем для работы с API и для отправки почты.
  • Программа на python для обработки файлов XML и загрузки информации из них в БД. Исполняемый файл — load_xml.py
  • Шаблон-заготовка для Django + DRF. Можно скопировать, заполнить настройки, выполнить миграцию и разрабатывать.
  • Шаблон для Vue + Vuex + Vuetify. Сперва, конечно, нужно будет предварительно все проинсталлить через npm. Это шаблон к только что созданному проекту.

Related Posts

62 Comments

  1. rintik

    (1) Можете пояснить для тех кто плохо понимает англицизмы и суржик, что такое «хероллара»?

    Reply ↓
  2. Robbi

    Все, что в статье касается 1с — прошлый век.

    Xml xls ftp зачем об этом всем писать, это чуть-ли не с начала 2000 в ходу

    Про ftp в 1С — около 5 лет ежедневных выгрузок фото на ftp сайта раз в полчаса средствами 1С, ни одного сбоя, Самая простая и беспроблемная часть обмена всегда была.

    Reply ↓
  3. fr13

    Отлиная работа, автор спасибо!

    Reply ↓
  4. riposte

    (3)

    Основная причина, по которой мне не понравились механизмы FTP-клиента 1С — отсутствие синхронизации каталогов.

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

    Третья — тяжело было соорудить так, чтобы не ломалось. У меня, во всяком случае, не получалось, когда доходило до выгрузки изображений. Нет-нет, а через 1000-другую файлов начинало отваливаться, причем каскадно.

    А с WinSCP все получилось очень просто и без бубна.

    Тем не менее, как и было замечено, процедуры формирования XML и обмены по FTP уже со всех сторон неоднократно рассмотрены.

    Reply ↓
  5. YPermitin

    (0) создан монстр, но читать было интересно!

    Reply ↓
  6. riposte

    (6)

    Можно приоткрыть тему монстра? Ну… для саморазвития. Хотя бы тезисно.

    Reply ↓
  7. smile2009

    Соглашусь, что FTP — прошлый век. Но автор показал нам возможность использования стека современных технологий. Однозначно плюс. Спасибо автору. Ждем новых статей!

    Reply ↓
  8. for_sale

    (2)

    Я тоже долго размышлял над данным суржиковым словом данного суржиконенависника. Даже подумал, было, что это такое имя. Ну типа, «ХероЛара Крофт, расхитительница гробниц». Может, человек не согласен таким отношением к гробницам? Или качество фильмов не нравится (тут я тоже согласен, что ХероЛара Крофт подошло бы лучше). Но потом я поиграл с ударением и решил, что, возможно, это такая рифма на «доллар», картинка с которым и правда нашлась в шапке сайта. Кейс клоузд.

    Reply ↓
  9. YPermitin

    (7) это была не критика, читать правда было интересно.

    Просто когда читаешь статьи про фронтенд, то там столько технологий и фреймворков всегда понапехано, что для этой сферы норма. А для 1С это немного непривычно 🙂

    Еще раз спасибо, пишите еще!

    Reply ↓
  10. SShipilov

    (5)

    ья — тяжело было соорудить так, чтобы не ломалось. У меня, во всяком случае, не получалось, когда доходило до выгрузки изображений. Нет-нет, а через 1000-другую файлов начинало отваливаться, причем каскадно.

    (8)

    Господа, зачем прицепились к FTP. Может в текущей реализации это было удобнее всего. Зато какая клевая остальная архитектура. Статья очень познавательная.

    Некоторые блоки правда напрашиваются на замену, но это придирки))

    Автор, спасибо за хороший пример.

    Reply ↓
  11. zqzq

    Дизайн сайта конечно жесть 🙂 В стиле WEB-2000. И конечно обязательно нужны мельтешащие видео и слайды в шапке. Лучше уж wordpress как по мне.

    Но сама работа добротная проделана, раз всё работает.

    В общем, я предложил — мне дали добро. Срок поставили — месяц. Справился за полтора, ибо замену картриджей никто не отменял.

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

    Reply ↓
  12. riposte

    (12)

    В первоначально версии не было блока commercials (той самой полоски с рекламой вверху).

    Я пытался объяснить, что добавление всех этих вещей — это уменьшение эффективного пространства самого приложения — таблицы с товарами, да и в принципе лишнее, учитывая предназначение сервиса. Но заказчик был неумолим.

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

    Reply ↓
  13. shard

    Предложенный алгоритм выгрузки данных на сайт (получение данных в 1с -> формирование xml и отправка на сайт -> разбор xml на стороне сайта и запись в бд) можно упростить, формируя текст запроса к субд непосредственно в 1с. Т.е. на выходе из 1с не xml, а текст с уже сформированными командами insert, который достаточно сразу отдать на выполнение субд (можно даже планировщиком).

    Reply ↓
  14. bonv

    (0)

    Если вас интересует, как же происходит общение с бэк-эндом. Очень просто — через ajax и jquery

    А почему jquery, а не Axios?

    Reply ↓
  15. riposte

    (14)

    Можно и прямыми запросами к API вносить изменения прямо из 1С. Сформировав нужный блок процедур на самом бэкэнде.

    Но от выгрузки xml уже не избавиться.

    Эти файлики еще один из клиентов забирает себе на сайт.

    (15)

    Не знал про него и даже как-то не натыкался. Спасибо, посмотрю.

    Reply ↓
  16. s_vidyakin

    (15) точнее — почему не cheerio+axios

    Вообще можно было без питона обойтись, все на node.js сделать, но раз человек знает питон…

    + Можно из 1С сразу через веб-сервис отдавать zip-архив с таблицами в JSON и картинками, на сервере распаковать и раскидать в базу

    Reply ↓
  17. smirnovserg.s@gmail.com

    Автор, молодец!

    Тоже ковыряю тему подобных интеграций Python + 1C и как раз публикация в тему.

    Кстати, твой проект можно и на гитхаб залить 😉

    Reply ↓
  18. nvv1970

    (17) объясните «танкистам»: python — это ацтой? или просто node.js — это топчик? и ни на чем другом писать не стоит…

    Пытаюсь сам развиться и подучиваю питон… Может не стоит?

    Reply ↓
  19. user1209201

    Я вообще рад за автора, если внедрение прошло и клиент получил инструмент. Даже полмиллиона можно ставить в ценник, так как гарантия стоит тоже денег, и не только во времени плотного сидения в отпуске дело, а в том, что менеджеры смогут удобнее барыжить ещё три-четыре квартала, пока можно плотно сидеть над решением без 1с, если на него будет заказ, а если не будет, то эти четыре квартала превратятся в, страшно сказать, …? Четырнадцать?

    Reply ↓
  20. s_vidyakin

    (19) Да нет, питон тоже топ) но он больше применяется в BigData, ИИ, обработке данных, научных исследованиях.

    Веб тоже можно, но это не мейнстрим, скорее исключение. Вот pinterest, dropbox и инстаграм до сих пор на джанго крутятся.

    Можно и наоборот, написать все на питоне, кроме Vue на клиенте, в питоне есть библиотека beautifulSoup4 типа cheerio для работы с html, сам сайты парсил ей

    Reply ↓
  21. nvv1970

    (21) спасибо за разъяснения

    питон начал учить ради аналитического интереса, в копилку и в помощь 1с, sql, bash, ps, oscript и т.п., да и просто ради разминки мозга. Уж больно синтаксис хорош ))

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

    Reply ↓
  22. riposte

    (22)

    Ботов на нем удобно писать. И для телеграма, и для прочих мессенджеровсервисов.

    Ну и, собственно, эти боты могут применяться в самых разных сферах.

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

    Reply ↓
  23. Diversus

    (0) Ваша модель имеет несколько серьезных недостатков:

    1. Длинная цепочка и сложность взаимодействия

    Есть старое доброе правило: чем больше в цепи разных звеньев, тем цепь становится не надежнее и если появится слабое звено, то цепь порвется. В вашей последовательности, если что-то отвалится, то весь механизм перестанет работать. Это плохо и это минус.

    2. Только вы адекватно сможете поддерживать эту систему

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

    3. Оперативность

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

    Зачем столько сложностей? У Вас может быть законный вопрос: «ну вот ладно, ты Виталий, тут критикуешь, а что можешь по существу сказать?». Вопрос правильный и сказать мне есть что.

    Почему не написать в базе HTTP-сервис, который бы все это делал? При этом: все было бы оперативно, в одной базе, могло дописаться любым 1С-ником.

    Я столкнулся с подобной проблемой, для нашего решения Управление IT-отделом 8 необходимо было сделать личный кабинет пользователей для создания заявок из веба. По сути — это ваша задача, только надо не заказы вносить сторонним пользователям, а задания в техподдержку, но тут нужна оперативность.

    Как поступил я?

    Я пошел по другому пути. Сделал возможность вносить HTML-файлы, файлы стилей, картинки, js-скрипты в отдельный справочник. Создал HTTP-сервис, который определял какой файл нужно показать в данный момент и отдаю по HTTP данные построенные в 1С.

    Как выглядит скриншот результата можно увидеть во вложениях:

    Получилось то, что хотел и можно посмотреть видео как оно работает:

    https://youtu.be/yEjMlcnH3Vk

    Если тема интересная могу отдельную статью написать.

    Reply ↓
  24. herfis

    (23) Не до конца понятна фраза «Создал HTTP-сервис, который определял какой файл нужно показать в данный момент».

    Это типа мини-вебсервер получился?

    Ну а диплоймент из 1С — это такое… Не сказать, что киллер-фича.

    Reply ↓
  25. Diversus

    (25)

    Не до конца понятна фраза «Создал HTTP-сервис, который определял какой файл нужно показать в данный момент».

    Это типа мини-вебсервер получился?

    Да, получается так. Apache или IIS присылает запрос, этот запрос разбирается, строится страница и выдается HTTP-ответ.

    Причем странички можно изменять «на лету» в режиме предприятия.

    Reply ↓
  26. herfis

    (26)

    Причем странички можно изменять «на лету» в режиме предприятия

    Каким именно образом? При записи «пушатся» на сервер через какой-то API вашего сервиса? Или каким-то более «рабоче-крестьянским» методом?

    Reply ↓
  27. riposte

    1. Критичное звено — это этап выгрузки и последующей загрузки. Если оно даст сбой, информация в базе будет неполной или неактуальной. Этот этап будет в ближайшее время пересмотрен, т.к. на момент создания не было четкого понимания возможностей rest api.

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

    Другое дело, когда написано по-китайски или лапшой. Я надеюсь, что у меня не настолько сложный и непонятный код. По поводу «другой разработчик, все переписать» — да и пусть себе переписывает. Если другой разработчик преследует цель сделать как ему нравится или как он считает нужным, он найдет аргументы в пользу «все фигня, надо по другому».

    3. Задачи постоянной выгрузки или полной интеграции не стояло. Цены в УТ устанавливаются на день и не так часто, актуальность оперативных остатков с точностью до минуты тоже не является обязательным фактором. Итоговый заказ, сформированный на сайте, не факт что будет реализован именно так, как придет. Что-то уже в резервах, что-то будет предложено из альтернатив, что-то пойдет в допоставку — это уже работа отделов. Требование к менеджеру вручную загружать и обрабатывать заказ скорее организационное, нежели из-за лени реализовать автоматическое формирование заказа. «Не заметил уведомление, забыл и т.д.» А так менеджер берет номер заказа и обрабатывает его сразу до этапа согласования и выставления счета.

    По поводу вэбклиента на базе 1С.

    Немного непонятно, это что-то вроде реализации шаблонизатора Jinja? Было бы неплохо, конечно, использовать непосредственно 1С как источник данных и бэкэнд, но узким местом в нашем случае будет доступность самого сервера, который нельзя разместить вне офиса, не такой широкий канал, и физически он всего один. Плюс даунтаймы из-за периодических проблем с электричеством или из-за того, что с сервером возникли проблемы. Крайне редко, конечно, но случается. Обеспечить хорошую доступность и аптаймы 24/7/365 мы не можем.

    Хотелось бы заменить стэк XML->FTP->DB на что-то типа DRF<-1C API или 1C->DB API. Где-то натыкался на реализацию REST-запросов к 1С, сяду этим заниматься, обязательно найду. Но отдавать HTML самой 1С… видится мне менее надежным, нежели когда 1С отдает JSON, а рисованием страниц занимается обычный JS-фреймворк.

    Reply ↓
  28. Diversus

    (27)

    Каким именно образом? При записи «пушатся» на сервер через какой-то API вашего сервиса? Или каким-то более «рабоче-крестьянским» методом?

    По сути, вся логика построения странички вынесена в справочник в поле «Алгоритм заполнения». Там код на языке 1С, этот код строит страничку при поступлении запроса. Если этот алгоритм заполнения мы поменяем в режиме предприятия, то изменения применяться сразу же и сервис начнет отдавать новый результат.

    Этот код так же может взаимодействовать с остальными частями конфигурации.

    Например, есть веб-форма новое задание, пользователь нажимает на кнопку «Отправить», HTTP-сервису передается POST-запрос, который он обрабатывает, читает значения реквизитов и создает новое задание кодом на 1С (закладка «Алгоритм заполнения»).

    Reply ↓
  29. nvv1970

    (24) А как вам такое:

    Например, реализуем некую примитивную игру, которую можно разделить на серверную и клиентскую части (общаемся удаленно по API — http-сервису). Пусть, условно, это будет карточная (дурак, 1000 и т.п.).

    Цель — развлечение и тренировка реализации. Сервер общий, клиенты — разные (живые или битва ботов).

    Все очень быстро и легко реализуется на 1С. Но… в интернет официально не выставишь… Лицензии )

    Вот и думаю потренироваться питоном…

    Reply ↓
  30. riposte

    (23)

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

    Если тема интересная могу отдельную статью написать.

    Интересная, жду статью.

    Reply ↓
  31. TODD22

    (23)

    Почему не написать в базе HTTP-сервис, который бы все это делал?

    1. Потому что этот сервис в базе 1С. Со всеми вытекающими из этого проблемами.(клиенты будут часто запросы отправлять, за дидосят базу)

    2. У Джанго есть много разных полезных модулей которые на 1С скорее всего придётся писать самому.

    Reply ↓
  32. Diversus

    (28)

    Но отдавать HTML самой 1С… видится мне менее надежным, нежели когда 1С отдает JSON, а рисованием страниц занимается обычный JS-фреймворк.

    А кто сказал, что рисованием страниц занимается 1С? 🙂 1С отдает HTTP-файлы (html, js, css, картинки и прочее), а в этих файлах могут быть любые данные, в том числе и страницы фреймворков, скрипты и прочее. Например, наш проект для вывода данных использует Bootstrap + JQuery + chart.js Т.е. 1С нам нужна именно для генерации полезного кода, все остальное отдается браузеру как есть. Есть шаблон заполнения странички, есть алгоритм заполнения недостающих частей страницы, алгоритм выполняется 1С. Итоговый результат отправляется пользователю.

    И да — это в какой-то мере и шаблонизатор.

    Reply ↓
  33. riposte

    (33)

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

    Кто-то уже спрашивал вроде про ддос и прочие прелести заваливания сервера мусорными запросами.

    Reply ↓
  34. Diversus

    (32)

    Потому что этот сервис в базе 1С. Со всеми вытекающими из этого проблемами.(клиенты будут часто запросы отправлять, за дидосят базу)

    Нагрузка на сервер 1С HTTP-сервисами минимальная. Надо понимать, что это не полноценный сеанс работы с 1С + есть возможность кэшировать подключения пользователей средствами 1С… Т.е. можно настроить так, чтобы новые запросы не делали новые сеансы (на какое-то время), а использовали пул подключений. Так что не за дидосят…

    У Джанго есть много разных полезных модулей которые на 1С скорее всего придётся писать самому.

    Дак используйте Джанго в связке, кто мешает? Повторюсь, мы в своем проекте используем Bootstrap + JQuery + chart.js и никто не мешает использовать ваш Джанго. Заливайте в справочник папочку с Джанго. Добавляете странички, которые используют этот фреймворк Джанго, из 1С это все отдается и вуаля, Джанго освобожденный! 🙂

    Reply ↓
  35. riposte

    (35)

    А другой программист, когда придет, разберется, как это все работает? )

    Ладно, шучу. Ждем статью.

    Reply ↓
  36. TODD22

    (35)Зачем его «заливать» в 1С?

    Reply ↓
  37. Diversus

    (34) ответ в (35) единственное дополню.

    Вот ссылка на повышение производительности http://v8.1c.ru/o7/201604service/index.htm

    Reply ↓
  38. Diversus

    (37) Можете в тексте странички использовать CDN-ссылки на скрипты, но для возможности использовать в локальной сети, которая может быть без доступа к интернету лучше «залить».

    Reply ↓
  39. avk72

    (23) То, что Вы предлагаете, не всегда применимо по нижеследующим причинам:

    1. Не всегда есть возможность разместить 1с на стороннем хостинге.

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

    2. 1с требует периодического останова на регламентные операции и прочее.

    3. Конфиденциальность.

    Обычно, базы 1с размещают на внутренних серверах компании, потому, что не все что есть в базе должно быть публично.

    2. Только вы адекватно сможете поддерживать эту систему

    Я не уверен, что обыкновенный одинэсник разбирается в javascript и может исправить при необходимости выдачу контента через http сервис.

    Можеть быть, для управления IT отделом, Ваш подход вполне применим, но для веб витрины все же предпочтительней отдельное веб приложение с собственным бекэндом и базой данных.

    (0) Автору хочется пожелать удачи. Сайт вполне неплох. Молодец.

    Reply ↓
  40. Diversus

    (40) Да, вы правы. Есть плюсы, есть минусы того, или иного подхода.

    Решение, которое реализовали мы — это «нативный» подход. У автора свое видение и свое восприятие ситуации, которую надо решить в определенном месте с конкретными условиями, но как сказал выше автор, он не знал, что так можно.

    Безусловно то, что автор реализовал такую задачу — это отлично и он молодец! С этим никто и не спорит.

    Reply ↓
  41. avk72

    (0) Я тоже смотрел в строну фреймворка Vuetify и вообще разработки на Vue, но мне не хватило некоторых компонентов:

    Селектора с возможностью выбора из дерева.

    Пошагового селектора, когда выбираем сначала, например, страну, а затем город в этой стране.

    Некоторых других вещей.

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

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

    Reply ↓
  42. riposte

    (42)

    VDataIterator используется при отрисовке на малых экранах. (XS, SM). Можете проверить, уменьшив окно браузера.

    Reply ↓
  43. Kalam

    Автор красавчик. Если был бы такой же запрос, тоже бы так сделал.

    Работа конечно проделана большая и всё, имхо подобрано и сделано удачно, ну да с обменами можно было бы подумать, но сроки не дали ))

    Тоже думал что-то такое с прайсами и заказами сделать, но времени нет, всё так же как и с ботами под телегу для заббикса 😉

    Reply ↓
  44. s_vidyakin

    (42) Так вот же https://vue-treeselect.js.org/

    Reply ↓
  45. avk72

    (45) Там возникли проблемы с наползанием элементов друг на друга и со скрытием меню во время выбора.Я уже не помню точно. Я и другие смотрел варианты. Предпочтительно, чтобы все компоненты были реализованы в одном фреймворке и имели более менее согласованный стиль оформления. В итоге сделал кастомный билд Vuetify с нужными компонентами. Их пришлось делать собственноручно. Сейчас думаю, как бы все это оформить отдельной библиотекой. Но все упирается во время.

    У автора были две недели. А у меня с этим сложности….

    Reply ↓
  46. philya

    (16) Можно сделать еще шаг. И подключить внешние источники данных к 1с и лить данные в базу данных сайта напрямую из 1с без всяких файликов.

    Reply ↓
  47. baracuda

    Добавил в закладки спасибо, я проделывал уже такое.

    правда данные на сайт лил простым POST запросом с JSON данными. Отрабатывает на ура, и файлики не нужны.

    Reply ↓
  48. herfis

    Интересно было прикоснуться к питоновой инфраструктуре, спасибо.

    Reply ↓
  49. user778014

    А вот добавил бы господин Нуралиев в 1с доступ к html верстке и лицензирование 1c по ядрам, так и не нужна бы была вся эта приблуда с Python, Django, Vue.js и прочая лабудистика

    Reply ↓
  50. _Z1

    (50) Не очень понятно чем это поможет.Ведь в данном решении все таки два сервера

    один это сервер где приложение 1с

    Второй сервер это VPS хостинге.

    Предположим что у Вас нет цен за Лицензию 1c.

    Вы хотите совместить эти два сервера и пустить внешних клиентов в свою внутреннюю сетку ?

    или Вы хотите на втором сервере который снаружи полностью написать сайт на 1с ?

    Reply ↓
  51. user778014

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

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

    Reply ↓
  52. acanta

    (52)видимо изучают спрос.

    Reply ↓
  53. user778014

    (53) В принципе даже просто добавив лицензирование по ядрам уже можно бы было использовать 1с в различных вебсервисах более активно

    Reply ↓
  54. riposte

    (50) https://infostart.ru/public/305854/

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

    Тем не менее, вэб-сеансы будут нуждаться в лицензировании.

    А вот когда 1С выступает просто источником данных и иницатором обмена с бэкендом через регламентноефоновое задание — лицензия не требуется (кроме лицензии на сервер 1С).

    Сохраняется безусловная безопасность самой базы 1С, т.к. прямого доступа к ней из интернета нет. В СУБД на бэкенде присутствует только выгруженная информация, необходимая для работы приложения, поэтому она не критична сама по себе. Ну и падение 1С не останавливает работу сайта, как падение сайта не останавливает работу 1С. Разделение задач и сред выполнения таки повышает в целом стабильность системы. По аналогии и с серверами — не пихают все в одну ОС, а создают несколько серверов, каждый выполняющий свои 1-3 задачи. Создание комбайнов, которые «делают все» чревато остановкой работы всего при их отказе.

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

    Reply ↓
  56. albert.goncharov

    Не смотрел, но сам подход абалденный!

    Reply ↓
  57. утюгчеловек

    (31) Формально http-соединения к 1С лицензируются)

    Reply ↓
  58. silberRus

    Не смотрел, не могу ничего сказать.

    но когда вижу rest и ftp рядом — не понимаю, зачем.

    Reply ↓
  59. riposte

    (59)

    Один из клиентов забирает отведенные ему файлики выгрузки на свой сайт.

    С оформления для него этой выгрузки все и началось.

    А раз это уже было сделано, то рядом делать выгрузку через API не стал.

    Так то да, обновлял бы через запросы. Оно и напрашивается.

    Reply ↓
  60. andron58

    А почему через ту же Django POST’ами инфу не заливать в БД (либо xml скармливать DJANGO, без использования FTP, 21 век же, ну)

    Reply ↓
  61. andron58

    (61) понятно, увидел ответ выше

    Reply ↓
  62. user1255028

    (55)

    Судя по https://its.1c.ru/db/v8313doc#bookmark:adm:TI000000304

    Лицензии на любые интернет-сервисы не требуются.

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *