Comments 85
Посмотрите решение от Инстаграмм: rob.conery.io/2014/05/28/a-better-id-generator-for-postgresql
Instagram ultimately decides that they don’t want to rely on app code to create the id, nor do they want to introduce complexity with a Snowflake-style system. Instead, they cracked open Postgres and created their own Function.
A really neat idea! Sharding Postgres logically using schemas is a very interesting way to speed up reads and writes – but it obviously messes up id generation. This solution, however, seems pretty elegant!
Что касается UUID, в самой 1С, насколько падает производительность для достижения уникальных UUID? Вы пробовали делать сравнения c другими решениями?
Instagram ultimately decides that they don’t want to rely on app code to create the id, nor do they want to introduce complexity with a Snowflake-style system. Instead, they cracked open Postgres and created their own Function.
A really neat idea! Sharding Postgres logically using schemas is a very interesting way to speed up reads and writes – but it obviously messes up id generation. This solution, however, seems pretty elegant!
Что касается UUID, в самой 1С, насколько падает производительность для достижения уникальных UUID? Вы пробовали делать сравнения c другими решениями?
Простите, но я так и не понял зачем вы все это делали. Зачем нужна система обмена сообщениями в 1С?
Про это есть в начале статьи. Видимо, не вполне ясно сформулировали. Попробуем еще раз:
- Дать разработчикам прикладных решений надежный механизм обмена сообщениями между различными инсталляциями продуктов 1С
- Дать конечным пользователям 1С мессенджер внутри рабочего места
Взаимодействие сервера 1с с клиентом 1с (речь про управляемые формы) похоже на взаимодействие браузера с веб-сервером эпохи веб 1.0. Система взаимодействия — это что-то типа WebSocket, только прикрученное сбоку и неудобное в использовании.
А можно насчет вот этого поподробнее?
На ИТС есть инструкция только лишь насчет обмена сообщениями между пользователями.
Почему вы не хотите просто реализовать веб-сокеты в платформе? И разработчикам было бы легче, и вам не нужно было бы изобретать очередной велосипед.
Дать разработчикам прикладных решений надежный механизм обмена сообщениями между различными инсталляциями продуктов 1С
На ИТС есть инструкция только лишь насчет обмена сообщениями между пользователями.
Почему вы не хотите просто реализовать веб-сокеты в платформе? И разработчикам было бы легче, и вам не нужно было бы изобретать очередной велосипед.
Почему вы не хотите просто реализовать веб-сокеты в платформе?
Да, можно было сделать и так.
Но мессенджер внутри приложений 1С все же нужен (в частности, из-за возможности контекстного обсуждения конкретных объектов в 1С — документов и т.п.). А делать отдельно реализацию веб-сокетов и мессенджера — накладно. Плюс единая реализация позволяет, например, интерактивно взаимодействовать коду с пользователем внутри мессенджера — в частности, писать чат-ботов, интерактивно взаимодействующих с пользователем:
Ну я бы очень поспорил насчёт необходимости мессенджера внутри платформы(за годы как-то даже ни разу не приходила в голову такая идея), но не буду. А вот вебсокеты могли бы закрыть огромный пласт задач по интеграции, которые постоянно приходится решать. Дайте нам то, что есть у всех — а потом уже играйтесь со своими джавами и питонами:)
Так как 1С всегда целится на низкий порог вхождения, вполне понятны причины создания этого продукта.
Что касается интеграции есть же NativeAPI.
Что касается интеграции есть же NativeAPI.
Низкий уровень вхождения и знания C++, необходимые для написание внешних компонент на NativeAPI, как-то не очень сочетаются)))
NativeAPI для нестандартных выходящих за рамки задач, вполне себе решение, мы сами нанимали фрилансера C++ для таких задач, не имеет отношения к порогу вхождения.
C++/CLI очень легко позволяет сделать компоненту-розетку, в которую дальше втыкается весь мир .net
А уж vb.net — это тот же 1С, только на английском. Обучить 1Сника запросто. Единственное, C++/CLI не кроссплатформенный
Доступность websocket на клиенте позволила бы закрыть целый ряд интеграционных задач с внешними сервисами, которые уже реализуют websocket. Например: Slack, IP телефония, собственный сайт не на 1с.
А можно ли отправить сообщение в систему взаимодействия из стороннего приложения, не 1с?
Делаете в прикладном решении http/web сервис, который посылает ваше сообщение в систему взаимодействия.
Сейчас единственный способ аутентификации в системе — это через 1С. Сервер 1С: Предприятия проверяет права пользователя клиента 1С и выдает ему подписанный токен для входа, который клиент передает в систему взаимодействия.
Задача уже в работе, так что скоро будет можно. Это будет новый способ аутентификации и/или вебхуки. Мы собираем сценарии, так что если поделитесь своим (здесь в комментариях или мне в личные сообщения), то мы убедимся, что новый функционал подойдет для решения вашей задачи.
Задача уже в работе, так что скоро будет можно. Это будет новый способ аутентификации и/или вебхуки. Мы собираем сценарии, так что если поделитесь своим (здесь в комментариях или мне в личные сообщения), то мы убедимся, что новый функционал подойдет для решения вашей задачи.
А во тут поподробнее… т.е. on-primise СВ подключается к конкретной инфобазе 1С и обслуживается пользователей этой инфобазы? Можно зацепить несколько инфобаз? С разных серверов приложений?
PS
Почитал мануал на ИТС — за что вы так админов ненавидите все-таки?
PS
Почитал мануал на ИТС — за что вы так админов ненавидите все-таки?
Что читали и, если можно, в чем суть недовольства?
Только, если можно, конструктивно — чего не хватает и т.д.
Только, если можно, конструктивно — чего не хватает и т.д.
Вот это все. its.1c.ru/db/cs20#bookmark:cs:TI000000001
Претензии не к документации как таковой, а к тому что можно было сделать нормальный инсталлятор под Linux. Если уж душит жаба готовую виртуалку отдавать…
Претензии не к документации как таковой, а к тому что можно было сделать нормальный инсталлятор под Linux. Если уж душит жаба готовую виртуалку отдавать…
А меня больше волнует вопрос: почему пользователей ИТС так ненавидите? В интернете полно ссылок на ИТС-статьи (и сами представители 1С любят такие давать на партнерсе), но при попытке перейти на нее получаешь — «Доступ к данному материалу ограничен». Далее нужно менять домен с RU на UA и лишь после этого шаманства можно читать статью. Зачем? Ведь содержимое ИТС в технических разделах идентичное до последнего знака препинания. И сервер один и тот же, что позволяет авторизироваться на обоих порталах под одной учеткой.
Несколько баз можно зацепить через механизм совместного использования приложений
downloads.v8.1c.ru/content//Platform/8_3_13_1472/1cv8upd_8_3_13_1472.htm#7ab36123-0fe7-11e8-a3f7-0050569f678a
its.1c.ru/db/v8313doc#bookmark:dev:TI000002046
its.1c.ru/db/v8313doc#bookmark:adm:TI000000755
(инфа по ссылкам доступна только для подписчиков ИТС, сорри)
Совместное использование, например, дает возможность написать пользователю другой базы. Это все в 8.3.13.
Скорее, инфобаза 1С подключается к СВ, разные базы с разных серверов приложений могут подключаться к одной СВ
для использования механизма совместного использования базы нужно подключать, используя один email (чтобы они были в одном абоненте).
downloads.v8.1c.ru/content//Platform/8_3_13_1472/1cv8upd_8_3_13_1472.htm#7ab36123-0fe7-11e8-a3f7-0050569f678a
its.1c.ru/db/v8313doc#bookmark:dev:TI000002046
its.1c.ru/db/v8313doc#bookmark:adm:TI000000755
(инфа по ссылкам доступна только для подписчиков ИТС, сорри)
Совместное использование, например, дает возможность написать пользователю другой базы. Это все в 8.3.13.
СВ подключается к конкретной инфобазе 1С и обслуживается пользователей этой инфобазы?
Скорее, инфобаза 1С подключается к СВ, разные базы с разных серверов приложений могут подключаться к одной СВ
для использования механизма совместного использования базы нужно подключать, используя один email (чтобы они были в одном абоненте).
«используя один email (чтобы они были в одном абоненте).» Вы сейчас про Fresh? Я про on-primise… У меня 3 базы, NTLM авторизация, каждый юзер «де-факто» имеет по пользователю в каждой базе… Я с этим в СВ взлечу?
Каждый юзер имеет по пользователю в каждой базе
Возможно, тут понадобится включить «сопоставление пользователей» — это такой способ сказать Системе Взаимодействия, что это один и тот же пользователь в каждой ИБ; сопоставлять можно по имени, по полному имени и по ключу соответствия, который администратор ИБ может задавать сам для пользователей.
В деталях все описано в документации, ссылки я приводил выше.
Но даже если сопоставление не включить, то все будет работать, просто будет по три копии каждого пользователя.
Обожаю статьи от PeterG :-) Каждый раз что-то новое и каждый раз впечатление что где-то в мире есть 2 разных фирмы 1С — в одной крутые продвинутые ребята, которые в курсе всех современных технологий разработки, а в другой какие-то… вредители.
Павел! Вы с 2015 года знаете про Elastic! Так какого… лешего мы до сих пор смотрим журнал регистраций и технологический журнал руками или через убогую встроенную в 1С клиента гляделку? Так тяжело сделать нативную нормальную выгрузку в «ёлку»? Чтобы админы не мучились с многочисленными костылями, Лустин не троллил «одинэсников» профнепригодностью из-за неумения срастить 1С и Elastic, а курс молодого бойца для программера не начинался с фразы «и не вздумай искать по журналу регистрации не поставив фильтр по датам — завалишь сервак»?
PS
Впрочем приличные люди вместо предложения «потренировать скиллы в установки 1С rpm'ов» давно бы готовые образы виртуалок под вмваре и гипер-в раздавали бы уже…
Павел! Вы с 2015 года знаете про Elastic! Так какого… лешего мы до сих пор смотрим журнал регистраций и технологический журнал руками или через убогую встроенную в 1С клиента гляделку? Так тяжело сделать нативную нормальную выгрузку в «ёлку»? Чтобы админы не мучились с многочисленными костылями, Лустин не троллил «одинэсников» профнепригодностью из-за неумения срастить 1С и Elastic, а курс молодого бойца для программера не начинался с фразы «и не вздумай искать по журналу регистрации не поставив фильтр по датам — завалишь сервак»?
PS
Впрочем приличные люди вместо предложения «потренировать скиллы в установки 1С rpm'ов» давно бы готовые образы виртуалок под вмваре и гипер-в раздавали бы уже…
Это можно продолжать до бесконечности. С одной стороны они поняли что конфигуратор никуда не годится, а с другой — начали перепиливать Эклипс!!! в надежде сделать из него новый конфигуратор. Эти же люди реализуют в 1С на уровне платформы систему расчета СЛАУ, но не могут сделать вебсокеты. Эти же люди придумывают "1С: Центр администрирования " на платформе 1С, но заставляют для него писать скрипты на Python. Все ну никак не складывается какого-то общего направления развития:)
Эти же люди придумывают «1С: Центр администрирования » на платформе 1С, но заставляют для него писать скрипты на Python. Все ну никак не складывается какого-то общего направления развития:)
Мне кажется разработчикам самим не нравится их платформа, поэтому они всё чаще обращаются к сторонним разработкам. Казалось бы, развивайте встроенный язык, создавайте экосистему. 1С как платформа — отличное решение для несложных систем учёта. Но язык 1С не только жутко ограничен в возможностях, но ещё и очень медленный.
Факт, что «вебсокеты» для 1с написаны на java исчерпывающе описывает отношение разработчиков к языку 1с, imho.
Мне кажется разработчикам самим не нравится их платформа, поэтому они всё чаще обращаются к сторонним разработкам.
Давайте все же разделять понятия.
Платформа — это набор софта для разработки и функционирования бизнес-приложений. Грубо говоря — это:
- Инструменты разработки
- Конфигуратор, написан на С++ или
- EDT, написан на Java
- Среда выполнения (runtime)
- Сервер приложений (С++)
- Тонкий (исполняемый) клиент, С++
- Веб-клиент (JavaScript)
- Прочее (например, инструменты администрирования, и, в том числе, Система Взаимодействия)
Бизнес-приложения пишутся на языке 1С, компоненты платформы – на тех средствах разработки, которые подходят для решения задач наилучшим образом.
1С как платформа — отличное решение для несложных систем учёта.
А еще, например, для написания ERP, успешно конкурирующей с другими лидерами рынка:
Ну и вообще.
Факт, что «вебсокеты» для 1с написаны на java исчерпывающе описывает отношение разработчиков к языку 1с, imho.
Ваше утверждение звучит примерно как «Факт, что НТТР-сервисы реализованы в платформе на C++, исчерпывающе описывает отношение разработчиков к языку 1С».
Повторюсь, бизнес-приложения пишутся на языке 1С, сама платформа (которая предоставляет те или иные возможности для разработки бизнес-приложений на языке 1С) – на тех средствах разработки, которые подходят для решения задач наилучшим образом.
Язык разработки 1С не предназначен для решения низкоуровневых задач типа реализации сокетов. Он предназначен для решения бизнес-задач. Платформа реализовала Систему Взаимодействия на тех средствах, которые подошли, с нашей точки зрения, лучше всего (Java, Hazelcast, Elasticsearch, Postgres) и сделала ее доступной в среде разработки 1С (объект СистемаВзаимодействия и т.д.)
Но веб-сервисы и http-сервисы — часть платформы, несмотря на то, что их удобнее было реализовать на PHP и JS. С тем же успехом можно утверждать, что для решения таких низкоуровневых задач язык 1С не предназначен.
Я могу написать сайт на 1С. Не знаю, насколько это полезно, но несколько лет назад у меня не было такой возможности.
Я расстроен от того, что вместо развития языка и платформы представлена «надстройка», которую, в принципе, можно было сделать и внешней компонентой. СВ — это же первый «компонент системы», требующий отдельную СУБД?
Я могу написать сайт на 1С. Не знаю, насколько это полезно, но несколько лет назад у меня не было такой возможности.
Я расстроен от того, что вместо развития языка и платформы представлена «надстройка», которую, в принципе, можно было сделать и внешней компонентой. СВ — это же первый «компонент системы», требующий отдельную СУБД?
Но веб-сервисы и http-сервисы — часть платформы
СВ — тоже часть платформы (только опциональная), объектная модель СВ доступна в языке 1С.
Я расстроен от того, что вместо развития языка и платформы представлена «надстройка», которую, в принципе, можно было сделать и внешней компонентой.
Не расстраивайтесь :)
Веб-сервисы и http-сервисы тоже при желании можно, наверное, сделать внешней компонентой. И что?
СВ — это же первый «компонент системы», требующий отдельную СУБД?
Насколько помню — да.
Отдельная БД для СВ нужна, в частности, потому что:
- При интенсивном обмене сообщениями размер СУБД и нагрузка на нее скажется на быстродействии инфобазы
- Есть возможность обмена сообщениями между разными инфобазами, поэтому целесообразнее хранить сообщения в отдельной СУБД, а не делить их между инфобазами (а также не хранить полные копии всех сообщений в каждой инфобазе)
Трудно не расстраиваться когда успел попробовать вкусностей из других фреймворков и языков.)
вкусностей из других фреймворков и языков
«Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча» (ц) Гоголь
Ну а если серьезно — да, в других языках и фреймворках есть немало хорошего, что, возможно, пригодилось бы в разработке приложений на 1С. У нас длинный список кандидатов на реализацию. Реализуем потихоньку, вот до СВ добрались.
Интересно, в этом списке есть вещи вроде тайп хинтинга или чего то подобного, замыканий, работы с коллекциями в стиле Коллекция.ДляКаждого(Функция).Где(Функция2) и т.п. улучшений языка?
Действительно интересно, без сарказма. Заодно замыкания бы позволили структурам поведение добавлять, чего бывает не хватает.
Действительно интересно, без сарказма. Заодно замыкания бы позволили структурам поведение добавлять, чего бывает не хватает.
Если очень уж интересно, откликайтесь на заявки хендхантеров из 1С, изучите бэклог, увольтесь по результатам испытательного срока — минимум действий, а получите инсайды настолько секретные, что их запрещено разглашать на ежегодных встречах в Космосе (содержимое которых тоже запрещено разглашать)
А вы не хотели бы поделиться этим списком с остальными разработчиками, чтобы они помогли вам расставить приоритеты? ))
Мне кажется, мнение разработчиков, которым остро необходимы те или иные инструменты в системе 1С помогло бы вам улучшить систему, и удовлетворенность системой.
Мне кажется, мнение разработчиков, которым остро необходимы те или иные инструменты в системе 1С помогло бы вам улучшить систему, и удовлетворенность системой.
Насколько помню — да.
А как же журнал регистрации на SQLite?
Павел, ну мы же тут не дети и понимает что главное конкурентное преимущество 1С при внедрение ERP это цена. По нынешнем временам на SAP деньги остались только у Роснефти :-). А второе — это конечно огромное коммьюнити (то бишь программеров). С котором кроме лично вас (за что вам отдельное спасибо) в компании 1С никто не работает.
PS
Так когда нам ждать сервер консолидации журналов регистрации на Эластике?
PS
Так когда нам ждать сервер консолидации журналов регистрации на Эластике?
видимо пока никто в открытый доступ не выложит свои наработки ( да хотя бы конфиг для filebeat) не будет движения.
Павел
Меня зовут Петр :)
главное конкурентное преимущество 1С при внедрение ERP это цена.
Низкая по сравнению с конкурентами цена — лишь один из факторов (цена, кстати, низкая во многом из-за удачного выбора модели разработки, позволяющего создавать решения на платформе 1С на порядок быстрее, чем на конкурирующих платформах). Ну и не будем забывать, что если бы функциональность продукта была ощутимо беднее, чем у конкурентов — выбрали бы конкурентов.
А второе — это конечно огромное коммьюнити (то бишь программеров).
Ну вот оно огромное в частности из-за удачной модели разработки.
С котором кроме лично вас (за что вам отдельное спасибо) в компании 1С никто не работает.
Всегда пожалуйста :)
Жаль, конечно, что складывается впечатление, будто я один работаю с коммьюнити. Будем исправляться.
Так когда нам ждать сервер консолидации журналов регистрации на Эластике?
Пока не готов ответить, к сожалению.
>Вы с 2015 года знаете про Elastic! Так какого… лешего мы до сих пор смотрим журнал регистраций и технологический журнал руками или через убогую встроенную в 1С клиента гляделку
Нуралиев год назад на открытом воскресенье говорил, что пока рассматривать какое-то более серьезное хранилище под чем текстовые файлы под ЖР не хотят. Не забывайте, что у 1С существенная доля пользователей до сих пор работают с базами в файловом режиме и им этот хайтек ни разу не нужен.
Нуралиев год назад на открытом воскресенье говорил, что пока рассматривать какое-то более серьезное хранилище под чем текстовые файлы под ЖР не хотят. Не забывайте, что у 1С существенная доля пользователей до сих пор работают с базами в файловом режиме и им этот хайтек ни разу не нужен.
Подскажите, реализована ли уже система взаимодействия на мобильной платформе? Если нет, то когда планируется?
Система Взаимодействия реализована на мобильном клиенте.
Каждый раз читаю такие статьи и каждый раз думаю (по другим комментариям видно что не только я) — тут такие клевые технологии используют, но при этом не могут сделать такой элементарщины как логи в скуль, нормальные web-socket, работу с гит нативную… У меня реально ощущение что люди живут в другой вселенной :((((( а самое обидное что об этом просят уже годы, и такое ощущение что к сообществу относяться как к отбросам — хотите? Хрен когда получите…
И я уже молчу про отладку, мониторинг и прочее… Зато мы сделали чатик внутри 1С!!! Это киллекфича!!!
P.S.
Не рассказывайте мне пожалуйста что логи в скуль это нереально. В sqllite сделали же, почему нельзя просто дать возможность выбора куда писать.
И я уже молчу про отладку, мониторинг и прочее… Зато мы сделали чатик внутри 1С!!! Это киллекфича!!!
P.S.
Не рассказывайте мне пожалуйста что логи в скуль это нереально. В sqllite сделали же, почему нельзя просто дать возможность выбора куда писать.
> У меня реально ощущение что люди живут в другой вселенной
1С действительно живут в другой, существенно более приближенной «к земле» вселенной. В которой большом количестве офисов попросту нет sql серверов. Да и серверов как таковых тоже, а в качестве сервера используется одна из рабочих станций (бухгалтера, например).
>sqllite сделали же
Сделали, да не взошло, так что теперь назад делают (см. downloads.v8.1c.ru/content//Platform/8_3_13_1198/1cv8upd_8_3_13_1198.htm#b398b60e-9891-11e7-a3f7-0050569f678a)
1С действительно живут в другой, существенно более приближенной «к земле» вселенной. В которой большом количестве офисов попросту нет sql серверов. Да и серверов как таковых тоже, а в качестве сервера используется одна из рабочих станций (бухгалтера, например).
>sqllite сделали же
Сделали, да не взошло, так что теперь назад делают (см. downloads.v8.1c.ru/content//Platform/8_3_13_1198/1cv8upd_8_3_13_1198.htm#b398b60e-9891-11e7-a3f7-0050569f678a)
>1С действительно живут в другой, существенно более приближенной «к земле» вселенной. В которой большом количестве офисов попросту нет sql серверов. Да и серверов как таковых тоже, а в качестве сервера используется одна из рабочих станций (бухгалтера, например).
нет, все-таки другая вселенная. Для описанных вами компаний сейчас очень активно развиваются облачные сервисы, которые гораздо более выгодные. А там, где покрупнее уже и скуль есть, и отдельная машина под 1С
нет, все-таки другая вселенная. Для описанных вами компаний сейчас очень активно развиваются облачные сервисы, которые гораздо более выгодные. А там, где покрупнее уже и скуль есть, и отдельная машина под 1С
Кажется вы переоцениваете степень доверчивости наших коммерсов. Свои сокровенные (и не всегда отражающие юридическую реальность, скажем так) данные в облако? И ни в какое-нить импортное, а в наше, родное, с доступом т-ща майора/налоговика/пожарника. Серьезно?
Оф. бухгалтерию в облако еще куда ни шло, но опер/упр. учёт? Серьезно? :)
Страшно далеки вы от народа
Оф. бухгалтерию в облако еще куда ни шло, но опер/упр. учёт? Серьезно? :)
Страшно далеки вы от народа
UFO just landed and posted this here
Касаемо логов в скуль, наверное слишком все сложно, но вот писать их в обычный текстовый файл (без развеселых скобочек) и выдать описание полей (хотя уже умельцы разобрались) можно было бы.
Но тогда любой несертифицированный специалист сможет эти логи хоть куда отправлять. А это может повлиять на всю экосистему 1С.
Но тогда любой несертифицированный специалист сможет эти логи хоть куда отправлять. А это может повлиять на всю экосистему 1С.
да, согласен, исчезнут сотни «интеграторов» которые на этой закрытости делают кучу бабла. Я вот тут с коллегами инженерами 3 недели сидел, пока мы прикрутили мониторинг сессий и блокировок из 1С в заббикс. Работает по итогу очень даже неплохо, но для того, чтобы понять как это сделать я год по крупицам собирал инфу. То там обрывок, то тут кусочек… Почему блин нельзя это отдавать по какому-нибудь урлу в виде json? или xml?
Но я все-таки надеюсь что коллеги прислушаются к обществу и заведут у себя голосовалку за фичи как МС. И начнут их делать.
А то эта статья, как я уже и говорил, кажется каким-то плевком в лицо сообщества… =(
Но я все-таки надеюсь что коллеги прислушаются к обществу и заведут у себя голосовалку за фичи как МС. И начнут их делать.
А то эта статья, как я уже и говорил, кажется каким-то плевком в лицо сообщества… =(
а планируете выложить эту систему в общий доступ?
так там же есть интерфейс на java и из утилиты командной строки. причем документация из командной строки по ключу /help вполне адекватная
Там же — это где? Можно линки?
https://its.1c.ru/db/v8312doc#bookmark:cs:TI000000189 — спец приблуда для администрирования кластера из командной строки, ставится как сервис параллельно с сервером 1с + её консольный клиент
its.1c.ru/db/metod8dev/content/4985/hdoc — интерфейс на java для этой приблуды
its.1c.ru/db/metod8dev/content/4985/hdoc — интерфейс на java для этой приблуды
> исчезнут сотни «интеграторов»
У вас причинное-следственная связь нарушена :)
Эта куча интеграторов — одна из основ бизнеса 1С. Без них бизнес-модель 1Са не будет работать.
> которые на этой закрытости делают кучу бабла
Деньги партнеры делают на лицензиях/программировании/консалтинге. О какой закрытости речь? Любой желающий может купить, например, технологическую поставку (https://rarus.ru/1c8/1c-predpriyatie-8-3-tehnologicheskaya-postavka/) для освоения и даже коммерческого использования платформы.
Примерно такой же подход у эппл (https://en.wikipedia.org/wiki/Mac_Developer_Program).
У вас причинное-следственная связь нарушена :)
Эта куча интеграторов — одна из основ бизнеса 1С. Без них бизнес-модель 1Са не будет работать.
> которые на этой закрытости делают кучу бабла
Деньги партнеры делают на лицензиях/программировании/консалтинге. О какой закрытости речь? Любой желающий может купить, например, технологическую поставку (https://rarus.ru/1c8/1c-predpriyatie-8-3-tehnologicheskaya-postavka/) для освоения и даже коммерческого использования платформы.
Примерно такой же подход у эппл (https://en.wikipedia.org/wiki/Mac_Developer_Program).
В личке aavolkov задал ряд инетресных вопросов, переношу сюда вместе с ответами.
RabbitMQ прекрасен, и мы много его используем в других проектах. Если бы мы делали отдельно чат и отдельно механизм publish-subscribe, второй совершенно точно делали бы через rabbitMQ (и AMQP в платформе). Но нужен был чат и транспорт два в одном. Для чата в качестве клиента помимо 1С: Предприятия ожидался сайт и standalone-приложение, так что вебсокет показался удобнее. А вебсокет в rabbitmq на тот момент (2014-2015 год) то ли не вызвал большого доверия, то ли не существовал. Возможен еще один вариант — не влез в osgi. Иногда даже у библиотек с заявленной поддержкой osgi по факту она реализована плохо и требует допиливания. Может быть, мы вообще забыли включить его в сравнение, потому что он был не очень на слуху. Не хочу вас обманывать, про тогда не скажу, сейчас обязательно рассмотрели бы такой вариант. Может, еще и рассмотрим в будущем.
Мы индексируем сообщения в ES, но пока не успели поддержать поиск сообщений/наименований_форм на уровне встроенного языка.
Думаю, тут опять же вопрос других клиентов — в 1С вы, конечно, можете хранить, но что делать остальным клиентам? Про unread_conversation вы совершенно верно заметили, это для того, чтобы снимать непрочитанность для каждого пользователя в отдельности. Также у нас есть место, где хранится ID и дата последнего прочитанного сообщения — таблица conversation_user (last_read_message_at, last_read_message_id). Но да, это снова на сервере.
Сейчас никак, но мы сами редко на уровне ИБ и удаляем пользователей по-настоящему. Обычно прибавляем к нему «ув.» и оставляем в таком виде. Так повелось задолго до системы взаимодействия, так что у нас проблема так остро не стоит. Но, наверное, дать такую возможность было бы неплохо, согласен с вами.
Я не совсем понял этот сценарий, вы написали
Так вы его прочитали или нет?
Смотрите, модель такая: оповещения приходят тем, кто онлайн.
Если пользователь оффлайн, то при старте он запросит обновления по таблице unread_conversation (это не оповещения — попадают ли они тут в обработчик я не подскажу). Для чтения есть параметр visible, если клиент передает его равным true, то из unread_conversation приедут только видимые обсуждения. Что из этого выведено в язык тоже, к сожалению, подсказать не могу (но могут на v8).
aavolkov — спасибо за хорошие сложные вдумчивые вопросы!
ВОПРОС: Первый вопрос (архитектурный): почему не очередь сообщений типа RabbitMQ? Там же адресная доставка, масштабируемость, нагрузки и прочее реализованы из коробки. Нужно всего-лишь прикрутить «воркер» к платформе и всё будет работать, да и на «плюсах» эти воркеры, конечно, есть. К тому-же RabbitMQ запилен на Erlang-е, который очень бережно относится к потокам (тредам) и прочему (типа распределения нагрузки, мониторинга состояния процессов), чего нельзя сказать о том-же самом в Java (без методичной настройки снаружи и педантичного многопоточного ковыряния внутри).
RabbitMQ прекрасен, и мы много его используем в других проектах. Если бы мы делали отдельно чат и отдельно механизм publish-subscribe, второй совершенно точно делали бы через rabbitMQ (и AMQP в платформе). Но нужен был чат и транспорт два в одном. Для чата в качестве клиента помимо 1С: Предприятия ожидался сайт и standalone-приложение, так что вебсокет показался удобнее. А вебсокет в rabbitmq на тот момент (2014-2015 год) то ли не вызвал большого доверия, то ли не существовал. Возможен еще один вариант — не влез в osgi. Иногда даже у библиотек с заявленной поддержкой osgi по факту она реализована плохо и требует допиливания. Может быть, мы вообще забыли включить его в сравнение, потому что он был не очень на слуху. Не хочу вас обманывать, про тогда не скажу, сейчас обязательно рассмотрели бы такой вариант. Может, еще и рассмотрим в будущем.
ВОПРОС: Если есть ElasticSearch, то почему нет возможности выбрать сообщения поиском из встроенного языка платформы (8.3.12 и 3.0.6)?
Мы индексируем сообщения в ES, но пока не успели поддержать поиск сообщений/наименований_форм на уровне встроенного языка.
ВОПРОС: Почему при создании обсуждения с единственным участником «все пользователи» и отсылки в это обсуждение сообщения — в БД СВ (postresql) сообщения регистрируются к доставке «всем» и «каждому пользователю» в отдельности (я сужу по таблице «unread_conversation»)? Я конечно, понимаю, что нужно удалять прочитанные «уведомления» для каждого конкретного пользователя, но может инфу о том, что конкретный пользователь прочёл сообщение хранить в самой БД 1С с возможностью управления этим параметром (типа, пометить сообщения с такой-то даты непрочтёнными или прочтёнными, как в почте)?
Думаю, тут опять же вопрос других клиентов — в 1С вы, конечно, можете хранить, но что делать остальным клиентам? Про unread_conversation вы совершенно верно заметили, это для того, чтобы снимать непрочитанность для каждого пользователя в отдельности. Также у нас есть место, где хранится ID и дата последнего прочитанного сообщения — таблица conversation_user (last_read_message_at, last_read_message_id). Но да, это снова на сервере.
ВОПРОС: (он вытек из третьего, когда я копал): Как удалить пользователя из СВ, который был физически удалён из базы данных 1С (напомню, 8.3.12 и 3.0.6), т.е. пользователь, при удалении из БД 1С, автоматом не удаляется из БД СВ и нет какой-то функции, которую бы можно было вызвать из языка платформы.
Сейчас никак, но мы сами редко на уровне ИБ и удаляем пользователей по-настоящему. Обычно прибавляем к нему «ув.» и оставляем в таком виде. Так повелось задолго до системы взаимодействия, так что у нас проблема так остро не стоит. Но, наверное, дать такую возможность было бы неплохо, согласен с вами.
ВОПРОС: я не могу понять — если сообщение обсуждения создавать во вкладке «Обсуждения», то адресат, пока не прочитает эти сообщения, будет каждый раз получать их при входе в «1С» (в виде уведомлений внизу экрана).
Если же неконтекстное сообщение создать (послать) и прочитать программно (обсуждение с признаком «Отображение = ложь», чтобы их визуально не отображать, конечно), то факт получения сообщения обработчиком новых сообщений уже считает сообщение прочтённым, хотя по бизнесу — оно может требовать реакции пользователя и, пока пользователь не отреагировал (даже между сеансами) — сообщение должно быть непрочтённым. То есть, правильно ли я понял, что управления прочтённостьюсообщений в языке платформы нет?
Я не совсем понял этот сценарий, вы написали
сообщение создать (послать) и прочитать программно
Так вы его прочитали или нет?
Смотрите, модель такая: оповещения приходят тем, кто онлайн.
Если пользователь оффлайн, то при старте он запросит обновления по таблице unread_conversation (это не оповещения — попадают ли они тут в обработчик я не подскажу). Для чтения есть параметр visible, если клиент передает его равным true, то из unread_conversation приедут только видимые обсуждения. Что из этого выведено в язык тоже, к сожалению, подсказать не могу (но могут на v8).
aavolkov — спасибо за хорошие сложные вдумчивые вопросы!
Продолжаем отвечать на вопросы aavolkov.
По срокам сказать не смогу, но такая цель перед нами ставилась с самого начала, так что это должно случиться.
Если я правильно понял сценарий, то мы на сервере это не делаем (обсуждение не пропадет из таблицы unread, пока пользователь/код не вызовут setLastReadMessageId). Возможно, это уже при вызове из языка делается. Надо у команды тонкого клиента спросить.
В таком виде не проводились, но идея хорошая, спасибо! Мы делаем нагрузочное тестирование, но с упором на интерактивные сценарии. Также стараемся мониторить отзывчивость системы в production и оперативно что-то доделывать, когда видим появление узких мест. Но самому интересно провести такой тест.
Основная идея теперь понятна — сервер взаимодействия разрабатывается, как некая готовая архитектура коммуникации для различных платформ, что, конечно, предполагает открытый API. В виду его закрытости и достаточно плотной интеграции с некоторыми объектами платформы 1С, я грешным делом, подумал, что эта история будет работать только из 1С-ных решений (конкретная ЦА, если угодно). Значит, ждём открытого API?)
По срокам сказать не смогу, но такая цель перед нами ставилась с самого начала, так что это должно случиться.
Немного поясню о моменте с «прочтеностью». Если создать сообщение на вкладке «обсуждения» и отослать его пользователю, то получатель, находящийся в онлайн, получит уведомление (внизу экрана), но, если он не прочтёт сообщение (визуально текст сообщения НЕ будет отображен ему на вкладке «обсуждения») и закроет сеанс 1С, то, при следующем старте сеанса — он снова получит это уведомление (внизу экрана). То есть, технически, это сообщение не удаляется из таблицы «unreaded» пока пользователь его не увидит глазами.
Если я правильно понял сценарий, то мы на сервере это не делаем (обсуждение не пропадет из таблицы unread, пока пользователь/код не вызовут setLastReadMessageId). Возможно, это уже при вызове из языка делается. Надо у команды тонкого клиента спросить.
Если же я программно (кодом в 1С) создам техническое/неконтекстное сообщение на источнике (например, уведомление о критическом изменении курса валютной пары, которое пользователь-приемник должен увидеть в отдельной форме с графиками и прочей аналитикой, эту форму пользователь должен открыть нажатием кнопки на начальной странице (логично, что это кнопка должна «покраснеть»)), то на приемнике:
Я программно (кодом) подписываюсь на событие нового сообщения нужного обсуждения/канала(«conversation»), получаю новое сообщение, когда нахожусь в онлайн, и делаю такие вещи, как: программное открытие уведомления внизу экрана, окрашивание кнопки открытия формы, проигрывание сигнала тревоги и т.п. прекрасные штуки. Но, если пользователь-приемник не проявил никакой реакциии и закрыл сеанс 1С, то, при следующем открытии сеанса 1С — приемник НЕ получуит это сообщение снова (в отличие от сценария доставки видимого сообщения на вкладке «Обсуждения»). Это произойдет потому, что строка доставки сообщения для пользователя удаляется из таблицы «unreaded» сразу в тот момент, когда отрабатывает подписка на получение новых сообщений.
Таким образом, возникает 2 различных поведения сервера взаимодействия по удалению признака необходимости оповещения приемника в зависимости от контекста процессинга сообщения. Иными словами появляется такой «условный» признак, как «прочтённость». И мне, например, бы очень хотелось этим признаком управлять в зависимости от того — завершён ли бизнес-процесс коммуникации (в моём примере — нажатие на красную кнопку) или нет.
И ещё один вопрос возник: проводились ли какие-либо синтетические тесты нагрузки СВ, т.е. где отправителем и приемником является некий «шустрый» многопоточный сервис (не 1С, видимо), чтобы протестировать скорость процессинга сообщений (например, количество полученных/доставленных сообщений в секунду в зависимости от количества источников/получателей). Ну, например, для http обычно проводят такие базовые тесты утилитой ab.
В таком виде не проводились, но идея хорошая, спасибо! Мы делаем нагрузочное тестирование, но с упором на интерактивные сценарии. Также стараемся мониторить отзывчивость системы в production и оперативно что-то доделывать, когда видим появление узких мест. Но самому интересно провести такой тест.
Добрый день.
Этот вопрос несколько раз уже задавали и несколько раз отвечали, но все равно непонятно. Очевидно, что чат между живыми пользователями 1с не может быть чересчур высоконагруженным, не миллионы же их. Тогда под какой практический пример разрабатывалась эта система? Возможно, станет понятнее, если привести несколько практических примеров?
Этот вопрос несколько раз уже задавали и несколько раз отвечали, но все равно непонятно. Очевидно, что чат между живыми пользователями 1с не может быть чересчур высоконагруженным, не миллионы же их. Тогда под какой практический пример разрабатывалась эта система? Возможно, станет понятнее, если привести несколько практических примеров?
Всего конечных пользователей продуктов 1С — более 5 миллионов. Понятно, что далеко не все из них пользуются Системой Взаимодействия, но по грубым оценкам, счет идет на десятки тысяч и количество пользователей растет.
А еще есть скрипты и боты, использующие Систему Взаимодействия для самых разных задач — извещений и уведомлений, обмена данными при интеграции и т.д. И они могут быть гораздо активнее людей-пользователей.
А еще есть скрипты и боты, использующие Систему Взаимодействия для самых разных задач — извещений и уведомлений, обмена данными при интеграции и т.д. И они могут быть гораздо активнее людей-пользователей.
Обмен данными при интеграции- это наверное проще делать через http сервис, чем через систему взаимодействия? Нам же в этом случае надо что- то сообщить серверу, а не сеансу? Я правильно понимаю, что единственное оставшееся применение- это чат между разными 1с? Но их вроде и так много, без 1с. Может быть есть конкретный понятный пример использования подсистемы, кроме дублирования whatsup? Прошу прощения за назойливость))
Вначале, очень скептически относились к чату внутри системы. Но на практике, оказалось удобно. Пример из недавнего проекта. Небольшая компания плотников/электриков. Работают по принципу планирования работ на неделю вперед. Создается и детализируется план, формируются задания рабочим, рабочие через телефоны подтверждают время, сформированное бригадиром. Система взаимодействия (СВ) используется для уведомления и коммуникации с бригадиром и руководителем проекта в контексте конкретного рабочего плана (документ в системе) или записи времени (завись в календаре). Например, в конце дня рабочий должен подтвердить часы, у него две функции – Confirm и Decline. Если он Decline – задается вопрос «почему?» и через СВ создается контекстное обсуждение с уведомлением бригадира. Тот в свою очередь открывает сообщение и видит контекст (клиент, проект, рабочий план и т.д.). Менеджер и другие полноправные пользователи всегда могут ознакомиться (при особой необходимости) с перепиской.
Что стоит отметить:
— У пользователя всё в одном месте, есть поиск, и что важно – контекст.
— Удобно программно формировать сообщения, не нужно продумывать интерфейс и сквозную систему оповещений и ссылок к объектам (например, если формировать письмами в html-телом)
— Если менеджер не за компьютером, он получит уведомление через мобильный клиент.
Из неудобств: при создании не контекстного обсуждения между двумя пользователями, хотят автоматическое формирование темы, типа Dima + Anthony
Что стоит отметить:
— У пользователя всё в одном месте, есть поиск, и что важно – контекст.
— Удобно программно формировать сообщения, не нужно продумывать интерфейс и сквозную систему оповещений и ссылок к объектам (например, если формировать письмами в html-телом)
— Если менеджер не за компьютером, он получит уведомление через мобильный клиент.
Из неудобств: при создании не контекстного обсуждения между двумя пользователями, хотят автоматическое формирование темы, типа Dima + Anthony
Я до сих пор скептически отношусь к чату внутри системы. По той простой причине, что на разработку адекватного чата люди тратят ресурсов больше, чем на весь 1с потрачено, ну или сопоставимо. Вашу задачу можно и нужно решать интегируясь с готовыми продуктами, а не пиля свой велосипед. Но, конечно же, клиент всегда прав, и если есть клиенты на чат и электронную почту внутри системы- почему нет. Я сторонник линукс вей, простые кирпичики, которые делают задачу хорошо. Но также понимаю, что нет правил без исключений, вероятно эта система- для таких исключений.
По той простой причине, что на разработку адекватного чата люди тратят ресурсов больше, чем на весь 1с потрачено
Но ведь это не совсем веская причина, я бы даже сказал, не обижайтесь, не очень профессионально. К сожалению, очень многие (и я не редко бываю в их числе) строят свой скептицизм именно на умозрительной оценке сущностей. При всех свестелках/перделках в широко распространенных чатах с миллиардными ценниками и невероятным технологиями (при этом, почему-то тот же скайп работает так себе), когда у вас есть проект, бюджет, реальные задачи, практический опыт и довольные пользователи, точка зрения меняется. Это я к тому, что лучше делать выводы на основании практического опыта своего или других в сфере применимости той или иной технологии.
del
Вот здесь есть про примеры использования СВ (помимо чатов):
youtu.be/R1qFuCd5dyo?t=1056
youtu.be/R1qFuCd5dyo?t=1056
А я уж думал в рамках программы «Не дадим СВ нищебродам у которых нет денег на 1C Корп» данное обсуждение уже закончилось :-) То при разговоре о готовой выгрузке журналов в ELK от 1С вспоминаем, что большинство пользователей 1С до сих пор в файловой сидит… А потом СВ отбираем у тех у кого только Проф версия платформы :-( Значить пользователей Корп версий все-таки достаточно, чтобы СВ только для них оставить.
Sign up to leave a comment.
Как и зачем мы написали высоконагруженный масштабируемый сервис для 1С: Предприятия: Java, PostgreSQL, Hazelcast