Комментарии 152
Тогда так. Вот было бы здорово, если бы функция «ПланыОбмена.ВыбратьИзменения» принимала максимальный размер выбираемой пачки. Не сразу всё, что там накопилось, а например пачичку в 100 штук. На следующей итерации – ещё 100 штук. И так далее. Она и отрабатывать будет быстрее, если изменений много образовалось. И блокировать будет недолго.
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
а запрос по изменениям с "первые н" не получается?
Снять с регистрации— возможна проблема, если выгрузка прервётся, а вся регистрация уже снята…
а запрос по изменениям с «первые н»не подходит
Я выгружаю в ТЗ «первые н».
Выгружаю это все в файл.
После закрытия прохожу и удалитьрегистрациюизменений.
удалитьрегистрациюизменений по обработанным в предыдущей пачке
В данный момент моему заказчику блокировки не мешают и он не готов на это потратить даже 8 часов, не говоря уже про 40.
Вы для анализа блокировок чем пользуетесь?
Да Вы гений. Наверное проверка синиаксиса тоже не нужна.
Вот прибегает к Вам человек, мол вот такая ошибка появляется при записи документа.
И на что Вы собрались беглый взгляд бросать? Обработчики записи формы документа? Модуля объекта? А если и там всё "чисто"?
не надо грузить обмены данных за квартал: снижается гранулярность до минут и секунд
Было бы неплохо. А ещё было бы неплохо, если бы обмен работал побыстрее.
Выборка изменений тормозит — выбирайте изменения по таблицам изменений.
С записью изменений проблем не видел.
С транспортом проблема? Есть отдельные системы для обеспечения гарантированного транспорта.
Так речь шла из одной типовой в другую. Это как бы уже готовое решение. Почему пользователь должен ещё что-то решать?
Тут можно только чаще делать обмен…
Попробуйте написать такой код, используя менеджер регистрации изменений. Получилось?
Теперь покажите пожалуйста всего одну строку — где удаляется регистрация изменений и чему у Вас равен номер сообщения?
Также удаление регистрации изменений можно выполнять не только по номерам сообщений, но и по массиву данных, по которым требуется удалить регистрацию. И, с учетом корректно сформированного массива, для этого также потребуется всего одна строчка кода. Таблицы изменений, номера сообщений, регистрация изменений это абстракция платформы которая упрощает работу с механизмом, но если эта реализация вас не устраивает всегда можно реализовать свой механизм обмена, не используя типовые механизмы или используя их частично.
Также, для высоконагруженных систем или если производительность работы объектов платформы недостаточна для нужного процесса, всегда можно спуститься до уровня базы данных и решить задачу прямой записью в СУБД — это позволяет решить все возникающие проблемы с производительностью обмена.
Для меня, средств программного комплекса 1С-SQL, достаточно для решения любых вопросов с обменом.
всегда можно спуститься до уровня базыправда лицензионное соглашение прямо запрещает это
1С, мне кажется, больше заботит попытка прямой записи в базу.
Компания софтпоинт использует решения с прямой записью в базу — также коммерческое решение давно присутствует на рынке.
Тому номеру который требуется исходя из логики конкретного решения
Это Вы в уме прикинули. Как нибудь, всё-таки попробуйте написать код параллельной передачи данных.
Если хотите, можно здесь в комментах попробовать.
Я за конструктив. Вполне может быть, что я где-то ошибаюсь. Пока нового ничего не услышал. А было бы здорово получить какое-то новое понимание того, как правильно делать.
Разбиваем обмен по сущностям — xml строка по выгрузке каждого объекта метаданных формируется отдельно.
Выборку изменений используем только для присвоения номера сообщений текущим записям в таблицах изменений.
Выгрузку проводим по каждому объекту метаданных запуском отдельного фонового задания с указанием номера сообщений для выборки.
Возвращенные строки XML склеиваем в результирующий файл обмена.
Перечни изменений в какой момент очищаются?
Хорошо работает?
Смотрите: вот в поток 1 выбрал 100 изменений. Им допустим был присвоен номер сообщения 51.
Вот поток 2 выбрал ещё 100 изменений. Им бы присвоен номер сообщения… какой? 52?
Ок. Допустим 52. Поток 2 закончил работу. Вызвана функция УдалитьИзменения(52), которая благополучно удалит и изменения с номером 51.
Поэтому я и спросил ранее про номер сообщения.
И первый и второй поток выбирают изменения для сообщения 51 — в моем случае распаралеливалась выборка данных. Удаление регистрации в данном случае никаких конфликтов не вызывало.
Так а в чём плюс такого подхода? Почти всё время передачи занимает непосредственно формирование сообщения и его чтение. Это и нужно параллелить.
Я делаю проще: каждый поток на передачу делает выборку и формирует сообщение. Просто в теле сообщения есть информация по своей нумерации.
порционность изменений в ПланахОбмена — это насколько я помню уже имеющаяся давно функциональность
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
все что вы описали — не имеет отношения к 1С как к платформе
Мне кажется Вы не очень внимательно прочитали просто.
А еще, для меня фразы типа «Все тормоза 1С связаны только с одной вещью — дефектами прикладного кода допускаемыми программистами. НУ и еще с неумением проектировать „нормальные“ метаданные.» пахнут маркетингом. 2й свежести.
И отдельное решение для интеграции и трансформации и это не КонвертацияДанных
Про это было бы интересно по подробнее. Что за решение?
и они работают и проблем с блокировками не испытывают. но там каждый запрос, и каждая процедура проходит ревью на предмет избыточных блокировок.
Так что я пришел к выводу, что в большинстве случаев «специалисты 1с» не особо заморачиваются и дергают данные довольно бездумно, а это порождает те самые пресловутые «Блокировки».
каждый запрос, и каждая процедура проходит ревью
«специалисты 1с» не особо заморачиваются и дергают данные довольно бездумно
Я бы так не сказал. Давайте напишем:
ДокументОбъект.Записать();
Теперь проведите ревью этого кода. Ничего страшного не видно?
Давайте выполним с записью запросов к базе. Похоже мы дёрнули бездумно много данных.
Я же пишу про то, что инструмент нужен, простой и доступный, для поиска и анализа блокировок.
нужен, простой и доступный, для поиска и анализа блокировок
В простом случае, например, у меня есть блокировки, а у Вас на тех же данных нет, что даст такой инструмент? Что он покажет?
Есть технологический журнал — он пишет то, что происходит во всех сеансах.
Собственно, ничего нового я не ожидаю. Должно показать, что Вы или кто-то ещё ожидали там-то на блокировке столько-то, в другом месте — столько то. Может быть также — нажал, подождал, отпустил, изучаешь. Тыкаешь в строку и видишь причину (или список причин), из-за которого происходило удержание на блокировке.
Что-то такое.
Скорее относится к СУБД и сильно от этого зависит.
Вы большой молодец. Еслиб мог поделиться шоколадкой, угостил бы. Поставлю плюсик тогда.
Вот вам инструмент БД показал, что запрос, что-нибудь вроде "INSERT INTO ##T436(_Fld0298, _Fld0292)… и так далее блокируется такого же вида запросом. Я знаю MS SQL вам даже визуальную схему нарисует. И чего дальше?
А управляемые блокировки?
Да и почему не иметь всё в одном месте? Особенно если взаимодействие с кодом не помешает.
Этот сервис хорош. Поэтому и привёл его как пример стороннего решения на эту тему.
Но в нём результаты не сразу отображаются. Иногда на следующий день только можно что-то увидеть. Плюс установка двух конфигураций. Плюс их настройка.
Хотелось бы типа такого же прямо в среде разработки. И чтоб взаимодействовало с кодом в модулях и с объектами.
Если даже стажёр начнёт находить источники блокировок, я уверен, выиграют от этого многие.
За ваш (кто это мы?) подход голосую двумя руками.
А на автора зря вы тут набросились. Одна из немногих статей по 1С-ной тематике на хорошем языке от адекватного автора. Я прочитал с интересом.
как минимум тянет за собой все процедуры и подписки которые срабатывают при записи этого документа… и если там все нормально, и написано не криво, то все будет проходить довольно быстро просто и даже таблица документов не будет блокироваться исключительно… так что тут никаких проблем не будет, блокировкам взяться неоткуда.(еще раз, это при условии что при записи документа ничего не происходит.)
)) если…
Если заниматься разработкой нофой конфы с нуля, есть такая роскошная возможность, как проведение ревью с самого начала. Я так и понял, что Вы под таким углом зрения проблему рассматриваете, когда написали про "окинуть взглядом".
А представьте, что конфа уже написана и такая, какая есть.
Нет автотестов. Нет никакой уверенности, что там всё хорошо.
Вот на такой случай было бы неплохо иметь простенький инструмент по поиску источника блокировок, если они таки случились.
А можно и без, обходились без него всё это время, и дальше обойдёмся.
попробуйте создать и записать большой набор записи в регистр сведений без вообще каких либо индексов и посмотрите в скуль аналайзер. и для хохмы замерьте время исполнения пустого цикла от 1 до 100000000. дефекты внутри платформы — есть, и каким бы ни был семи пядей во лбу 1сник, ничего он с этим не сделает. а на 5000 пользователей системы разбиты на базы и с помощью сторонних технологий.
для хохмы замерьте время исполнения пустого цикла от 1 до 100000000— а в чём смысл этого?
1С это не универсальный ЯП, а предметно-ориентированный.
а смысл, что в даже самых примитивных интерпретаторах примитивных языков типа бейсика это было поправлено еще в 90-е, но программистам ядра 1с этот опыт не пригодился
Но, действительно, в практике я ни разу не встречал потребности крутить такие циклы.
Как я уже писал, 1С это не универсальный ЯП, а предметно-ориентированный.
Работа ведётся большей частью с бизнес-объектами.
Был как то случай, из ком объекта массив байтов получали в кривой кодировке, так что в цикле их крутили, немного меняли значения. Бывало цикл со сложением внутри выполнялся несколько часов на 20-30кк операций.
Я бы просто написал бы мааааааленькую утилитку конвертации на C/Go/Rust/Python/по вкусу. А будучи скомпилированной с безконсольными ключиками она даже на экране не мелькает.
Или 1С не умеет вызывать внешние процессы?
ПС. В режиме отладки платформа 1С выполняет много всего на каждый перевод строки.
1С хороша тогда, когда используются проверенные временем типовые конфы вроде УТ10, БП2, БП3, УПП1.3 и т.д. То есть когда, надо вести бизнес и не париться — все хорошо. Но настает момент когда компания «вырастает». И тут начинается самое интересное.
Если стоит задача идти в ногу со временем, BigData, ИИ, HighLoad и прочее, то тут начинаются проблемы, и проблемы настолько серьезные, что проше написать с нуля на привычном для вас языке (Java, Python, C#).
Возможно у меня руки кривые, но всегда когда дело имел с переработанными конфигурациями, то все «хотелки» заказчика, только запутывали «паутину» все хуже. И латание одной дыры непременно создавала одну, а то и две новые.
В таком случае приходится держать штат собственных квалифированных программистов, а что если их нет?
В общем не так все просто с 1с, хотя и стоит признать, что ситуация налаживается. Платформа 8.3 так это вообще глоток свежего воздуха, для любителя «нативных» интеграций.
1С хороша тогда, когда используются проверенные временем типовые конфы вроде УТ10, БП2, БП3, УПП1.3 и т.д. То есть когда, надо вести бизнес и не париться — все хорошо. Но настает момент когда компания «вырастает». И тут начинается самое интересное.
Это проблема квалификации. Только и всего.
Обновлятор типовой конфигурации на следующую типовую вообще не программист. Это и бухгалтера умеют делать.
Если стоит задача идти в ногу со временем, BigData, ИИ, HighLoad и прочее, то тут начинаются проблемы, и проблемы настолько серьезные, что проше написать с нуля на привычном для вас языке (Java, Python, C#)
А при чем здесь вообще язык?
BigData — это проблема не в языке а в архитектуре.
И, минуточку, как это так у вас в мгновение ока случился переход с типовой конфы на БигДату, что вы не успели даже понять что тут нужны совсем другой специализации ИТшники?
Это проблема квалификации. Только и всего.
Обновлятор типовой конфигурации на следующую типовую вообще не программист. Это и бухгалтера умеют делать.
Собственно я о том же.
BigData — это проблема не в языке а в архитектуре.
А она у 1с идеальная?
И, минуточку, как это так у вас в мгновение ока случился переход с типовой конфы на БигДату, что вы не успели даже понять что тут нужны совсем другой специализации ИТшники?
Я разве говорил, что у нас случился переход с типовой конфы на БигДату? Хотя думаю, таких компаний хватает.
Это проблема квалификации. Только и всего
Кстати это какой квалификацией надо обладать чтоб правильно готовить 1с?
Я на пальцах могу пересчитать из своего окружения ребят, которые правильно «готовят» 1с. Не бегут править типовые модули, и добавлять свои реквизиты в регистры, а используют это в крайних случаях, а в большинстве своем используют либо внешние обработки, расширения, либо подстраиваются под типовой бизнес процесс.
Это я к тому, что если все сводится к наличию хороших прогеров, то все тоже самое сделать практически на любом стеке, благо хороших программистов c#, python, java не развелось, только еще не надо будет платить за 1с. В общем баян…
масса пользователей переваливает за некий порог, после которого уже ничего не помогает, даже корпоративный инструментальный пакет
дальше правильный путь — Центр поддержки крупных внедрений. Да и вообще без него видел внедрения на 700-1000 онлайн пользователей. А то, что написано в варианте 1 и 2 — дорого и без гарантированного результата. Да еще и с резким удорожанием поддержки.
А без ЦПКВ можно часто сделать базу распределенной (причем на платформе 1с это сделано очень хорошо) и получить вместо одной большой базы на одного килопользователя 4 базы по 250 пользователей на разных серверах с актуальностью данных от «фуллонлайн» для части данных до 10-15 минут для данных, к которым нет таких требований. Делить можно как функционально (склад отдельно, финансы отдельно), так и территориально (питер отдельно, москва отдельно).
Плюсую. Единственно, по двум вариантам я имел ввиду, что это пример свершившегося выбора в разных компаниях. Насчёт попытки применения ЦПКВ в них ничего не знаю. Может быть и не пытались.
В той же Рознице в обработке РМК только для того, что бы избавиться от модальности сделали кучу «ассинхронных» вызовов (например это вызов который совершается после закрытия формы когда никаких других действий не осуществляется) после каждого происходит блокировка интерфейса.
Спрашивается зачем?
Ассинхронность при работе с ККМ или ПК это вообще идиотизм порождающий периодически глюки.
Но в целом 1с — Хороша. Без кавычек. Хотелобы конечно создавать массив вот так
a=[1,2,5,4]
а не так
а= новый Массив;
а.Добавить(1);
а.Добавить(2);
а.Добавить(5);
а.Добавить(4);
Хотелось бы в запросах делать накопительные поля
Выбрать Т.Измерение, НакопительнаяСумма(Т.ресурс)
из Справочник как Т
Упорядочить по Т.Измерение
И
Выбрать Т.Измерение, НакопительнаяСумма(1) как ТутПорядокНомеровПоВозростанию
из Справочник как Т
Упорядочить по Т.Измерение
то проше написать с нуля на привычном для вас языке (Java, Python, C#)
О да, вы серьезно? Прямо вот все-все взять и переписать? И UI и Reporting и ORM… Ну т.е. надо конечно взять все готовое из опенсорса, а потом долго все это сопрягать. И постойте… бизнес-логику с 1С тоже надо портировать. И все сущности базы, и алгоритмы… Это точно «проще», чем отпрофилировать тормозные запросы, починить и все же оставить 1С?
— тормозной интерпретатор, ну правда и не говорите что это не важно. Кроме прочитать — вставить в 1С еще куча вычислений, переборов и прочего и порой эти тормоза очень даже заметны;
— отсутствие кастомных индексовю Нет я конечно могу поставить «индексировать» на атрибут, но а если мне надо сразу по двум полям или сделать inсlude? Легко вводится дополнительным метаданным к документам и справочникам;
— ну и стабильности
Разумеется любой программист средней руки может написать УЗКОспециализированное решение которое даже летать будет.
Но так делают не часто. Наверное это просто не выгодно по сравнению с типовыми универсальными пусть и не быстрыми решениями от 1С?
Иначе бы балом правила не 1С а множество программистов с очень шустрыми наколенными УЗКОспециализированными решениями.
Предыдущая статья — ворчание привыкшего к обычному приложению специалиста. 7 лет работаю исключительно с управляемым — прелесть, а не концепция. Асинхронность тоже хороша, если её осознать, а не пытаться использовать со старой меркой...
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.
То есть вы не знаете что у языка 1С есть английский синтаксис уже больше 20 лет?
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках.И что это даст?
Сделаны то только примитивные вещи для склада.
За бухгалтерию опенсоурсному сообществу взяться слабо.
А бухгалтерам сесть на опенсоурс для сдачи отчетов — стремно. Штраф за неправильные или не вовремя сданные налоги…
Но это не мешает очередному шапкозакидателю.
nclockworker покажите нам пример. Сделайте уже.
Это же так просто…
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.
Судя по качеству комментариев, то тут все со значительным 1С-стажем и знанием линейки «ассемблер, С++, C#, JavaScript», но только вы хотите избавится от платформы и перейти на что-то другое. Так в чем же дело, что вас останавливает? Ваш выбор Odoo (бывшая OpenERP), которая и опенсурс, и на популярном питончике, и на котором уже много бухгалтерских и прочих конфигураций создано — все как вы и хотели. Их типовые решения даже на русский язык локализированы, но никто не мешает вам писать «с нуля» и продавать свою поделку.
Вот только тут полная аналогия айфонов и андроидофонов. С одной стороны закрытая аппаратная платформа и ОС, которые контролируются вендором; а с другой стороны зоопарк тысяч кастомизаций различных версий операционки под сотни различных девайсов — тонны аппаратных и программных глюков, в которых даже никто не пытается разбираться. Причины популярности среди покупателей «закрытых» решений очевидны.
Прежде чем писать очередной бесполезный комментарий, прочитай пожалуйста внимательно статью.
Я тоже согласен с вашим оппонентом: считаю что грабли как правило находятся в безграмотности конкретного внедренца/админа/программиста 1С там где эксплуатируется ПО 1С.
Не спорю — любому сложному ПО всегда есть куда развиваться.
Но проблема низкой квалификации людей подавляющего большинства занимающихся этим ПО на местах — имеет место быть. И не только с 1С
Большинству инсталляции 1С и программист то вовсе не нужен — типовое обновление на типовую конфигурацию 1С может и бухгалтер накатить сам.
Ппри этом есть и другие, более навороченные инсталляции.
Именно они и нуждаются в присмотре КВАЛИФИЦИРОВАННЫХ спецов.
Теперь вопрос — если вы достаточно для этой задачи квалифицированны — то у вас не должно быть проблем с тем чтобы вручную создать несложный xml файл для включения технологического журнала, используемого для глубокого разбора тормозов. И т.д.
Квалифицированному специалисту платят хорошо за то что он решает проблемы.
Если же вы ожидаете что фирма 1С обязана сделат волшебную кнопку для программистов «решить все проблемы» — то возникает вопрос: а за что вам как профессионалу платить будут? Эту волшебную кнопку бухгалтера и сами нажать смогут.
Запомните: профессионалов нанимают и хорошо им платят только потому что наниматель сам не может решить проблему, и не может решить ее силами неспециализирующихся сотрудников.
Если проще — то даже стажёр должен уметь с проблемой справиться. И это не то, что вы предлагаете.
1С ни мне, ни вам ничего не обязана.
Статья претендует на конструктивную критику.
По поводу того, чем должен заниматься высокооплачиваемый специалист: ловлей блох или бизнес-анализом — вопрос спорный.

На скриншоте пример с 3мя процедурами, но есть типовые общие модули где таких процедур 20 и работа превращается в ад.
Что собственно мешало разработчикам сделать этот список растягивающимся?
Трудности работы разработчиков не приносит дохода 1С, в отличие от добавления «котиков» в Бухгалтерию 3.0, к примеру )
Приносят деньги постоянная адаптация под изменения в законодательстве. И только. За это заказчики готовы платить регулярно фирме 1С регулярно.
Приносит деньги методология автоматизации предлагаемая 1С. Ну не все способны придумать самостоятельно как вести свой учет, да и зачем каждому предприятию изобретать велосипед заново. За это тоже готовы платить заказчики фирме 1С.
И все
Вот похвалить 1с — это был бы подвиг. Ну, чтобы обоснованно, и чтобы с обоснованием, почему они выбрали тот или иной путь (и с ним — некое не всем поначалу видимое, но в результате материализовавшееся, положительное будущее)!
Ещё немного критики 1С