О кастомизациях вообще
Потребность в кастомизации программного обеспечения, т.е. его изменения под нужды конкретного пользователя, появилась, наверное, одновременно с самим программным обеспечением. Трудно написать программу, которая удовлетворит всех, а потому заложить в нее возможность изменений без привлечения производителя программы – хорошая идея. Особенно если дело касается бизнес-приложений, т.к. бизнес-процессы даже в одних и тех же областях могут отличаться в разных организациях.
Изменение исходного кода
Есть разные стратегии кастомизаций. Если приложение поставляется в исходных кодах, то самый очевидный подход – переписать исходный код под свои нужды. И самая очевидная в этом случае проблема – переход на новую версию приложения, т.к. он влечет слияние (merge) исходных кодов измененной на стороне клиента версии и новой версии от поставщика. А это может быть нетривиальной задачей, особенно если код на стороне клиента сильно кастомизирован.
Плагины
Более безопасная в этом плане стратегия – плагины. Исходное приложение предоставляет плагину фиксированный набор интерфейсов, а также возможность зарегистрировать себя в приложении. При выходе новой версии приложения плагины, написанные для предыдущей версии, продолжат работать и в новой версии (при условии неизменности интерфейсов). Поведение плагинов в новой версии может отличаться от поведения в предыдущей, если поставщик ПО изменил поведение приложения. Концепция плагинов используется в самых разнообразных классах ПО – офисном и бизнес-софте, средах разработки (Visual Studio, Eclipse, …), графических и звуковых редакторах и т.п.
Подписки
Еще одна технология кастомизации – возможность оформления подписки (subscription) на события в приложении и выполнения пользовательского кода на общеизвестном или проприетарном языке во время этих событий. События могут быть самого разного вида – открытие окна, загрузка изображения (для графического редактора), обработка заказа (для бизнес-системы).
Одна из разновидностей такого подхода – встраивание в основную программу возможности выполнять пользовательские скрипты на языках типа Visual Basic for Application (VBA). Кастомный код может, в частности, выполняться в ответ на события приложения. Тот же VBA показал себя очень мощным и гибким средством кастомизации; он встроен в Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS и другие продукты.
Кастомизации в решениях «1С»: начало
В платформе «1С:Предприятие» реализованы разные стратегии кастомизации. Поскольку прикладные решения 1С поставляются в исходных кодах, естественно, один из самых очевидных сценариев – изменение исходного кода.
Изменение исходного кода приложений 1С
Когда клиент меняет исходный код решения 1С под свои нужды, ему надо помнить, что поставщик приложения тоже не бездействует и выпускает новые версии, добавляя функциональность и исправляя ошибки. Чтобы при установке новой версии приложения не потерялись изменения, сделанные под потребности клиента, нужно каким-то образом произвести слияние (merge) измененной предыдущей версии приложения и новой версии.
Естественно, мы в «1С» уделяли большое внимание этой задаче и разработали механизм поставки и поддержки, облегчающий ее решение. Прежде чем рассказать, как он работает – пара деталей о внутреннем устройстве решений «1С».
Исходные коды и метаданные прикладного решения «1С» (конфигурации) хранятся в базе данных, в той же самой, в которой лежат данные самого приложения (проводки, данные справочников и документов и т.п.), т.е. программа хранится вместе с данными. База данных с конфигурацией (и данными приложения) в терминологии 1С называется информационной базой (сокращенно – инфобазой).
В процессе разработки поставщик конфигурации определяет, какие объекты конфигурации (справочники, документы и т.п.) клиент может менять, а какие – нет.
Настройка поставки на стороне поставщика
Клиент на своей стороне с помощью этого механизма также может определять правила поддержки объектов внедренной конфигурации поставщика— например, он может отказаться от поддержки поставщиком конкретного объекта, если возьмет на себя ответственность за дальнейшую модификацию этого объекта. А можно, наоборот, запретить редактирование объекта «своей» конфигурации (даже если поставщик разрешает это делать) с тем, чтобы застраховаться от случайного изменения.
Настройка поддержки на стороне клиента
Когда клиент начинает что-то менять в типовой конфигурации, в инфобазе создаются две конфигурации:
- Оригинальная конфигурация поставщика.
- Текущая конфигурация, измененная на стороне клиента.
И вот поставщик выпускает новую версию. Она может поставляться в виде полного приложения, а может — в виде пакета обновления с измененными объектами. При переходе на новую версию у нас на стороне клиента имеется 3 конфигурации, на основании которых осуществляется так называемое трехстороннее слияние конфигураций:
- Старая конфигурация от поставщика.
- Текущая конфигурация клиента (старая конфигурация от поставщика плюс изменения, сделанные в ней клиентом).
- Новая конфигурация от поставщика.
Понятно, что в ряде случаев объекты, измененные поставщиком, можно обновлять автоматически:
- Объекты, не измененные клиентом.
- Простые изменения объектов на стороне клиента (например, добавление дополнительных реквизитов к объекту).
В случае же, когда объект был изменен и на стороне клиента, и в новой версии от поставщика, необходимо ручное вмешательство. У нас есть мощный механизм сравнения и объединения не только для модулей кода, но и для моделей (метаданных, форм, отчетов…), но даже с этим механизмом объединение конфигураций может быть нетривиальной задачей.
Внешние отчеты и обработки
Другой механизм кастомизации, сравнительно безопасный с точки зрения перехода на новые версии – это механизм внешних отчетов и обработок. Как следует из названия, оба типа объектов — внешние отчеты и внешние обработки – являются внешними по отношению к прикладному решению, хранятся в отдельных файлах и загружаются в прикладное решение в момент исполнения. Таким образом, процесс перехода на новую версию не затрагивает их вовсе. Но в случае, если в новой версии реквизиты какого-либо объекта были удалены или переименованы, а обработка или отчет обращаются к ним – на новой версии отчет или обработка без переделки не заработают.
Внешние отчеты и обработки по сути являются плагинами. Они хорошо подходят для «кастомных» отчетов и специфических операций над данными (например, для импорта информации из других систем), но, конечно, покрывают далеко не все сценарии кастомизации. Если клиенту нужно добавить специфический код, который должен выполняться при проведении документа, внешней обработкой тут не обойтись – надо править исходный код модуля документа.
Кастомизации в облаках
С появлением облачной технологии 1cFresh задача кастомизации вышла на новый уровень. Дело в том, что в «облаке» пользователи прикладного решения из разных организаций могут физически работать с одной информационной базой (т.е. с одним экземпляром приложения), но, в то же время, благодаря механизму разделения данных, видят только данные своей организации. Кастомизация через изменение исходного кода здесь становятся неприемлемой – каждой организации нужны свои кастомизации, и совершенно не нужны кастомизации «соседей» по инфобазе.
В «облаке» для кастомизации применимо только использование внешних отчетов и обработок, но, как говорилось выше, внешние отчеты и обработки покрывают далеко не все нужные пользователям сценарии.
Расширения конфигурации
Итак, нам нужно было придумать механизм кастомизации, который бы удовлетворял следующим требованиям:
- Позволял бы легко обновлять кастомизированное решение на новую версию, избегая ручной работы по объединению конфигураций.
- Позволял включать кастомизацию при определенных условиях (например, если мы работаем в контексте определенной организации).
- Снижал вероятность потери работоспособности кастомизации при переходе на новую версию исходной конфигурации.
- Имел возможность отключения кастомизации в случае проблем для сохранения работоспособности приложения.
Такой механизм, помимо применения в облачных решениях, сильно облегчил бы жизнь при переходе на новую версию на внедрениях типовых конфигураций, где необходимы кастомизации.
Мы придумали такой механизм и назвали его расширения. Этот механизм в каком-то смысле совмещает в себе два подхода к кастомизации – идеологию плагинов и механизм подписок.
Расширения – это способ держать изменения конфигурации отдельно от самой конфигурации. Расширение, по сути, само является отдельной конфигурацией, содержащей измененные объекты. Оно так же, как и конфигурация, представляется в виде дерева объектов. Для работы с расширением используются те же приёмы работы, что и с обычной конфигурацией:
Если мы хотим задействовать в расширении объект из основной конфигурации (например, добавить новую форму к существующему в основной конфигурации документу) – нам вначале надо позаимствовать объект к себе в расширение через команду «Добавить в расширение». Сразу после добавления объекта в расширение он «пустой» в дереве объектов расширения – у него есть только те свойства, которые есть в основной конфигурации. Можно также позаимствовать из основной конфигурации уже существующую форму и, например, добавить к ней новую кнопку, выполняющую какое-либо специфическое действие. К объектам в расширениях пока нельзя добавлять новые реквизиты, но мы работаем над этим.
Основная конфигурация и расширение с заимствованным документом СчетФактураВыданный
В расширении также есть аналог подписки на события — возможность обрабатывать события объектов расширяемой конфигурации, например, обработку записи. Можно указать, как именно будет вызываться наш код в расширении:
Мы можем перед стандартной процедурой записи документа вызвать наш код, который, например, проверит, заполнено ли поле ответственного за документ сотрудника, и если нет – запишет в это поле текущего пользователя:
&После("ПередЗаписью")
Процедура РасшАндромеда_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если (ЭтотОбъект.Ответственный = Справочники.Пользователи.ПустаяСсылка()) Тогда
ЭтотОбъект.Ответственный = МодульПользователи.ПолучитьТекущегоПользователя();
КонецЕсли;
КонецПроцедурыВ новой версии конфигурации реализация записи документа может измениться, но наш код в расширении будет по-прежнему выполняться перед стандартным кодом записи документа и делать свою работу.
Во время исполнения типовая конфигурация и расширения (их может быть несколько) «складываются», давая в итоге новую, кастомизированную конфигурацию, с которой и работает конечный пользователь.
Порядок выполнения расширений
При разработке расширений следует помнить, что платформа не гарантирует одинакового порядка выполнения расширений при добавлении нескольких расширений к конфигурации. Мы сознательно отказались от явного задания порядка выполнения расширений, т.к. это, на наш взгляд, усложняет настройку и в конечном счете привносит больше проблем, чем решает.
Если у нас к конфигурации добавляются несколько расширений, в каждом из которых есть обработка проведения одного и того же документа с директивой «&После», то все обработчики будут выполнены, но платформа не гарантирует, что порядок их выполнения всегда будет одинаков. Это надо учитывать при разработке расширений.
В случае наличия в нескольких расширениях обработчика одного и того же события с директивой «&Вместо» будет выполнен только один обработчик, причем какой – заранее сказать нельзя. Об этом нужно помнить и отслеживать, чтобы к конфигурации не более одного расширения имели обработчик «&Вместо» для одного и того же объекта/события.
Кастомизация форм в расширениях
Мы можем позаимствовать в свое расширение форму объекта из конфигурации (например, форму документа). При этом в визуальном редакторе формы в расширении мы увидим форму такой же, как и в основной конфигурации. А в редакторе кода формы в расширении будет пусто – весь код для формы пока содержится только в основной конфигурации.
На форму можно добавить новую кнопку (или даже несколько). В случае если несколько расширений добавляют на одну и ту же форму свои кнопки – все они будут присутствовать на итоговой форме во время исполнения.
А вот удалять стандартные элементы с формы не рекомендуется – это может сломать существующий в оригинальной конфигурации код (если он обращается к элементам формы). Если уж есть такая нужда – лучше делать элементы невидимыми через свойство «Видимость».
Нужно учитывать, что приложение на «1С:Предприятии» — это не просто код на языке программирования. БОльшая часть приложения описывается в виде декларативных моделей. Причем для разных задач используются разные виды моделей (формы, отчеты, права, ….). Для каждого вида модели мы подбираем свой способ кастомизации в расширениях, обеспечивающий наиболее удобное изменение для типичных случаев.
Преимущества расширений
Расширения имеют идеологическое отличие от механизма поставки и поддержки. В механизме поставки и поддержки разработчик правит конфигурацию поставщика, как хочет, как будто просто дорабатывает свою конфигурацию, а потом (при обновлении) разбирается с тем, как синхронизировать конфликтующие изменения. В расширениях разработчик сразу изначально разрабатывает именно расширение – в терминах добавляемой функциональности. Расширение хранится системой именно как дополнение и система заботится о максимально безопасном обновлении.
Простота перехода на новую версию конфигурации
Когда поставщик выпускает новую версию типовой конфигурации, выполняется автоматическое обновление, поскольку режим поддержки типовой конфигурации не менялся — она осталась на полной поддержке поставщика. А при запуске обновлённого прикладного решения платформа снова автоматически объединит изменённую типовую конфигурацию с расширением. И клиент продолжит работать с изменённым под его потребности типовым решением.
Иногда все же после обновления версии типовой конфигурации может потребоваться адаптация расширения под новую версию, например, если в новой версии переименованы объекты или реквизиты объектов, задействованных в расширении. Чуть подробнее об этом ниже, в разделе «Раннее оповещение об ошибках».
Изменения лежат отдельно
Первое очевидное преимущество расширений – все кастомизации, сделанные для клиента, лежат отдельно от типовой конфигурации, и теперь не надо сравнивать измененную конфигурацию с типовой чтобы понять, что же именно было изменено.
Уже упоминалось, что для того, чтобы задействовать в расширении объект из основной конфигурации, его надо позаимствовать в расширение из основной конфигурации. Таким образом, в расширении появляется нечто вроде ссылки на объект из основной конфигурации.
При этом есть способ понять, какие заимствованные объекты в конфигурации действительно изменены, а какие позаимствованы в режиме read-only – например, для использования в отчетах. В дереве объектов расширения есть кнопка фильтра «Изменённые и добавленные в расширении», после нажатия которой в дереве остаются только заимствованные объекты, модифицированные в этом расширении, и новые объекты, созданные в этом расширении.
Раннее оповещение об ошибках
Предположим, мы позаимствовали в расширение справочник Контракты из основной конфигурации для использования его в отчете. Тем временем вышла новая версия типовой конфигурации, в которой справочник Контракты был переименован в Договоры. Естественно, после перехода на новую версию наш отчет в расширении работать не будет. Если бы мы использовали старую технологию кастомизации — внешний отчет, то ошибка возникла бы только в момент выполнения отчета. В случае же расширений у нас есть возможность проверить корректность расширений в design-time после обновления версии типовой конфигурации, и исправить все проблемы до того, как пользователи начнут работу.
Особенно это актуально на внедрениях, где в одной информационной базе используется много расширений, а обновление версии конфигурации проводится централизованно (например, на облачных внедрениях, где разные организации, использующие одну и ту же конфигурацию, но работающие в разных областях данных, могут использовать разные наборы расширений). Администратор может на тестовой базе обновить версию типовой конфигурации и проверить корректность всех пользовательских расширений относительно новой версии. В случае проблем он сообщит о них владельцам расширений, и переход рабочей базы на новую версию типовой конфигурации будет сделан только тогда, когда все расширения будут приведены в соответствие с новой версией конфигурации.
Что дальше?
Мы считаем развитие расширений одним из главных направлений развития средств кастомизации в платформе «1С:Предприятие». Расширения, задуманные изначально для облегчения кастомизаций в облачном сервисе, были спроектированы так, чтобы облегчить и ситуации с кастомизациями и на не-облачных внедрениях.
Пока в расширениях можно откастомизировать не всё, что хочется. Например, пока нельзя создавать новые прикладные объекты (справочники, документы и т.д.) и нельзя добавлять новые реквизиты к существующим прикладным объектам. Мы работаем над этим (и над другими возможностями тоже) и практически в каждой новой версии платформы «1С:Предприятие» добавляем в расширения новые возможности:
- Web и HTTP сервисы в расширениях (версия 8.3.7).
- Добавление собственных объектов в расширениях — общих команд, макетов и картинок, а также форм заимствованных прикладных объектов, их команд и макетов (версия 8.3.8, ссылка).
- Развитие механизма расширений (добавление ролей в расширениях – версия 8.3.9).
- Расширение модулей (версия 8.3.9).
Комментарии (60)
ssdvig
27.01.2017 09:42Да даже то, что есть — уже хорошо, добавление новых реквизитов в основную конфигурацию не сильно усложняет обновление, а вот изменение формы — да.
pro100_mixa
27.01.2017 10:09Расширения совсем не годятся для разработки в команде.
Многие, кто работает с УТ, привыкли к специальным вызовам из модулей форм, через которые можно внести изменения. Вообще интересней было бы на различные события форм довешивать свои процедуры с указанием порядка выполнения/замещения стандартного обработчика (смесь подписок на события и расширений) и работать с ними в «своих» модулях, без изменения конфигурации поставщика.
Когда 8.3.10 тестовая будет?eks1985
27.01.2017 10:53А что сейчас мешает это делать?
http://v8.1c.ru/o7/201603module/index.htm
Перехват
Вы можете перехватывать любые методы типовой конфигурации, обрамляя их собственными, или даже заменяя целиком.
Собственные обработчики
Вы можете добавлять собственные обработчики событий типовой конфигурации. Если, например, в типовой конфигурации они не назначены.Все это доступно в 8.3.9
Когда 8.3.10 тестовая будет?
8.3.10 Ориентировочная дата выхода 22.02.17
pro100_mixa
27.01.2017 12:10Расширения совсем не годятся для разработки в команде.
Вообще не годятся!
Все это доступно, но не для «реальной» разработкиeks1985
27.01.2017 13:38Да почему не годятся? Пояснить можете? Я сейчас так кастомизирую ERP, вроде все что заявлено в расширениях работает. Не хватает только возможности добавлять объекты — реквизиты, чтобы совсем уж не трогать основную конфигурацию, а вынести все доработки в отдельные слои.
pro100_mixa
27.01.2017 14:02Работа в команде это когда несколько человек работает над улучшением какой-либо подсистемы.
Вот мы начали делать новый проект по изменению подсистемы.
Модифицируя конфигурацию поставщика каждый захватывает, изменяет и освобождает модули, формы и прочее, все хорошо, каждый сразу видит изменения других.
Что предлагает нам расширения для работы в команде? Ничего. Чтобы один программист увидел изменения в расширении другого программиста надо чтобы первый выгрузил и передал расширение другому программисту, загрузил себе, потом как закончил выгрузил и отдал следующему. Никакой параллельной работы.
Другой вариант. Каждый создает свое расширение. И что в этом случае? Либо объединять как-то все расширения в одно, либо оставлять кучу расширений. Но как во втором случае увидеть весь код вместе?
Тем более расширения это отдельные от конфигурации объекты, и посмотреть весь код вместе (конфигурация + расширение) не получится.
Neikist
27.01.2017 14:05Интересно, тот же git тут прикрутить не выйдет? Тем более что в EDT вроде как его нативная поддержка планируется.
pro100_mixa
27.01.2017 14:44EDT пока не справляется с минимально необходимым функционалом, а уж тем более что-то «новое» типа git для расширений — не скоро будет или вообще не будет
Как описано в посте, расширения для фреша, а фреш используется маленькими компаниями и небольшими доработками
я же в своем комментарии пофантазировал о программной оболочке этих «расширений» без расширений
iliabvf
27.01.2017 10:46Просто поразительно как 1С постоянно изобретает велосипеды.
Вместо простешего ООП — прикладные объекты, вместо упрощения в нормальный современный скриптовый язык — вековой давности бейсик, метаданные, вместо html/css/js GUI — управляемые формы.
Если в десктопной платформе интерфейс Такси более-менее, то GUI в мобильной платформе, без преувеличения просто ужас. Пытались решить этот ужас с помощью jquery material design, так что вы думаете? контрол отвечающий за отображение html в мобильной платформе может только отображать html без обратной связи.
А теперь о хорошем, недавно 1С научилась работать с бинарными данными.eks1985
27.01.2017 10:56вместо html/css/js GUI — управляемые формы
Предлагаете вместо управляемых форм писать GUI на чистом html/css/js? Тогда конечно можно нарисовать любой сложности форму. Вот только скорость разработки упадет раз этак в 100.
fishca
27.01.2017 14:00Это не самое страшное. Плохо то что толстые формы лишаются поддержки, а у народа таких конфигураций пруд пруди, при этом управляемые формы, мягко говоря, слабо управляются.
iliabvf
27.01.2017 16:22что вы говорите? а я видел школьников программирующих на js. Видимо все таки разработка 1С легче и универсальнее чем международные open-source решения
Drac013
27.01.2017 16:49Вы путаете сложность и скорость разработки.
Да и руководствуясь вашим пример, можно сказать, раз школьники могут программировать на ассемблере (таких и я видел лично), то незачем пользоваться не низкоуровневыми языками программирования и уж тем более фреймворками.
DenEncode
27.01.2017 18:58Почему в 100? Если бы стандартный интерфейс был реализован на каком-нибудь гипотетическом 1с.js фрейморке, в котором по умолчанию было бы тоже самое что есть сейчас, т.е. готовые компоненты и дефолтный дизайн (Кстати под капотом управляемых форм наверняка внутренний js фреймворк? Дать бы api с ним поработать, а для тех кто любит по старинке оставить привычный вариант через конфигуратор). Это было бы очень круто.
se80
27.01.2017 10:54-3дожили… 1c на хабре.
Drac013
27.01.2017 15:35+3Простите, а где еще быть одному из крупнейших разработчиков ПО на территории СНГ?
Termux
28.01.2017 12:29-2Там не столько ПО, сколько «экосистема»
в форме трёхногой табуретки из костылей и колеса:
лоббисты в госдуре, непрерывно меняющие законодательство,
впариватели жёлтых коробочек, пихающие везде варезные MSSQL,
дающие права «всем на всё» и добавляющие ВСЕХ пользователей
корпоративной сети в группу администраторов домена…
И про «СНГ» — вы тоже абсолютно в точку. Ни в одной из 7 развитых стран еврейского содружества
не будет востребована ситстема, в которой можно «перепроводить» задним числом
— такое возможно только в растаскиваемых странах-бензоколониях переферийного капитализмаDrac013
30.01.2017 09:57+1«такое возможно только в растаскиваемых странах-бензоколониях переферийного капитализма»
Вот открыта у меня сейчас QuickBooks Enterprise, где вполне себе можно исправить любой документ задним числом. Вы США тоже относите к «растаскиваемым странам-бензоколониях переферийного капитализма»?Termux
30.01.2017 12:07-3да хоть ERPNext, FrontAccounting, inoERP или invocera!
Большинство поняли — о чём я,
а доебаться решил один пУтриот,
да и то — учащий «родину любить» из загнивающей СШАшкиDrac013
30.01.2017 12:16+1Что-то вас совсем занесло. Снизьте градус неадеквата.
Большинство поняли — о чём я
Объяснили бы оставшимся. QBE — это не подвальная open-source ERP. Это лидер рынка США среди программ учета для малого и среднего бизнеса в США. Вполне себе американский аналог 1С. И там есть работа задним числом прямо из коробки. Так что ваша позиция нуждается в больше аргументации.
да и то — учащий «родину любить» из загнивающей СШАшки
Вы считаете, что какую-либо программу можно запустить только в стране ее происхождения?
Neikist
30.01.2017 12:44Я конечно от 1с далеко не в восторге (говорю как человек на 1с пишущий), но вас конкретно занесло отвечать на контраргумент переходом на личности с матом и штампами раздела «политика» разного рода интернет ресурсов.
o4karek
30.01.2017 10:43Фантастически незамутненный поток сознания…
Собраны в кучу, наверное, почти все «городские легенды»
Wernisag
27.01.2017 15:40Вы путаете ещё один продукт, который необходимо поддерживать с элитой из элит среди программистов
mgis
28.01.2017 13:20Объясните пожалуйста. Допустим я в расширении добавил реквизит для справочника. В БД также создастся колонка для таблицы? Если да то нужно ли следить за последующим удалением неактуальных полей из БД?
cleaner_it
29.01.2017 09:33Сейчас нет возможности добавить реквизит объекту, только для формы. Когда реализуют — тогда посмотрим. Скорее всего, будет отдельный механизм контроля
Dr_Wut
30.01.2017 00:32Это ладно, вот кто мне скажет когда 1с научиться наконец таки многопоточности? На дворе 2017 год, а я все равно закупаю сервера с самой большой тактовой частотой чисто под 1с, ибо другого не умеет. Да и кластер уже пора бы сделать нормальный, и балансировщик… уже практически все маломальски значимые системы это умеют — вы нет…
Хотя я могу сказать что у 1с есть два качества, из-за которых ее будут продалжать покупать. И не только в СНГ. Это банально скорость и стоимость разработки учетного продукта. Тут 1с вообще все конкуренции…
EvilBeaver
30.01.2017 17:25А можете развернуть тему: что именно вы хотите от многопоточности в 1С? Кажется, вас дезинформировали насчет полного отсутствия параллельных задач в 1С. А равно, как и про отсутствие балансировщика и кластера. Что есть «нормальный» балансировщик?
Dr_Wut
31.01.2017 06:33Я хочу от многопоточности стандартного — многопоточности :) если на сервере 1 база, работает 10 человек, запущен 1 процесс то использоваться будет 1 ядро все зависимости от того, сколько реально есть ядер. И если все эти 10 человек запустят что-то адски тежелое — то единственная возможность это убыстрить — частота ядра.
Про балансировщик и кластер.
1. Распределение людей по всем имеющимся серверам
2. Автоперезод при падении
3. Геораспределенность
Так же многочисленными тестами подтверждено что на старых процах работает быстрее.
Ну и еще момент — производительность. Она в принципе достаточно низкая, но это уже отдельная песня. Это болезнь большинства скриптовых языков.
В целом 1с не так уж плоха, но к сожалению она настолько сильно заняла рынок что у нее нет конкурентов и товарищам нет нужды активно бороться за выживание и делать высококачественный продукт…fishca
31.01.2017 08:23+1Сервер 1С вообще-то многопоточный
Dr_Wut
02.02.2017 00:14Нет. Сделайте 1 процесс, запустите что-нибудь адски тяжелое по процу и увидете что загружено будет только 1 ядро все зависимости от их количества.
fishca
02.02.2017 08:33Создаю и запускаю несколько адски тяжелых фоновых заданий по процу и вижу равномерную загрузку всех ядер проца.
o4karek
02.02.2017 09:45Что мешает запускать фоновые задания и выносить в них действия, которые могут распаралеливаться?
Neikist
02.02.2017 13:13Рискну ответить за автора комментария:
1. В формах с этим могут быть проблемы;
2. Подозреваю имеется в виду что то вроде примера ниже:
а = а+б;
в = д+г;
и система видя это отправляет первую строку в один поток, вторую в другой. Фоновые задания на такие случаи городить — не очень идея. Тяжеловатыo4karek
02.02.2017 13:351. Какие?
2. А в мире есть скриптовые интерпретаторы, который такое распарралеливание делает?Neikist
02.02.2017 14:071. Для запуска фонового задания нужен общий модуль с экспортной процедурой.
2. Увы, тут погорячился.
В принципе можно было бы упростить работу с многопоточностью, дав более удобные средства. Например возможность запустить процедуру в другом потоке передав колбэк, пусть даже только на серверную процедуру формы, а не клиентскую как сейчас с ОбработкаОповещения. Да даже просто запуск в фоновом внеконтекстных процедур формы был бы плюсом.o4karek
02.02.2017 16:451. Это понятно. Но все-таки это проблемы не с формами :)
Упростить — наверное можно. И еще много чего можно сделать (наверное). Но пока не сделали.
D01
30.01.2017 14:30-1Восьмерка — это конечно интересно, но не хватает той простоты, что была в версии 77.
На мой взгляд 1С 77 — это шедевр.
А то, что делается сейчас — движение к еще одному языку программирования. При этом если что-то делать «с нуля», то проще взять несколько фреймворков (серверный и js +css) и сделать проще и быстрее.Drac013
30.01.2017 14:39Голая платформа 7.7 — это мрак. По всем параметрам: функциональность, интерфейс, масштабируемость. Чтобы подтянуть функциональность до адекватного уровня нужны 1C++ и FormEx. Плюс еще различные компоненты и сторонние приложения. И то часто возникают ситуации, когда всего этого может не хватить. Жить можно, если система уже отлажена и работает десяток лет, но это явно не продукт для новых проектов по автоматизации.
svcoder
31.01.2017 10:30Объясните, какой смысл было выпускать механизм расширений без возможности помещения изменений по ним в хранилище? Вы понимаете, что этим вы исключили использование этого механизма для подавляющее большинства вероятных пользователей?
nikvel
31.01.2017 15:29Касательно кастомизации: в прошлом году делали печатную форму счета для 1cfresh, так через пару месяцев она слетела, так как разработчики 1с решили переименовать поле «Комментарий» в «Примечание» или как-то так, точно не помню. Зачем? Зачем это им понадобилось?
В итоге: остались без печ.формы на неделю, заплатили программисту за час работы (самим в 1cfresh не запилить, только через авторизованных франчайзи). И это всего лишь простая печатная форма!
trdm
31.01.2017 15:29Господа разработчики платфомы 1С, как у вас дела с ЛИНТЕРОМ?
Не сдвинулись с мертвой точки?
Обсуждение на форуме линтера тут:
http://www.linter.ru/ru/forum/?PAGE_NAME=read&FID=18&TID=71Dementor
31.01.2017 22:03Только благодаря вашему комментарию узнал о существовании такой СУБД. На форуме ЛИНТЕРа правильно пишут, что 1С не будет с ними интегрироваться пока у них не появится известность.
Давайте маленькое сравнение. Что средний ИТшник знает о PostgreSQL? То, что каждый квартал по всей стране проходят конференции, семинары и лекции по мотивам из более крупных PgConf; открываются новые обучающие курсы, в том числе бесплатные видео-уроки для админов; в ИТ-изданиях пишут о том, что бывшие адепты MySQL уходят в PostgreSQL или о том, что благодаря поддержке хранения JSON-объектов эта СУБД может отобрать кусочек хлеба у некоторых из No-SQL решений… А что мы (среднестатистические ИТ-шники) знаем про Линтер? Случайный комментарий на хабре с вопросом не совсем по теме статьи. Не серьезно… Не удивлюсь, если офис-менеджеры 1С видя письма по теме Линтера считают это «гербалайвовщиной» и удаляют не читая.
Vovchik74
31.01.2017 15:29а по GAMP5 вышеописанное к чему относится?
Category 4: Configured software
ИЛИ
Category 5: Custom software
PeterG
03.02.2017 10:34Судя по этой статье — Category 5: Custom software.
В табличке ниже указано — «Configuration using a vendor-supplied scripting language should be handled as custom componnets (category 5).» (правая колонка, описание Category 4).
Vovchik74
03.02.2017 10:56Вот тут и вопрос, сразу вся база в 5 категорию или только «custom componnets» в 5-ую
Есть практика валидации КС по GAMP5?PeterG
03.02.2017 11:09Есть практика валидации КС по GAMP5?
Я про такую практику пока не слышал.
Если вы услышите — напишите мне пожалуйста, буду благодарен.
сразу вся база в 5 категорию или только «custom componnets» в 5-ую
Тут зависит от того, о чем именно мы говорим.
Если про внешние отчеты/обработки — то «custom componnets», т.е. собственно сами внешние отчеты/обработки.
Если про расширения — то, как мне кажется, вся база, т.к. обработки грузятся в инфобазу.Vovchik74
03.02.2017 11:34Судя по разъяснениям коллег SAP — именно вся система остаётся на 4 категории, по 5 категории валидируется только то, что написано на «vendor-supplied scripting language» дополнительно.
Если мы конфигурацию с поддержки не снимали — это может быть основанием для того чтоб защитить часть компонентов по 4 категории. Но после того как мы включим возможность изменения — что дальше?
Вопрос наверное даже бы прозвучал по другому, как сама 1С относится к расширениям?
Как 1С относится к включению возможности изменения?
Ведь в спорном моменте между «Валидаторами» и «Отделом ИТ» ответ можно построить только на мнении вендора (1с).
PeterG
03.02.2017 15:12Да, похоже я был неправ по поводу расширений — конфигурация ведь остается на поддержке. Т.е. под категорию 5 попадают только сами расширения, не вся конфигурация.
Vovchik74
06.02.2017 10:27Воот.
А что же думает сама компания 1С по этому поводу?
И если мы включим изменения и добавим реквизиты в расширение? Тогда что?
eks1985
Вот это ключевой момент. Если 1с сделает возможность добавлять новые прикладные объекты — это будет прорыв.
ClosedSneaky
Но есть же native addons — берешь и пишешь себе прикладной объект, по-взрослому на c++.
Главное придумать что за новый вид прикладного объекта нужен, а его реализация это не такая большая проблема. Если нужно чтобы «свой прикладной объект» работал с базой, то есть webservice и json.
Не понимаю, что за проблема, чего не хватает. Какие прикладные объекты вы бы хотели добавить?
eks1985
Вы не поняли, я говорю не о новом типе объектов. А об экземплярах. Нужно нам реализовать какую-либо подсистему новую — создаем расширение, добавляем справочники, документы, отчеты какие нам нужны. Сейчас можно доблять только реквизиты. Причем тут с++, причем тут native addons. Я говорю не о расширении платформы, а о "слоях кода", чем по сути расширения и являются. Но сейчас в расширениях можно не все, но над этим работают, что в статье собственно и написано.
EvilBeaver
расширения созданы, в-основном, для кастомизации в облаке 1cfresh по модели multy-tenancy. Т.е. база данных одна на всех, а кастомизации у каждого свои. Поэтому, в расширениях не будет возможностей, требующих модификации схемы базы данных.
Опять же, это не значит, что в будушем 1С не придумает нечто, что позволит это запилить, но полагаю, это будет нескоро. Они все делают исходя из собственного бизнес-эффекта.