Комментарии
Избранное
Подписка
Сортировка:
Древо
Хорошо что у меня нет возможности ставить минусы, иначе я влепил бы два.
Первый за англицизмы в статье, это просто какой-то русско-английский суржик двоечника. Что в статье, что на сайте.
Второй за символ хероллара в шапке сайте.
Первый за англицизмы в статье, это просто какой-то русско-английский суржик двоечника. Что в статье, что на сайте.
Второй за символ хероллара в шапке сайте.
(2)
Я тоже долго размышлял над данным суржиковым словом данного суржиконенависника. Даже подумал, было, что это такое имя. Ну типа, "ХероЛара Крофт, расхитительница гробниц". Может, человек не согласен таким отношением к гробницам? Или качество фильмов не нравится (тут я тоже согласен, что ХероЛара Крофт подошло бы лучше). Но потом я поиграл с ударением и решил, что, возможно, это такая рифма на "доллар", картинка с которым и правда нашлась в шапке сайта. Кейс клоузд.
Я тоже долго размышлял над данным суржиковым словом данного суржиконенависника. Даже подумал, было, что это такое имя. Ну типа, "ХероЛара Крофт, расхитительница гробниц". Может, человек не согласен таким отношением к гробницам? Или качество фильмов не нравится (тут я тоже согласен, что ХероЛара Крофт подошло бы лучше). Но потом я поиграл с ударением и решил, что, возможно, это такая рифма на "доллар", картинка с которым и правда нашлась в шапке сайта. Кейс клоузд.
Все, что в статье касается 1с - прошлый век.
Xml xls ftp зачем об этом всем писать, это чуть-ли не с начала 2000 в ходу
Про ftp в 1С - около 5 лет ежедневных выгрузок фото на ftp сайта раз в полчаса средствами 1С, ни одного сбоя, Самая простая и беспроблемная часть обмена всегда была.
Xml xls ftp зачем об этом всем писать, это чуть-ли не с начала 2000 в ходу
Про ftp в 1С - около 5 лет ежедневных выгрузок фото на ftp сайта раз в полчаса средствами 1С, ни одного сбоя, Самая простая и беспроблемная часть обмена всегда была.
(3)
Основная причина, по которой мне не понравились механизмы FTP-клиента 1С - отсутствие синхронизации каталогов.
Вторая причина проистекает из первой - долго. Циклы.
Третья - тяжело было соорудить так, чтобы не ломалось. У меня, во всяком случае, не получалось, когда доходило до выгрузки изображений. Нет-нет, а через 1000-другую файлов начинало отваливаться, причем каскадно.
А с WinSCP все получилось очень просто и без бубна.
Тем не менее, как и было замечено, процедуры формирования XML и обмены по FTP уже со всех сторон неоднократно рассмотрены.
Основная причина, по которой мне не понравились механизмы FTP-клиента 1С - отсутствие синхронизации каталогов.
Вторая причина проистекает из первой - долго. Циклы.
Третья - тяжело было соорудить так, чтобы не ломалось. У меня, во всяком случае, не получалось, когда доходило до выгрузки изображений. Нет-нет, а через 1000-другую файлов начинало отваливаться, причем каскадно.
А с WinSCP все получилось очень просто и без бубна.
Тем не менее, как и было замечено, процедуры формирования XML и обмены по FTP уже со всех сторон неоднократно рассмотрены.
(5)
(8)
Господа, зачем прицепились к FTP. Может в текущей реализации это было удобнее всего. Зато какая клевая остальная архитектура. Статья очень познавательная.
Некоторые блоки правда напрашиваются на замену, но это придирки))
Автор, спасибо за хороший пример.
ья - тяжело было соорудить так, чтобы не ломалось. У меня, во всяком случае, не получалось, когда доходило до выгрузки изображений. Нет-нет, а через 1000-другую файлов начинало отваливаться, причем каскадно.
(8)
Господа, зачем прицепились к FTP. Может в текущей реализации это было удобнее всего. Зато какая клевая остальная архитектура. Статья очень познавательная.
Некоторые блоки правда напрашиваются на замену, но это придирки))
Автор, спасибо за хороший пример.
Дизайн сайта конечно жесть :) В стиле WEB-2000. И конечно обязательно нужны мельтешащие видео и слайды в шапке. Лучше уж wordpress как по мне.
Но сама работа добротная проделана, раз всё работает.
Но сама работа добротная проделана, раз всё работает.
В общем, я предложил - мне дали добро. Срок поставили - месяц. Справился за полтора, ибо замену картриджей никто не отменял.
Что-то мне подсказывает, что лучше выбрать специализацию не такую широкую, если про картриджи буквально было.
(12)
В первоначально версии не было блока commercials (той самой полоски с рекламой вверху).
Я пытался объяснить, что добавление всех этих вещей - это уменьшение эффективного пространства самого приложения - таблицы с товарами, да и в принципе лишнее, учитывая предназначение сервиса. Но заказчик был неумолим.
Скорее всего, через пару версий корневая страница будет представлять из себя стандартную для многих магазинов простыню из баннеров, а сам функционал прайса будет вынесен на отдельную страницу безо всяких мельтешащих реклам и каруселей.
В первоначально версии не было блока commercials (той самой полоски с рекламой вверху).
Я пытался объяснить, что добавление всех этих вещей - это уменьшение эффективного пространства самого приложения - таблицы с товарами, да и в принципе лишнее, учитывая предназначение сервиса. Но заказчик был неумолим.
Скорее всего, через пару версий корневая страница будет представлять из себя стандартную для многих магазинов простыню из баннеров, а сам функционал прайса будет вынесен на отдельную страницу безо всяких мельтешащих реклам и каруселей.
Предложенный алгоритм выгрузки данных на сайт (получение данных в 1с -> формирование xml и отправка на сайт -> разбор xml на стороне сайта и запись в бд) можно упростить, формируя текст запроса к субд непосредственно в 1с. Т.е. на выходе из 1с не xml, а текст с уже сформированными командами insert, который достаточно сразу отдать на выполнение субд (можно даже планировщиком).
(15) точнее - почему не cheerio+axios
Вообще можно было без питона обойтись, все на node.js сделать, но раз человек знает питон...
+ Можно из 1С сразу через веб-сервис отдавать zip-архив с таблицами в JSON и картинками, на сервере распаковать и раскидать в базу
Вообще можно было без питона обойтись, все на node.js сделать, но раз человек знает питон...
+ Можно из 1С сразу через веб-сервис отдавать zip-архив с таблицами в JSON и картинками, на сервере распаковать и раскидать в базу
(19) Да нет, питон тоже топ) но он больше применяется в BigData, ИИ, обработке данных, научных исследованиях.
Веб тоже можно, но это не мейнстрим, скорее исключение. Вот pinterest, dropbox и инстаграм до сих пор на джанго крутятся.
Можно и наоборот, написать все на питоне, кроме Vue на клиенте, в питоне есть библиотека beautifulSoup4 типа cheerio для работы с html, сам сайты парсил ей
Веб тоже можно, но это не мейнстрим, скорее исключение. Вот pinterest, dropbox и инстаграм до сих пор на джанго крутятся.
Можно и наоборот, написать все на питоне, кроме Vue на клиенте, в питоне есть библиотека beautifulSoup4 типа cheerio для работы с html, сам сайты парсил ей
(21) спасибо за разъяснения
питон начал учить ради аналитического интереса, в копилку и в помощь 1с, sql, bash, ps, oscript и т.п., да и просто ради разминки мозга. Уж больно синтаксис хорош ))
Вот и думаю, где в жизни мне он реально понадобится... Понадобится ли... За рамки бэкенда вылазить не планирую. А учить все языки на свете - моск лопается. Да и возможности для этого есть только при работе на предприятиях, когда за время можно не отчитываться. ((
питон начал учить ради аналитического интереса, в копилку и в помощь 1с, sql, bash, ps, oscript и т.п., да и просто ради разминки мозга. Уж больно синтаксис хорош ))
Вот и думаю, где в жизни мне он реально понадобится... Понадобится ли... За рамки бэкенда вылазить не планирую. А учить все языки на свете - моск лопается. Да и возможности для этого есть только при работе на предприятиях, когда за время можно не отчитываться. ((
(22)
Ботов на нем удобно писать. И для телеграма, и для прочих мессенджеров\сервисов.
Ну и, собственно, эти боты могут применяться в самых разных сферах.
Сам хочу написать бота в телеграм под заббикс с пачкой скриптов на примитивные операции по управлению серверами - рестарты служб, перезагрузки и т.д. Но хотелок, как всегда, больше чем времени.
Ботов на нем удобно писать. И для телеграма, и для прочих мессенджеров\сервисов.
Ну и, собственно, эти боты могут применяться в самых разных сферах.
Сам хочу написать бота в телеграм под заббикс с пачкой скриптов на примитивные операции по управлению серверами - рестарты служб, перезагрузки и т.д. Но хотелок, как всегда, больше чем времени.
(24) А как вам такое:
Например, реализуем некую примитивную игру, которую можно разделить на серверную и клиентскую части (общаемся удаленно по API - http-сервису). Пусть, условно, это будет карточная (дурак, 1000 и т.п.).
Цель - развлечение и тренировка реализации. Сервер общий, клиенты - разные (живые или битва ботов).
Все очень быстро и легко реализуется на 1С. Но... в интернет официально не выставишь... Лицензии )
Вот и думаю потренироваться питоном...
Например, реализуем некую примитивную игру, которую можно разделить на серверную и клиентскую части (общаемся удаленно по API - http-сервису). Пусть, условно, это будет карточная (дурак, 1000 и т.п.).
Цель - развлечение и тренировка реализации. Сервер общий, клиенты - разные (живые или битва ботов).
Все очень быстро и легко реализуется на 1С. Но... в интернет официально не выставишь... Лицензии )
Вот и думаю потренироваться питоном...
Я вообще рад за автора, если внедрение прошло и клиент получил инструмент. Даже полмиллиона можно ставить в ценник, так как гарантия стоит тоже денег, и не только во времени плотного сидения в отпуске дело, а в том, что менеджеры смогут удобнее барыжить ещё три-четыре квартала, пока можно плотно сидеть над решением без 1с, если на него будет заказ, а если не будет, то эти четыре квартала превратятся в, страшно сказать, ...? Четырнадцать?
(0) Ваша модель имеет несколько серьезных недостатков:
1. Длинная цепочка и сложность взаимодействия
Есть старое доброе правило: чем больше в цепи разных звеньев, тем цепь становится не надежнее и если появится слабое звено, то цепь порвется. В вашей последовательности, если что-то отвалится, то весь механизм перестанет работать. Это плохо и это минус.
2. Только вы адекватно сможете поддерживать эту систему
Для работодателя это плохо. Если вы завтра захотите уйти из фирмы, то фирма может пострадать от того, что не будет специалистов, которые смогут восстановить работу или что-то дописать. Для вас это хорошо, для работодателя плохо. И после вас придет какой-нибудь разработчик и скажет, что все надо переписать и что он удивляется как это все работает до сих пор.
3. Оперативность
Ее просто нет. Выгрузка раз в день всех позиций может быть не достаточной. Зачем-то менеджерам нужна по сути самостоятельно запускать загрузку нужного заказа. Это время.
Зачем столько сложностей? У Вас может быть законный вопрос: "ну вот ладно, ты Виталий, тут критикуешь, а что можешь по существу сказать?". Вопрос правильный и сказать мне есть что.
Почему не написать в базе HTTP-сервис, который бы все это делал? При этом: все было бы оперативно, в одной базе, могло дописаться любым 1С-ником.
Я столкнулся с подобной проблемой, для нашего решения необходимо было сделать личный кабинет пользователей для создания заявок из веба. По сути - это ваша задача, только надо не заказы вносить сторонним пользователям, а задания в техподдержку, но тут нужна оперативность.
Как поступил я?
Я пошел по другому пути. Сделал возможность вносить HTML-файлы, файлы стилей, картинки, js-скрипты в отдельный справочник. Создал HTTP-сервис, который определял какой файл нужно показать в данный момент и отдаю по HTTP данные построенные в 1С.
Как выглядит скриншот результата можно увидеть во вложениях:
Получилось то, что хотел и можно посмотреть видео как оно работает:
Если тема интересная могу отдельную статью написать.
1. Длинная цепочка и сложность взаимодействия
Есть старое доброе правило: чем больше в цепи разных звеньев, тем цепь становится не надежнее и если появится слабое звено, то цепь порвется. В вашей последовательности, если что-то отвалится, то весь механизм перестанет работать. Это плохо и это минус.
2. Только вы адекватно сможете поддерживать эту систему
Для работодателя это плохо. Если вы завтра захотите уйти из фирмы, то фирма может пострадать от того, что не будет специалистов, которые смогут восстановить работу или что-то дописать. Для вас это хорошо, для работодателя плохо. И после вас придет какой-нибудь разработчик и скажет, что все надо переписать и что он удивляется как это все работает до сих пор.
3. Оперативность
Ее просто нет. Выгрузка раз в день всех позиций может быть не достаточной. Зачем-то менеджерам нужна по сути самостоятельно запускать загрузку нужного заказа. Это время.
Зачем столько сложностей? У Вас может быть законный вопрос: "ну вот ладно, ты Виталий, тут критикуешь, а что можешь по существу сказать?". Вопрос правильный и сказать мне есть что.
Почему не написать в базе HTTP-сервис, который бы все это делал? При этом: все было бы оперативно, в одной базе, могло дописаться любым 1С-ником.
Я столкнулся с подобной проблемой, для нашего решения необходимо было сделать личный кабинет пользователей для создания заявок из веба. По сути - это ваша задача, только надо не заказы вносить сторонним пользователям, а задания в техподдержку, но тут нужна оперативность.
Как поступил я?
Я пошел по другому пути. Сделал возможность вносить HTML-файлы, файлы стилей, картинки, js-скрипты в отдельный справочник. Создал HTTP-сервис, который определял какой файл нужно показать в данный момент и отдаю по HTTP данные построенные в 1С.
Как выглядит скриншот результата можно увидеть во вложениях:
Получилось то, что хотел и можно посмотреть видео как оно работает:
Если тема интересная могу отдельную статью написать.
Прикрепленные файлы:
(25)
Да, получается так. Apache или IIS присылает запрос, этот запрос разбирается, строится страница и выдается HTTP-ответ.
Причем странички можно изменять "на лету" в режиме предприятия.
Не до конца понятна фраза "Создал HTTP-сервис, который определял какой файл нужно показать в данный момент".
Это типа мини-вебсервер получился?
Это типа мини-вебсервер получился?
Да, получается так. Apache или IIS присылает запрос, этот запрос разбирается, строится страница и выдается HTTP-ответ.
Причем странички можно изменять "на лету" в режиме предприятия.
(27)
По сути, вся логика построения странички вынесена в справочник в поле "Алгоритм заполнения". Там код на языке 1С, этот код строит страничку при поступлении запроса. Если этот алгоритм заполнения мы поменяем в режиме предприятия, то изменения применяться сразу же и сервис начнет отдавать новый результат.
Этот код так же может взаимодействовать с остальными частями конфигурации.
Например, есть веб-форма новое задание, пользователь нажимает на кнопку "Отправить", HTTP-сервису передается POST-запрос, который он обрабатывает, читает значения реквизитов и создает новое задание кодом на 1С (закладка "Алгоритм заполнения").
Каким именно образом? При записи "пушатся" на сервер через какой-то API вашего сервиса? Или каким-то более "рабоче-крестьянским" методом?
По сути, вся логика построения странички вынесена в справочник в поле "Алгоритм заполнения". Там код на языке 1С, этот код строит страничку при поступлении запроса. Если этот алгоритм заполнения мы поменяем в режиме предприятия, то изменения применяться сразу же и сервис начнет отдавать новый результат.
Этот код так же может взаимодействовать с остальными частями конфигурации.
Например, есть веб-форма новое задание, пользователь нажимает на кнопку "Отправить", HTTP-сервису передается POST-запрос, который он обрабатывает, читает значения реквизитов и создает новое задание кодом на 1С (закладка "Алгоритм заполнения").
(23)
Кстати, не знал что 1С так может. В свое время дико раздражал факт, что нельзя предоставить нелицензируемый доступ к какой-то базе через вэб, а только вэб-клиент и лицензия под него с ключа или сервера.
Интересная, жду статью.
Кстати, не знал что 1С так может. В свое время дико раздражал факт, что нельзя предоставить нелицензируемый доступ к какой-то базе через вэб, а только вэб-клиент и лицензия под него с ключа или сервера.
Если тема интересная могу отдельную статью написать.
Интересная, жду статью.
(23)
1. Потому что этот сервис в базе 1С. Со всеми вытекающими из этого проблемами.(клиенты будут часто запросы отправлять, за дидосят базу)
2. У Джанго есть много разных полезных модулей которые на 1С скорее всего придётся писать самому.
Почему не написать в базе HTTP-сервис, который бы все это делал?
1. Потому что этот сервис в базе 1С. Со всеми вытекающими из этого проблемами.(клиенты будут часто запросы отправлять, за дидосят базу)
2. У Джанго есть много разных полезных модулей которые на 1С скорее всего придётся писать самому.
(32)
Нагрузка на сервер 1С HTTP-сервисами минимальная. Надо понимать, что это не полноценный сеанс работы с 1С + есть возможность кэшировать подключения пользователей средствами 1С... Т.е. можно настроить так, чтобы новые запросы не делали новые сеансы (на какое-то время), а использовали пул подключений. Так что не за дидосят...
Дак используйте Джанго в связке, кто мешает? Повторюсь, мы в своем проекте используем Bootstrap + JQuery + chart.js и никто не мешает использовать ваш Джанго. Заливайте в справочник папочку с Джанго. Добавляете странички, которые используют этот фреймворк Джанго, из 1С это все отдается и вуаля, Джанго освобожденный! :)
Потому что этот сервис в базе 1С. Со всеми вытекающими из этого проблемами.(клиенты будут часто запросы отправлять, за дидосят базу)
Нагрузка на сервер 1С HTTP-сервисами минимальная. Надо понимать, что это не полноценный сеанс работы с 1С + есть возможность кэшировать подключения пользователей средствами 1С... Т.е. можно настроить так, чтобы новые запросы не делали новые сеансы (на какое-то время), а использовали пул подключений. Так что не за дидосят...
У Джанго есть много разных полезных модулей которые на 1С скорее всего придётся писать самому.
Дак используйте Джанго в связке, кто мешает? Повторюсь, мы в своем проекте используем Bootstrap + JQuery + chart.js и никто не мешает использовать ваш Джанго. Заливайте в справочник папочку с Джанго. Добавляете странички, которые используют этот фреймворк Джанго, из 1С это все отдается и вуаля, Джанго освобожденный! :)
(23) То, что Вы предлагаете, не всегда применимо по нижеследующим причинам:
1. Не всегда есть возможность разместить 1с на стороннем хостинге.
У автора веб сайт функционирует независимо от 1с и может работать автономно, в качестве веб витрины предприятия. Поэтому, я бы на его месте, также бы делал веб сайт с собственным бекэндом. Да, необходимо организовывать обмены, но основной плюс в том, что мы на выходе имеем две слабосвязанные системы, которые могут работать независимо друг от друга.
2. 1с требует периодического останова на регламентные операции и прочее.
3. Конфиденциальность.
Обычно, базы 1с размещают на внутренних серверах компании, потому, что не все что есть в базе должно быть публично.
Я не уверен, что обыкновенный одинэсник разбирается в javascript и может исправить при необходимости выдачу контента через http сервис.
Можеть быть, для управления IT отделом, Ваш подход вполне применим, но для веб витрины все же предпочтительней отдельное веб приложение с собственным бекэндом и базой данных.
(0) Автору хочется пожелать удачи. Сайт вполне неплох. Молодец.
1. Не всегда есть возможность разместить 1с на стороннем хостинге.
У автора веб сайт функционирует независимо от 1с и может работать автономно, в качестве веб витрины предприятия. Поэтому, я бы на его месте, также бы делал веб сайт с собственным бекэндом. Да, необходимо организовывать обмены, но основной плюс в том, что мы на выходе имеем две слабосвязанные системы, которые могут работать независимо друг от друга.
2. 1с требует периодического останова на регламентные операции и прочее.
3. Конфиденциальность.
Обычно, базы 1с размещают на внутренних серверах компании, потому, что не все что есть в базе должно быть публично.
2. Только вы адекватно сможете поддерживать эту систему
Я не уверен, что обыкновенный одинэсник разбирается в javascript и может исправить при необходимости выдачу контента через http сервис.
Можеть быть, для управления IT отделом, Ваш подход вполне применим, но для веб витрины все же предпочтительней отдельное веб приложение с собственным бекэндом и базой данных.
(0) Автору хочется пожелать удачи. Сайт вполне неплох. Молодец.
(40) Да, вы правы. Есть плюсы, есть минусы того, или иного подхода.
Решение, которое реализовали мы - это "нативный" подход. У автора свое видение и свое восприятие ситуации, которую надо решить в определенном месте с конкретными условиями, но как сказал выше автор, он не знал, что так можно.
Безусловно то, что автор реализовал такую задачу - это отлично и он молодец! С этим никто и не спорит.
Решение, которое реализовали мы - это "нативный" подход. У автора свое видение и свое восприятие ситуации, которую надо решить в определенном месте с конкретными условиями, но как сказал выше автор, он не знал, что так можно.
Безусловно то, что автор реализовал такую задачу - это отлично и он молодец! С этим никто и не спорит.
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-фреймворк.
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-фреймворк.
(28)
А кто сказал, что рисованием страниц занимается 1С? :) 1С отдает HTTP-файлы (html, js, css, картинки и прочее), а в этих файлах могут быть любые данные, в том числе и страницы фреймворков, скрипты и прочее. Например, наш проект для вывода данных использует Bootstrap + JQuery + chart.js Т.е. 1С нам нужна именно для генерации полезного кода, все остальное отдается браузеру как есть. Есть шаблон заполнения странички, есть алгоритм заполнения недостающих частей страницы, алгоритм выполняется 1С. Итоговый результат отправляется пользователю.
И да - это в какой-то мере и шаблонизатор.
Но отдавать HTML самой 1С... видится мне менее надежным, нежели когда 1С отдает JSON, а рисованием страниц занимается обычный JS-фреймворк.
А кто сказал, что рисованием страниц занимается 1С? :) 1С отдает HTTP-файлы (html, js, css, картинки и прочее), а в этих файлах могут быть любые данные, в том числе и страницы фреймворков, скрипты и прочее. Например, наш проект для вывода данных использует Bootstrap + JQuery + chart.js Т.е. 1С нам нужна именно для генерации полезного кода, все остальное отдается браузеру как есть. Есть шаблон заполнения странички, есть алгоритм заполнения недостающих частей страницы, алгоритм выполняется 1С. Итоговый результат отправляется пользователю.
И да - это в какой-то мере и шаблонизатор.
(0) Я тоже смотрел в строну фреймворка Vuetify и вообще разработки на Vue, но мне не хватило некоторых компонентов:
Селектора с возможностью выбора из дерева.
Пошагового селектора, когда выбираем сначала, например, страну, а затем город в этой стране.
Некоторых других вещей.
После долгой переписки с разработчиками, пришел к выводу, что проще самому сделать эти компоненты. чем ждать, пока их реализуют.
Список товаров, думаю, можно сделать с VDataIterator и показывать отдельными карточками. Так наверное лучше выглядеть будет.
Селектора с возможностью выбора из дерева.
Пошагового селектора, когда выбираем сначала, например, страну, а затем город в этой стране.
Некоторых других вещей.
После долгой переписки с разработчиками, пришел к выводу, что проще самому сделать эти компоненты. чем ждать, пока их реализуют.
Список товаров, думаю, можно сделать с VDataIterator и показывать отдельными карточками. Так наверное лучше выглядеть будет.
(45) Там возникли проблемы с наползанием элементов друг на друга и со скрытием меню во время выбора.Я уже не помню точно. Я и другие смотрел варианты. Предпочтительно, чтобы все компоненты были реализованы в одном фреймворке и имели более менее согласованный стиль оформления. В итоге сделал кастомный билд Vuetify с нужными компонентами. Их пришлось делать собственноручно. Сейчас думаю, как бы все это оформить отдельной библиотекой. Но все упирается во время.
У автора были две недели. А у меня с этим сложности....
У автора были две недели. А у меня с этим сложности....
Автор красавчик. Если был бы такой же запрос, тоже бы так сделал.
Работа конечно проделана большая и всё, имхо подобрано и сделано удачно, ну да с обменами можно было бы подумать, но сроки не дали ))
Тоже думал что-то такое с прайсами и заказами сделать, но времени нет, всё так же как и с ботами под телегу для заббикса ;)
Работа конечно проделана большая и всё, имхо подобрано и сделано удачно, ну да с обменами можно было бы подумать, но сроки не дали ))
Тоже думал что-то такое с прайсами и заказами сделать, но времени нет, всё так же как и с ботами под телегу для заббикса ;)
(50) Не очень понятно чем это поможет.Ведь в данном решении все таки два сервера
один это сервер где приложение 1с
Второй сервер это VPS хостинге.
Предположим что у Вас нет цен за Лицензию 1c.
Вы хотите совместить эти два сервера и пустить внешних клиентов в свою внутреннюю сетку ?
или Вы хотите на втором сервере который снаружи полностью написать сайт на 1с ?
один это сервер где приложение 1с
Второй сервер это VPS хостинге.
Предположим что у Вас нет цен за Лицензию 1c.
Вы хотите совместить эти два сервера и пустить внешних клиентов в свою внутреннюю сетку ?
или Вы хотите на втором сервере который снаружи полностью написать сайт на 1с ?
(50)
Если так хочется, можно делать из сервера 1С бэкенд. Но Фронт на базе того же 1С уже будет слишком.
Тем не менее, вэб-сеансы будут нуждаться в лицензировании.
А вот когда 1С выступает просто источником данных и иницатором обмена с бэкендом через регламентное\фоновое задание - лицензия не требуется (кроме лицензии на сервер 1С).
Сохраняется безусловная безопасность самой базы 1С, т.к. прямого доступа к ней из интернета нет. В СУБД на бэкенде присутствует только выгруженная информация, необходимая для работы приложения, поэтому она не критична сама по себе. Ну и падение 1С не останавливает работу сайта, как падение сайта не останавливает работу 1С. Разделение задач и сред выполнения таки повышает в целом стабильность системы. По аналогии и с серверами - не пихают все в одну ОС, а создают несколько серверов, каждый выполняющий свои 1-3 задачи. Создание комбайнов, которые "делают все" чревато остановкой работы всего при их отказе.
А еще для повышения доступности и отказоустойчивости можно организовывать региональные кластеры практически всего и вся. Но это уже для энтерпрайзов уровня страны\мира.
Если так хочется, можно делать из сервера 1С бэкенд. Но Фронт на базе того же 1С уже будет слишком.
Тем не менее, вэб-сеансы будут нуждаться в лицензировании.
А вот когда 1С выступает просто источником данных и иницатором обмена с бэкендом через регламентное\фоновое задание - лицензия не требуется (кроме лицензии на сервер 1С).
Сохраняется безусловная безопасность самой базы 1С, т.к. прямого доступа к ней из интернета нет. В СУБД на бэкенде присутствует только выгруженная информация, необходимая для работы приложения, поэтому она не критична сама по себе. Ну и падение 1С не останавливает работу сайта, как падение сайта не останавливает работу 1С. Разделение задач и сред выполнения таки повышает в целом стабильность системы. По аналогии и с серверами - не пихают все в одну ОС, а создают несколько серверов, каждый выполняющий свои 1-3 задачи. Создание комбайнов, которые "делают все" чревато остановкой работы всего при их отказе.
А еще для повышения доступности и отказоустойчивости можно организовывать региональные кластеры практически всего и вся. Но это уже для энтерпрайзов уровня страны\мира.
Да разные варианты можно сделать. И первый и второй. Сейчас на 1с этот вариант не пройдет так как лицензирование нужно на каждое подключение, а у вас непонятно сколько пользователей будет заходить на сайт, плюс на 1с невозможно написать свой произвольный веб интерфейс.
Просто я о том что легким движением 1С руки, можно бы было сделать ненужными всю эту какафонию технологий
Просто я о том что легким движением 1С руки, можно бы было сделать ненужными всю эту какафонию технологий
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.