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

🚀 Как провести документ и не «повесить» интерфейс Серфил тут по одной конфигурации и наткнулся на интересный подход, которого раньше не встречал: проведение документа из формы запускается как длительная операция. ⏱️ В чём проблема? Полагаю, все знают, что документ, который проводится 20 секунд и дольше, — не самый удачный сценарий. Особенно в веб-клиенте, где требования к времени отклика выше, чем в тонком клиенте. Если серверный вызов выполняется слишком долго, соединение клиента с информационной базой может быть разорвано. В рекомендациях 1С приводятся примерно такие значения: • около 20 секунд — для большинства браузеров и веб-серверов; • около 8 секунд — для некоторых браузеров. Поэтому серверные вызовы, которые могут выполняться дольше 8 секунд, рекомендуется запускать асинхронно — через фоновое задание. А для конфигураций, работающих в модели сервиса через веб-клиент, требования ещё строже: отклик должен укладываться примерно в 2–3 секунды. ⚙️ И вот как это решили в конфигурации В форме документа стандартное проведение заменили запуском длительной операции. Документ проводится в фоне, а после завершения операции форма получает результат и обновляется. 🛠 Получается примерно такая схема: 1️⃣ Переопределяем стандартные команды формы: Записать, Провести и Провести и закрыть. 2️⃣ При выполнении команд Провести или Провести и закрыть сериализуем объект документа в двоичные данные и помещаем их во временное хранилище. 3️⃣ Передаём адрес временного хранилища в фоновое задание. Там восстанавливаем объект из двоичных данных и проводим его. 4️⃣ После завершения фонового задания возвращаем результат на клиент и при необходимости обновляем или закрываем форму. ✅ Что получаем в итоге? Пользователь не смотрит на зависший экран и может заняться чем-то ещё, пока документ проводится. ⚠️ Конечно, есть нюансы: нужно обработать ошибки проведения, защититься от повторного нажатия команды и правильно обновить состояние формы после завершения операции. Сам документ от этого быстрее проводиться не станет. Но для пользователя, особенно в веб-клиенте, работа будет выглядеть гораздо приятнее. До этого фоновые операции я обычно встречал в обработках и отчётах, при заполнении табличных частей, а вот проведение документа в фоне из формы увидел впервые. А вы встречали такой подход?

Использование ключевых слов "ОБЪЕДИНИТЬ" и "ОБЪЕДИНИТЬ ВСЕ" в запросах 🟡 В общем случае при объединении результатов нескольких запросов используйте ОБЪЕДИНИТЬ ВСЕ, а не ОБЪЕДИНИТЬ. 🟡 Исключение: ситуации, когда удаление дубликатов является обязательным условием корректного результата запроса. 🟡 Причина: ОБЪЕДИНИТЬ удаляет полностью одинаковые строки, и это требует дополнительного времени даже тогда, когда одинаковых строк заведомо быть не может. 🟡 Проверяйте соблюдение стандарта при доработках и перед выпуском релиза. #std434 https://v8std.ru/std/434/

https://habr.com/ru/articles/1068094/

1с. Комьюнити лицензия на macOS. Столкнулся еще раз. Думаю таки актуально. Удалить файлы предыдущих лицензий. Удалить 1cv8/1C/1Cv8/1cv8conn.pfl В терминале sudo /Applications/1cv8.localized/{Ваша версия}/1cv8.app/Contents/MacOS/1cv8 Если я правильно понимаю то приложение 1с по умолчанию не имеет доступа к папке с лицензиями. Далее получаем комьюнити как обычно. Profit!

Ограничения на использование вложенных запросов в условии соединения 🟡 Рекомендуемый подход - вынести вычисления во временную таблицу и затем соединять уже готовый результат. 🟡 Типовой проблемный сценарий: в условии соединения используется вложенный запрос, чтобы получить «срез последних» на конец предыдущего периода, причем для каждой номенклатуры период может отличаться. 🟡 Это может существенно замедлить запрос и в ряде случаев сделать его неработоспособным на отдельных СУБД. 🟡 Проверяйте соблюдение стандарта при доработках и перед выпуском релиза. #std656 https://v8std.ru/std/656/

Бил бы по рукам, да все линейки уже сломаны. Поговорим о запросах. Точнее о том, как их надо писать, если хотите довести коллег до состояния старого чайника, который давно не мыли. С накипью. 1️⃣ Тянуть данные через весь запрос. Если какое-то поле от ссылочного типа нужно в итоговом результате большого запроса, выберите его сразу, поместите во временную таблицу и перетаскивайте через каждое следующее использование - не дай бог к концу написания запроса забудется, какие именно поля нужны. А так - всегда перед глазами. 2️⃣Используйте для выражения замены в ЕСТЬNULL то, что может быть NULL или вообще вызвать ошибку. К примеру, надо получить цену из какого-то регистра. Но ведь по соединению может получится так, что цена не найдена. Что тогда говорит насмотренность в таком случае: для левых соединений с негарантированным результатом, то есть вообще для всех, надо использовать функцию ЕСТЬNULL(ДанныеРегистра.Цена, ВыражениеЗамены) Но тут пытливый мозг говорит: а почему 0? ведь если в регистре её нет, это не значит, что цены не существует, её же можно ещё рассчитать! И рождается великолепное ЕСТЬNULL(ДанныеРегистра.Цена, ДанныеДокумента.Сумма/ДанныеДокумента.Количество) Никаких проблем, ведь пользователи же всегда стабильны в своём поведении, а значит количество чего-то всегда будет больше нуля. Мы не будем проверять это отдельно, потому что это трата ресурсов, сравнение числа с нулем съедает их просто невероятно. 3️⃣Используйте ВЫБРАТЬ РАЗЛИЧНЫЕ чтобы скрыть тот факт, что Ваше соединение - говно. Вы же не дураки и знаете: если запрос возвращает несколько одинаковых записей, значит нужно выбрать только те, что уникальные. Не беда, что скля потратит ресурс сначала на лишнюю выборку, потом на удаление дублей. Мы ж как раз сэкономили на проверке количества. Да и в конце концов не бывает же такого, что пользователь захочет вывести ещё какое-нибудь дополнительное поле, особенно из тех, что будут отличаться. Правда ведь? 4️⃣Для получения актуальных сведений используйте соединение с таблицей регистра сведений, а не его среза последних. Особенно в формах списка. Нужно, чтобы пользователь сразу при открытии понимал, что у документа может быть несколько записей о статусе. Он, правда, сам этого не поймёт, но для этого есть же техподдержка, аналитики и тимлид. Они ему объяснят, что на самом деле сообщение "Обнаружено дублирование ключевых значений в колонках" - это не баг, а образовательная фича. А если всё таки идёте против своей природы и обращаетесь к срезу последних - ни в коем случае не покрывайте поля индекса полностью, это для слабаков! 5️⃣Чтобы упростить поиск условий в запросе с большим количеством временных таблиц, накладывайте их, условия, в конце. Нам не принципиальна выборка лишних данных. В конце концов, не мы же их тянем всё больше и больше с каждым соединением, а машина. А машина, как известно, надорваться не может. Зато все условия в одном месте и очень просто читаются. Профит! В общем, используйте сами и другим подскажите. Только не долго, новые линейки уже заказал. #медвежийкодстайл

Настройка параметров ibcmd в режиме replicate, а так же СУБД транслятора и СУБД приёмника для оптимальной скорости Казалось бы, миграция базы 1С с помощью ibcmd и так происходит очень быстро, гораздо быстрее чем выгрузка/загрузка dt. Но даже эту скорость можно существенно повысить и дальше расскажу как. Начнём с настроек параметров ibcmd в режиме replicate при сценарии миграции базы с MS SQL на PostgreSQL как самом распространённом: ▫️ Количество потоков чтения (--jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd. Несколько моментов, которые стоит учесть при подборе начального значения --jobs-count: 1. Утилита ibcmd ограничена одной NUMA, т.е. если у вас на сервере 48 ядер и 2 NUMA, то максимально утилита сможет занять только 48/2=24 ядра. 2. Это потоки на чтение, а есть же ещё и потоки на запись, поэтому для начала нужно поделить наши 24 ядра ещё на 2 и получим уже 12. 3. Поскольку это чтение, то точно имеет смысл включить параллелизм на MS SQL увеличив параметр MAXDOP. А вот насколько его увеличивать тут надо посчитать. Опять же, если у нас на сервере СУБД 96 ядер, а мы читаем в 12 потоков, то нужно 96/12=8. ▫️ Количество потоков записи (--target-jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd. Что нужно учесть при подборе параметра --target-jobs-count: 1 и 2 пункты те же самые что и у --jobs-count, т.е. в итоге получим 12 3. Поскольку это запись, то она всегда однопоточная на СУБД, но после записи у нас начнут создаваться индексы, а PostgreSQL нам позволяет распараллеливать именно эту операцию указывая параметр max_parallel_maintenance_workers (максимальное число рабочих процессов, для CREATE INDEX) и при этом не забываем что «сверху» число параллельных процессов ограничено параметром max_parallel_workers. Соответственно при 96 ядрах на СУБД PostgreSQL и 12 потоков записи у ibcmd нам можно указать 96/12= 8 у max_parallel_maintenance_workers и max_parallel_workers = 96. Так же будет очень полезно увеличить параметры work_mem (оперативная память на сеанс для операций ORDER BY) до 2-4 ГБ и maintenance_work_mem (Лимит памяти для CREATE INDEX) до 4-8 ГБ. Учитывая, что у нас 12 потоков, то 12*4*8 = 384ГБ и это может быть максимум 50% всей доступной оперативной памяти. ▫️ Количество строк в порции данных (--batch-size) Количество строк в порции данных, используемой при репликации таблицы. Значение по умолчанию: 10 000 Казалось бы, ну а тут то что ещё считать, 10 000 вроде должно хватить всем? Подбор этого параметра можно осуществить только тестами миграции и чтением лога PostgreSQL, в котором фиксируем операции длительнее 0,5 сек (log_min_duration_statement = 500ms) сравниваем скорость записи при умолчательном параметре 10 000, а затем увеличивая его на те же 10 000 пока скорость не начнёт падать. У нас на серверах этот параметр получился оптимальным по скорости при значении 50 000. ▫️ Объем пакета данных (в байтах) (--batch-data-size). Значение по умолчанию: 10 485 760. Ну и в целом похожий по смыслу на параметр --batch-size, только теперь в объёме памяти, а не количестве строк. Тут к сожалению, только подбор замером времени полной миграции при разных параметрах. Опять же у нас оптимальным вышло увеличение и этого параметра в 5 раз до значения 52 428 800. ❗️Напомню, что по моему убеждению большая у вас база или нет определяется не её размером, а размером тех. окна и успеваете ли вы в это тех. окно сделать нужные вам монопольные операции или нет. Миграция с СУБД на СУБД это одна из самых "больных" операций в части тех. окна и подбор параметров как ibcmd так и обоих, участвующих в этом процессе серверов СУБД может существенно и даже на порядок сократить это самое тех. окно. Ну и на всякий случай канал в MAX https://max.ru/explorer1c

Автоформатирование кода 1С Не все нарушения стандартов обязательно исправлять вручную. Обработка «Автоформатирование кода и локализация» умеет автоматически применять 34 преобразования: форматировать код, исправлять структуру модулей, комментарии, локализацию и другие элементы конфигурации. Мы сопоставили автозамены с конкретными пунктами стандартов. Теперь возле поддерживаемых пунктов отображается тег autoformat со ссылкой на инструкцию. В ней собраны: — получение обработки с ИТС; — пакетный запуск; — работа с файловой и серверной базой; — XML-выгрузка и проект EDT; — получение и фиксация изменений в хранилище; — настройка отбора стандартов и отдельных пунктов. Подробнее: https://v8std.ru/diagnostics/autoformat/

Давно искал плагин для EDT, который бы добавлял две простые кнопки на командную панель - включить фильтр по измененным объектам и фильтр по "избранному". В итоге сделал такой плагин сам. Он добавляет две эти кнопки + кнопку добавления объекта в избранное. Установить можно так: EDT Справка → Установить новое ПО, добавить репозиторий https://pavel-aparin.github.io/edt-favorites/ Замечания, пожелания - welcome

Использование Журнала регистрации 🟡 Не используйте выборки из журнала регистрации там, где критична высокая скорость. 🟡 Текст типа события должен быть локализуемым и задаваться на основном языке конфигурации. 🟡 Журнал регистрации хранит события, которые возникают в работе пользователей с информационной базой. 🟡 Одна запись журнала должна соответствовать одному событию. #std498 https://v8std.ru/std/498/

🐼 Материалы с митапа 1) Бот от Леши @demoHermesItsBot 2) Репо с практики Паши: https://github.com/korolevpavel/kung-fu-llm-wiki Промт: Установи мне https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f КУНГ-ФУ: Канал / Чат 👍