 |
|
|
|
Адаптация типовых конфигураций. Применение механизма расширений на практике
Адаптация типовых конфигураций Адаптация типовых решений от «1С» под требования заказчика чаще всего сопровождается сложностями. Вместе с новым функционалом приходят проблемы дальнейшего сопровождения в виде трудностей установки обновлений отпоставщика Применение хорошо зарекомендовавших себя практик доработки решает проблему частично – как не старайся, а переопределить типовой код без снятия конфигурации с поддержки невозможно. Помочь справиться с надоевшей проблемой призвана новая технология – механизм расширений. В прошлом номере журнала публиковалась статья «Правильная доработка типовых решений от 1С» [1]. В ней мы рассмотрели практики доработки типовых решений, позволяющих максимально сократить сложности с последующей установкой обновлений от поставщика. К сожалению, при глобальных доработках, затрагивающих основополагающие алгоритмы типового решения, предложенные методы не смогут полностью решить все проблемы. Разработчику придется снимать конфигурацию с поддержки и вносить изменения напрямую, модифицируя типовой код. Единственный способ не потеряться в собственных изменениях – включить на полную катушку документирование и спомощью подручных технологий автоматизировать проверку возможности объединения серьезно переработанных участков. Шаг влево, шаг вправо – и прощай выполненные изменения. Особые сложности возникают при росте участков с изменениями типового кода. В моей практике адаптации типовой конфигурации «Бухгалтерия 2.0» изменения затрагивали десятки участков кода. Каждый процесс обновления требовал особой внимательности, чтобы не затереть наработки. Наиболее трудно сращивать изменения после серьезного рефакторинга кода со стороны поставщика. При сопровождении «молодого» типового решения сращивание кода доставляет особые проблемы. Поставщик активно меняет код, и надо успевать подстраивать свои наработки. Механизм расширений Компания «1С» в курсе перечисленных выше трудности. Разработчики платформы потратили большое количество времени, чтобы привнести в систему новую технологию, способную решить наболевшие проблемы. Таким решением стал механизм расширений конфигурации. Как и все новое, с момента первого релиза технология подвергалась переосмысливанию, доработкам и пересмотру функционала. За пару лет существования концепт технологии устоялся, и сегодня ее можно применять без особого страха ирисков. Основные возможности прекрасно работают, и прикладным разработчикам пора примять ее в проектах. Перед тем как погрузиться в технические нюансы и рассмотрение практических примеров, давайте немного поговорим об общем механизме системы расширения конфигурации. Каким образом новая технология решает стек закоренелых проблемам? Первая и важная особенность расширений – работа поверх стоковой конфигурации. Разработчику не требуется снимать конфигурацию поддержки. В контексте механизма расширений необходимые доработки выносятся прямо врасширение. Технически расширение представляет собой мини-конфигурацию, которая при подключении объединяется с основной. Объединение выполняется автоматически сразу после подключения. Непосредственное подключение происходит прямо из режима «предприятие». Достаточно выбрать файл-расширение (*.cfe) и подключить его через менеджер расширений. Потребуется перезапуск «предприятие», и после него расширение будет готово к работе. Процесс подключения и активации расширения выполняется максимально прозрачно. Механизм расширений практически полностью решает проблему сопровождения доработанных конфигураций. В идеальных случаях конфигурацию не требуется снимать с поддержки, и последующие обновления выполняются стандартным образом. После установки обновления от поставщика добавленные расширения автоматически подключатся к обновленной информационной базе. Как разработчика вас никто не ограничивает в количестве расширений. Хотите – дробите функционал на отдельные расширения или держите доработки в одном. Главное, придерживайтесь принципа «все расширения должны быть к месту». Чрезмерное количество подключенных расширений может сыграть злую шутку и нанести урон производительности. Хорошо, а что если поставщик конфигурации внесет глобальные изменения, подобно упомянутым выше, – проведет серьезный рефакторинг кода? В этом случае фатального ничего не случится. Расширение просто перестанет работать, и высможете заняться адаптацией к новым требованиям. Механизм расширений покрывает сценарии адаптации типовых решений, но важно запомнить, что расширение не является полноценной конфигурацией. Разработчик может создавать дополнительные объекты метаданных (в расширении), но перечень поддерживаемых для создания объектов ограничен. Не буду перечислять список поддерживаемых объектов (см. официальную документацию), скажу лишь, что в расширениях отсутствует возможность создания объекта дляхранения информации. Добавить новый справочник или реквизит документа не получится. Это одновременно ограничение и защита данных. Если разработчик имеет возможность создавать в расширении объекты для хранения информации, а потом расширение случайно отключается от информационной базы, то данные улетят втрубу, что недопустимо. Хорошо, а как тогда быть, если доработка подразумевает ввод в конфигурацию дополнительных объектов метаданных (справочников, документов)? Снимать с поддержки? Нет, в этом случае активируется возможность внесения изменений (поддержка остается на месте), создаются новые объекты, а вот взаимодействие или переопределение типовых вещей выполняется в расширении. Схема работы расширений приведена на рис. 1.
Рисунок 1. Схема работы расширений Статью целиком читайте в журнале «Системный администратор», №4 за 2017 г. на страницах 60-65. PDF-версию данного номера можно приобрести в нашем магазине.
|
ИГОРЬ АНТОНОВ, руководитель отдела разработки ПО, страховая компания АО «ДальЖАСО», 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
