1С и AI, полезные инструменты и сервисы, стандарты и паттерны

🎹 Менеджер лицензий (rmlic.exe) в 8.5.4

Уж очень не хватало этой утилиты. Это шаг к более админскому подходу, а не просто раздаче лицензий платформой. Теперь лицензии можно в собственной утилите:
▪️ активировать
▪️ мониторить (свободные/занятые)
▪️ управлять централизованно

Лицензии можно получать через менеджер (в том числе для файловых баз):
▪️ локальные лицензии → выдаются на компьютер
▪️ сетевые/удалённые → на сеанс

Ограничивать выдачу по:
▪️ пространствам лицензирования
▪️ информационным базам
▪️ продуктам

Писать более умные механизмы автополучения лицензий в коде. Добавлены методы:
▪️ПолучитьДоступныеМенеджерыЛицензий()
▪️ПроверитьДоступностьМенеджераЛицензий()
▪️ПолучитьОтветЦентраЛицензирования()
И расширены:
▪️автоматическое получение лицензий
▪️работа с носителями

Новый глобальный объект МониторингЛицензий позволяет прямо из кода анализировать состояние лицензий.

Подписаться: TG | MAX

#Практика1С #ПримерКода1С #Релиз8_5наПроде

Когда проводить рефакторинг?

Никогда, если:
- Код не будет меняться. Например, в одноразовых обработках или устаревшем механизме
- Изменение ничего нового не дадут. Рефакторинг ради рефакторинга бесполезен. Важно, чтобы появлялось новое качество. Например, масштабирование станет проще или снизится сложность будущего изменения

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

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

До, если:
- Рефакторинг даст быстрый результат. Например, код станет понятнее или его будет проще менять
- Вы точно понимаете, что и как нужно сделать.

Катастрофическое падение скорости при обновлении

В последнее время флагманские конфигурации 1С выпустили достаточно «тяжёлые» обновления ERP, УХ, KA и т.д.

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

Мы в рамках инцидентов РКЛ уже несколько раз столкнулись с тем, что процесс этого монопольного обновления затягивается на несколько часов или даже суток!

Систематизация проблемы показала, что она существует только при использовании MS SQL и при этом полностью отсутствует на PostgreSQL и там этот этап проходит буквально за минуты.
Дальнейший анализ показал, что проблема возникает не всегда и не у всех – что с одной стороны сильно затрудняет её решение (так как по классике – такая же нога и не болит), с другой стороны есть что с чем сравнить (тех у кого быстро и тех у кого медленно, при сопоставимом количестве записей в регистрах – чтобы ощутить проблему, этих записей должны быть миллионы и десятки миллионов).

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

Тонкость регистрации изменений состоит в том, что сначала проверяется есть ли уже такие зарегистрированные изменения (на уровне СУБД это запрос SELECT), и если таковых нет, то происходит уже сама регистрация (на уровне СУБД это запрос INSERT).

И по Технологическому журналу 1С мы получали чудовищную деградацию скорости именно при SELECT, если по началу он длился тысячные доли секунды, то затем вырастал до десятков секунд.

Разбор плана запроса показал что статистика чудовищно ошибается в предположении сколько строк уже зарегистрировано, например статистика предполагает что их 638 шт, а по факту оказывается 3 564 175 шт.

А у тех у кого обновление было быстрым – статистика не ошибалась…

В итоге было обнаружено, что всему виной отключенный Автоматический расчёт статистики на базе (аналог autovacuum_analyze в PostgreSQL) – на картинке видно где это включается.

Причина отключения достаточно известна – есть прекрасная статья, конкретно отключение автообновление статистики начинается с заголовка «Нестандартные ожидания на блокировках».

Что делать?
❗️Выключать автообновление статистики нужно только если вы фиксируете ожидания с типом LCK_M_SCH_S.
Придётся теперь следить и за этим параметром, и включать автоматический расчёт статистики, если вы ожидаете огромный объём регистрации к изменению.
Ну а при обновлении конфигурации – нужно включать автоматический расчёт на постоянной основе, просто как часть процесса и только после окончании всех процессов обновления, в том числе и фоновых уже выключать автообновление статистики, если на вашей базе это необходимо.

https://v8std.ru/mcp/

Я тут докрутил mcp к базе стандартов.

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

Он по фрагменту кода находит применимые к нему стандарты

Получает стандарты в маркдауне чистом виде

По коду диагностик апк бсл и едт находит описание диагностики и пункт стандарта.

Ну и просто умеет искать по произвольным фразам стандарты)

Использование управляемого режима блокировки

🟡 В конфигурациях следует использовать управляемый режим блокировок (свойство конфигурации Режим управления блокировкой данных устанавливается в значение Управляемый) и учитывать его особенности.

🟡 Они связаны с особенностями механизмов блокировок в самой СУБД и с тем, что СУБД не учитывает физический смысл и структуру объектов метаданных 1С:Предприятия.

🟡 Одновременно могут возникать избыточные блокировки на уровне СУБД.

🟡 Проверяйте соблюдение стандарта при доработках и перед выпуском релиза.

#std460
https://v8std.ru/std/460/

Спроси меня правильно.

Казалось бы, что может быть проще, чем задать НОРМАЛЬНЫЙ вопрос пользователю? А вот оказывается, что для некоторых это сродни ракетостроению

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

⚠️В поле введены некорректные данные.

Варианты продолжения диалога

Продолжить ввод - Отменить ввод

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

И что тут не так?

Ну для начала — неинформативно. Так же, как и в случае с простым оповещением, информация - ключ к пониманию. Почему данные некорректны? Добавьте пояснение: Вы ввели лярд в поле, в котором максимальное допустимое значение - 1. Уже понятно и пользователю будет проще сориентироваться, что ему надо сделать.

Второе. Неоднозначность трактовки. По мне так Продолжить ввод означает Если нельзя, но очень хочется - то можно. То есть вроде как не лезет, но если поплевать и надавить - войдёт. Но по факту - нет. Меня просто вернёт обратно в место ввода. Где я опять нажму Enter - и опять попаду на тот же вопрос. Он даже не поинтересуется у меня не идиот ли я, если упорно пытаюсь ввести тоже самое кривое значение дважды😔

Суть в том, что в этой ситуации вопрос (а это вопрос, мы уже разобрались) - тут не нужен совсем. Нужно оповестить пользователя

Вы ввели некорректное значение. Введите число в пределах от 0 до 1.

И один вариант

ОК

Вообще у вопросов, которые мы задаём пользователю, есть два золотых правила

1️⃣Не используйте отрицание в вопросе. Тот самый недопарадокс

Вы не хотите?

Варианты ответа

Да, не хочу - Нет, не хочу

2️⃣Суммарно в вопросе и вариантах ответа слово "отмена" и однокоренные могут быть использованы ровно один раз.

Если Вы это сделаете, то есть вероятность: ногу Вам отгрызёт кровожадный лемминг. Отменить?

Варианты ответа

ОК-Отмена

Что произойдёт, если я нажму ОК? По идее — отмена. Но тогда зачем Отмена? Я отменяю отмену и ногу мне всё таки отгрызут? В общем, Отменить? + Отмена прям в топе неоднозначных трактовок.

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

Помним и про информативность - пользователь должен понимать, что именно поставило его перед столь сложным выбором.

Вы добавляете в геном лемминга безбашенность медоеда и клыки саблезубого тигра. Вырастить эту чудовищную тварь?

Варианты ответа

Да-Нет-Отмена

Вуаля! Пользователь сразу и однозначно понимает и какое критичное изменение происходит, и какая ветка процесса пойдет дальше в случае каждого из вариантов ответа
Да - изменение происходит, животное появляется
Нет - изменение происходит, животное не появляется, можно продолжить и добавить, предположим, ленивца - и хрен что эта тварь кому сделает, потому что лень
Отмена - изменение не происходит

Если действие уже выполнилось без возможности отката - не может быть и отмены.

Ну и небольшой чек-лист в конце
▪️Если вариант ответа только один, то это не вопрос - это оповещение. Если вариантов больше одного - должен быть и вопрос.
▪️Не используйте в вопросе усложнения

Где завтра взойдёт солнце?
Нажмите Да, если считаете, что на востоке
Нажмите Нет, если считаете, что на западе
Нажмите Отмена, если считаете, что оно не взойдёт

Если у Вас есть необходимость подобного описания вариантов - запилите отдельную форму, а не используйте платформенный механизм.
▪️Убедитесь, что Ваши вопросы или оповещения ни в каком сценарии не дублируются (предположим, вызываемыми платформой)

#медвежийкодстайл

Информирование пользователей

Грамотное общение с пользователем посредством интерфейса - это про умение продумывать сценарии, логику работы и формулировать мысли.

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

Давайте посмотрим на простом примере

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

Некорректная дата платежа

«Чё ты доебался?» - спросит кто-то, ведь понятно же, что накосячили в дате платежа. Ну ок. А в чём именно? Как исправить? Каким должно быть значение, чтобы всё прошло на ура?

Сравните.

Указанная дата платежа - 22.04.2026 - не совпадает с установленными платёжными периодами для <Организации>/<Контрагента>/<Типа операции>. Измените дату платежа таким образом, чтобы она совпадала с платёжным периодом. Ближайший доступный период 27-30.04.2026. Или измените статус платежа на «срочный»

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

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

На этой стадии ещё неплохо обеспечить согласованность интерфейса со сценарием исправления ошибки, создавайте у пользователя прямую связь с элементом интерфейса. Да, слово "изменить" - универсальное, но всё же
👉если для каждого статуса у вас предусмотрена собственная кнопка - используйте название этой кнопки (предположим, в информации для пользователя можно написать "или используйте опцию "срочный платёж")
👉если для изменения статуса используется чек-бокс, используйте глагол «установите»

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

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

Не вводите пользователя в заблуждение - очищайте историю сообщений.

Говорят, что лучшее сообщение об ошибке - его отсутствие. В том плане, что при проведении какой-либо операции можно исправлять ошибки автоматически.

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

При этом, если изменяемые по зависимости данные уже заполнены, пользователя лучше об этом информировать:
👉предупреждением до изменения, если данные объемные (таблицы)
👉если изменяемые по зависимости данные
▪️находятся в поле видения, но разнесены с изменяемыми пользователем — краткосрочным выделением цветом
▪️находятся вне видимости (на другой странице) —сообщением об изменении
👉сообщением о сбросе значений

Еще небольшой чек-лист:
▪️если сценарий подразумевает выполнение исчислимого количества операций в фоне - информируйте пользователя о ходе прогресс-баром
▪️если сценарий подразумевает выполнение в фоне — сообщайте об окончании процесса так, чтобы это было заметно из любой формы

ну наверное в
#медвежийкодстайл

Зацените какой прикол раскопал в платформе

Пытаюсь запустить сеанс 1С:Предприятие из конфигуратора, запущенного из EDT. Да, я знаю толк в матрёшках.э 😂
А оно не запускается с ошибкой:

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

А я как бы на 8.3.27.1859 и запускаю. Именно эта версия у меня обозначена в конфигураторе, эта же версия указана в EDT.
А ошибка есть.

Знаете в чём косяк? А в том, что в списке баз 1С для этой базы прописана другая версия. И EDT на эту настройку в списке баз кладёт болт и запускает конфигуратор версии, которая указана в EDT. А конфигуратор, запущенный на другой версии, как дурачок пытается выполнить это невыполнимое требование и запускает Предприятие на невалидной платформе.

Мммм, покупка нового кресла всё ближе и ближе...


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

🧩 Привилегированный общий модуль в расширениях

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

У привилегированного режима есть разные нюансы, например:
▪️не отключает RLS для некоторых видов объектов, включённый перед пакетным запросом с временными таблицами (8.3.11)
▪️мог вызвать падение СУБД (8.3.12)
▪️не срабатывает во внешних обработках (до сих пор):

УстановитьПривилегированныйРежим(Истина); // Отключаем проверку прав доступа

ПривилегированныйРежим() вернёт Ложь

Так вот, Dmitry Kinash поделился ещё одним непредсказуемым поведением платформы, дословно:

А вы знали, что если перехватывать в расширении процедуры из привилегированного модуля, то они выполняются в режиме без привилегий? Дело в том, что в общих модулях в расширениях не предусмотрели свойство "Привилегированный" (Privileged), а потому механизм расширений выполняет код как обычный. Если у вас далее по коду есть проверка привилегий и вы не хотите получить ошибку, то вам придется явно повысить привилегии:

#Insert
SetPrivilegedMode(True);
#EndInsert

Учитывайте данные нюансы при проектировании архитектуры.

#Практика1С #Лайфхак1Снику

🔥 Андрей Соколов: «Как съесть XML с JSON, и не поперхнуться»

Как правильно работать с XML и JSON в 1С-интеграциях? Андрей Соколов (ведущий разработчик KORUS Consulting) разобрал оба формата с нуля — и это настоящая кладезь практики:

▶️Что внутри:

🔵История форматов и модели данных
🔵Схемы и конвертация — от простого к сложному
🔵Потоковое чтение больших файлов без утечек памяти
🔵XDTO — когда нужен жёсткий контроль структуры
🔵Производительность и подводные камни, на которых ломаются интеграции
🔵И многое другое

▶️Кому будет полезно:

Всем, кто хотя бы раз мучился с парсингом XML или JSON в 1С. Особенно — тем, кто проектирует интеграции с внешними системами.

▶️Смотреть:

🔜 YouTube: https://youtu.be/o8ras_BflLk

➡️ ВКонтакте: https://vkvideo.ru/video-232435421_456239041

Ставьте лайки, комментируйте, делитесь с коллегами — и следите за каналом: скоро выложу и другие доклады с Жёлтого клуба!

❓А какие темы интеграции вам были бы ещё интересны? Пишите в комментариях — соберём идеи для следующих встреч! 👇


#event@it_lunch

🔥 Подписывайся на IT Ланч!

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

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

НачатьТранзакцию() - счётчик 1
    НачатьТранзакцию() - счётчик 2
        НачатьТранзакцию() - счётчик 3

Всё это будет одна транзакция. На сервере приложений будет лишь увеличен счетчик количества транзакций. Фактически транзакция завершиться, когда вы напишите

ЗафиксироватьТранзацию() - счётчик 2
    ЗафиксироватьТранзацию() - счётчик 1
        ЗафиксироватьТранзацию() - счётчик 0 - транзакция фактически будет зафиксирована

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

 НачатьТранзакцию();
    Попытка  
        ДокументОбъект.Записать()  
        ЗафиксироватьТранзакцию();  
    Исключение  
        ОтменитьТранзакцию();  
        ВызватьИсключение;
    КонецПопытки;

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

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

Как вы думаете будет ли записан элемент ?

НачатьТранзакцию();

Попытка

  НовыйЭлемент = Справочники.Номенклатура.СоздатьЭлемент();
  НовыйЭлемент.Наименование = "Новый";
  НовыйЭлемент.Записать();

  ВызватьИсключение "Какая-то ошибка";

  ЗафиксироватьТранзакцию();

Исключение
  
КонецПопытки;

ЗафиксироватьТранзакцию();

Да, элемент будет записан. Но так делать не следует, это демонстрационный пример. Так как исключение не связано с базой данных, мы можем дальше продолжить работу с транзакцией. В случае, если в строке НовыйЭлемент.Записать() - у нас выпадет исключение, например перед записью сработала проверка, и мы установили "Отказ = Истина", то это будет расценено как ошибка при работе с базой данных, и соответственно будет являться "невосстановимой ошибкой". Транзакция будет помечена испорченной, и единственное, что мы должны сделать это отменить ее. Если мы дальше попробуем обратиться к базе данных, даже банально прочитать представление ссылки, то получим уже знакомую ошибку "В данной транзакции уже происходили ошибки".

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

НоменклатураОбъект = Справочники.Номенклатура.СоздатьЭлемент();  
НоменклатураОбъект.Наименование = "Тест1";  
НоменклатураОбъект.Записать();  
НачатьТранзакцию();  
НоменклатураОбъект.Наименование = "Тест2";  
НоменклатураОбъект.Записать();  
ОтменитьТранзакцию();  

Что выведут методы ?

Сообщить(НоменклатураОбъект.Наименование); 
Сообщить(НоменклатураОбъект.Ссылка.Наименование);

В нижеприведенном примере НоменклатураОбъект - объект в оперативной памяти. И после отмены транзакции данные в базу данных записаны не будут, но "Тест2" будет сохранен в оперативной памяти, и Сообщить(НоменклатураОбъект.Наименование); выведет "Тест2", а Сообщить(НоменклатураОбъект.Ссылка.Наименование); выведет "Тест1".

Отличная статья Андрея Овсянкина про транзакции на хабре.

РУБРИКА «ЧёПоСтандартам»
Имя, синоним, комментарий

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

#std474
...
Например, неправильно: «Загрузка данных из Эксель», «Загрузка данных из MS Excel»,
правильно: «Загрузка данных из Microsoft Excel».
....
1.5. При этом для стандартных реквизитов Родитель и Владелец, следует всегда указывать синонимы, отличные от синонимов по умолчанию. 

Для справочника Файлы: 
правильно
вложить в синоним прикладной смысл: «Папка» или «Папка с файлом».

Другой пример. В то время как для стандартного реквизита Наименование некоторых справочников может вполне подойти синоним по умолчанию «Наименование», в случае со справочником Файлы целесообразнее назначить синоним «Имя файла», а для справочника ФизическиеЛица – дать синоним «ФИО».

1.6. В случае, когда есть два (или более) объекта метаданных со схожим назначением, необходимо, чтобы синонимы каждого объекта полностью описывали каждый объект.

Например, неправильно давать справочникам следующие синонимы:
Банковские счета,
Банковские счета контрагентов

правильно:
Банковские счета организаций,
и Банковские счета контрагентов

2.3. Имена объектов метаданных не должны превышать 80 символов.

3.1. Комментарий задается только в тех случаях, когда необходимо дать участнику разработки конфигурации какие-либо пояснения по данному объекту конфигурации. Например, комментарий к реквизиту справочника может быть таким: "Индексирование поставлено для оптимизации отчетов с отбором по виду контрагента", или: "Используется в регламентированном учете".

4. В именах, синонимах и комментариях не допускается использовать букву "ё".

По пункту 1.5, а кто-то менял синоним у стандартного реквизита "Владелец"?) 💬

Ну и не забываем про поле "Комментарий" у объектов метаданных, практически никогда не встречал его заполнение, а иногда очень хотелось бы, чтобы там была важная информация, отвечающая на вопрос "нафига оно так?")

В дополнение к этому стандарту можно почитать #std468 Пользовательские представления объектов

P.S. Полное описание стандарта по ссылке в начале поста
#ЧёПоСтандартам #std474

Гайд для создания форм на 1С

Сейчас в разгаре обсуждение и внедрение нового интерфейса 8.5. Но это способ отображения, принципы построения интерфейса остаются прежними.

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

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

Предоставляются также примеры и антипримеры для наглядного понимания принципов построения формы

Как только сформируются основные подходы к интерфейсу 8.5 - актуализирую его. А пока с помощью него можете делать крутые приложения на интерфейсе Такси.

От вас требуется:
1. Поставить звездочку репозиторию Дизайн-гайд 1С
2. Поделиться с коллегой
3. По возможности, поддержать развитие гайда на boosty

Возвращаясь после долгого затишья, хочу поделиться с вами демо-версией моего нового проекта — идейного продолжения «Накидки». Это редактор конфигурации 1С.Предприятие в виде YAML, а также в ещё одном формате, близком к «Накидке».

Пока это очень ранняя версия: в ней реализована лишь базовая работа со справочниками и формами. Тем не менее, надеюсь, она позволит составить представление о том, какое решение я разрабатываю.

Буду рад обратной связи!

Ссылка на проект: https://github.com/crimsongoldteam/nkdk

Ниже прикладываю несколько коротких видео с демонстрацией работы.

Сегодня доделаны все стандарты с v8std

Сайт в десктопе улучшен

Добавлены диагностики от bslls, АПК и EDT с перекрестными ссылками на стандарты

Всем привет.

Редко сюда пишу, но сегодня реально есть что показать — наконец-то допинал до релиза свою интерпретацию консоли кода для 1С.

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

Что в итоге получилось:
• несколько режимов подсветки из коробки: BSL, запросы 1С, СКД, YAML, JSON и XML;
• автодополнение не только по самому языку, но и по метаданным конфигурации;
• возможность формировать свой контекст подсказок, например добавлять переменные, функции и поля структур;
• выполнение BSL-кода прямо из консоли;

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


Код конечно-же открыт:
https://github.com/Segate-ekb/code_editor

1️⃣🔤 Количество соединений на процесс

Есть такой параметр в свойствах Рабочего сервера 1С.
По умолчанию он равен 256, но в некоторых сценариях его необходимо менять и вот тут не всё так просто.

Кому можно менять этот параметр?
Всем, и ПРОФ и КОРП лицензии это позволяют (Многие путают этот параметр с параметром "Количество ИБ на процесс", вот он доступен только для КОРП)

Когда стоит менять этот параметр?

❗️Самый частый сценарий, это когда у вас на сервере 1С более одной NUMA-ноды.

Рабочий процесс работает только в рамках одной NUMA-ноды и если на сервере их 2, то мы получаем что сервер загружен максимум на 50% процессорной мощности, а при этом у пользователей ощущаются тормоза.

Распределением процессов по NUMA занимается операционная система и мы можем только увеличить вероятность равномерного распределения увеличив количество процессов.

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

Соответственно при 2х NUMA-нодах нам нужно обеспечить наличие минимум 4х Рабочих процессов при стандартной нагрузке на систему.

Практически единственный вариант это сделать – поменять количество соединений на процесс.

И вот тут начинаются тонкости:

1. Соединение не равно сеанс (рис. 1 и рис. 2). Т.е. ориентироваться на кол-во сеансов будет не совсем корректно, на рисунках мы видим что при 66 сеансах у нас 119 соединений
2. В свойствах Рабочего процесса есть поле «Соединений», на рис. 3 видим, что там 119 соединений, также, как и на рис. 2.
3. При этом в вычислении механикой Кластера 1С количества соединений для рабочего процесса НЕ учитываются соединения с номером 0

В нашем примере надо делить не 119 на 4, а 57 (именно столько соединений с ненулевым номером) и получим примерно 16.

❗️Менее частый сценарий - это когда количество соединений получается пограничное.
Т.е. у нас то чуть меньше 256, например 255 соединений, то чуть больше 256, например 259. Ну или чуть меньше и чуть больше текущего значения Количества соединений на процесс.

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

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

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

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

Имейте в виду эти тонкости при настройке своих серверов 1С для сбалансированной работы!