Решение на базе 1С:Предприятие.Элемент в информационном ландшафте предприятия

Меня зовут Матвей Серегин. Я работаю в фирме «1С», отвечаю за разработку сервиса 1С:Бухобслуживание. В свободное от работы время преподаю разработку на технологиях от 1С, а также рассказываю об особенностях платформы на различных вебинарах и мастер-классах. Материалы от меня можно найти на портале для разработчиков фирмы «1С» – developer.1c.ru.

Хочу рассказать о перспективах решений на базе 1С:Элемент в ИТ-ландшафте предприятия. Мы рассмотрим:

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

• Поищем среди этого многообразия точки, где нам будет полезна технология 1С:Предприятие.Элемент.

• Обсудим, как начать разрабатывать на этой технологии и сколько времени потребуется на то, чтобы ее освоить, учитывая, что мы уже хорошо умеем разрабатывать решения на платформе 1С:Предприятие 8.

Классификация ИТ-решений предприятия и стереотипные решения в отдельных слоях

Традиционно ИТ-решения предприятия представлены в виде трех слоев архитектуры: фронт-офис, бэк-офис и инфраструктура. Рассмотрим, что скрывается внутри каждого из этих слоев:

• Фронт-офис представляет собой набор ИТ-решений, которые направлены вовне – в большинстве случаев, на клиентов. Цель решений для фронт-офиса – привлечь клиента, предоставить ему услуги, удержать и так далее. Такие решения традиционно представляют собой сайты, порталы, личные кабинеты, мобильные приложения. И для разработки часто используются веб-технологии и различные популярные CMS.

• Бэк-офис – это вотчина 1С:Предприятия. Специалисты бэк-офиса, финансисты, специалисты по регламентированному учету, расчетчики, кадровики, топ-менеджмент работают в системах бэк-офиса – ERP и HRM-системах, системах для регламентированного учета, бюджетирования, планирования и других, где в качестве стека используется любимая нами платформа 1С:Предприятие 8.

• Инфраструктура – как вены в теле человека, связывает все информационные решения в единый ландшафт, обеспечивая сквозную аутентификацию и позволяя обмениваться данными через различные механизмы. Инфраструктура делает работу сотрудников эффективнее, поскольку позволяет хранить файлы и предоставляет площадки для развертывания других ИТ-решений – выступает как IaaS или PaaS.

А что на стыках? Идеи для применения 1С:Предприятие.Элемент

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

Давайте посмотрим несколько примеров таких задач – несколько кейсов, которые попадают на стыки слоев архитектуры.

Первый кейс касается наших сотрудников.

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

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

Второй кейс также связан с сотрудниками или подрядчиками.

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

• Выдать им заказы или маршруты.

• Предоставить возможность сдать нам отчет о доставке или выполненной работе.

• Контролировать взаиморасчеты с ними.

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

Третий кейс – поставщики и дистрибьюторы.

С ними у нас также возникает задача создания личных кабинетов, чтобы поставщик мог:

• Поискать позиции, которые нам нужны, и предложить их.

• Получить уведомление, когда от нас будет опубликован новый похожий заказ.

• Поучаствовать в тендере – выложить свое предложение и посмотреть его статус, если предложение будет одобрено.

• Посмотреть взаиморасчеты.

• Посмотреть историю взаимоотношений.

Четвертый кейс касается учащихся в среднеспециальных учебных заведениях, а также в частных школах.

Мы можем предложить и родителям, и детям:

• Следить за посещаемостью и успеваемостью детей.

• Смотреть расписание и домашние задания.

• Предлагать дополнительные услуги – например, кружки, поездки на каникулы, экскурсии, совместные походы в театр. Не в чатах родительских собирать желающих, а отправлять на мобильный телефон пуш-уведомления, чтобы родитель мог нажать: «Да, хочу! Запишите моего ребенка» и сэкономить нам время на организации.

Пятый кейс – задача поддержки наших сотрудников, которые работают с другими ИТ-системами. Им нужно:

• Ставить тикеты – оформить заявку по образцу, приложить скриншоты, а потом узнать статус этой заявки.

• А внутри системы эти заявки должны категоризироваться – распределиться на ответственных за наши информационные системы специалистов, эскалироваться на следующую линию поддержки, если та или иная линия не успела отработать.

Шестой кейс – задачи инфраструктуры.

Например, в крупных интеграторах или у франчайзи часто встречается, что:

• По запросу разработчика нужно быстро развернуть базу клиента – достать ее из файлового хранилища и подготовить рабочее место, потому что разворачивание больших DT-шников занимает много времени.

• Или нужно автоматически доставить клиенту какую-то новую фичу, раскатать расширение.

• Или нужно мониторить, в каком состоянии находится инфраструктура у всех клиентов – собирать эту информацию в одном месте.

Здесь тоже задача на стыке, но уже не на стыке фронта и бэка, а на стыке бэк-офиса и инфраструктуры.

Седьмой кейс – это headless-сервисы. Тоже на стыке бизнес-логики и инфраструктуры.

• Мы можем создать сервис сбора информации об ошибках для наших клиентов. Настроить в базах клиентов, чтобы платформа 1С:Предприятие отправляла отчеты об ошибках на указанный HTTP-эндпоинт, и на стороне сервиса категоризировать эти ошибки, превращать в тикеты и дальше ими управлять.

• Либо мы хотим публиковать контент для своих клиентов особым образом – управлять доступом и гибко настраивать хранение, чтобы файлы были доступны только одному клиенту, какие-то – только в течение дня, а этот файл – только для однократного скачивания.

Что объединяет все перечисленные кейсы:

• Потребность в легком, быстром и интуитивно-понятном интерфейсе – естественно, там, где интерфейс применим (headless-сервисы на то и headless, что у них интерфейса нет).

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

• Но с другой стороны, в эти приложения встроена сложная бизнес-логика – по обработке заказов или предоставлению доступа к части данных каждому пользователю.

• И такие системы в большинстве случаев имеют интеграцию с системами бэк-офиса.

  • Если мы делаем личный кабинет сотрудника, очевидно, что мы интегрируемся с системой расчета заработной платы, с системой аттестации и тестирования сотрудников, с разными другими системами.

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

Почему 1С-разработчику проще, чем другим, решать подобные задачи

Давайте поищем среди специалистов, поддерживающих наш ИТ-ландшафт в целом – фронтенд-разработчиков, разработчиков бэк-офиса, инфраструктурщиков – тех, кто обладает наиболее подходящей полной квалификацией для решения этого спектра задач.

И здесь мы видим самих себя – 1С-разработчиков, которые работают в контуре бэк-офиса и умеют работать с прикладной областью:

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

• Мы владеем предметно-ориентированной разработкой. Мы умеем вплетать бизнес-логику и термины реального мира (той прикладной области, которую мы автоматизируем) в нашу информационную систему – в названия сущностей, в названия методов, в алгоритмы, реализованные в запросах. Эта бизнес-логика просматривается на всех слоях, не считая совсем низкоуровневого хранения данных.

• Мы умеем быстро разрабатывать за счет архитектуры 1С:Предприятия, в которую заложены решения типовых кейсов: хранение данных, обработка данных, интеграция и так далее. Мы можем за час-два построить простейшую учетную систему, накидать MVP на задачу, потому что у нас реализованы все слои: есть интерфейс, есть сервер бизнес-логики, есть сервер управления базами данных. Мы можем одной кнопкой масштабировать это с локального решения до клиент-серверного, способного работать под большой нагрузкой для большого объема пользователей.

• Мы в одиночку можем разрабатывать всю трехзвенную архитектуру. Мы на одном языке пишем фронт и бэк, а СУБД платформа берет на себя. В отличие от веб-команд, нам не нужно одновременно иметь фронтенд-разработчика, бэкенд-разработчика, дизайнера, DBA и других специалистов. У нас разработчик способен в одиночку быстро накидать решение задачи, и в будущем средствами платформы ее отмасштабировать.

Соединяя 1С-разработчика и платформу 1С:Предприятие.Элемент, которая имеет в себе все необходимое и для построения легких, быстрых, понятных интерфейсов, и для реализации Headless-сервисов, плюс представляет собой PaaS-платформу, мы получаем возможность решать все перечисленные задачи.

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

Ранее платформа 1С не позволяла нам решать эти задачи, а от фронтенд-разработчиков или инфраструктурщиков не получалось допроситься ресурсов, потому что им это делать долго, дорого, нужно проектировать, и вообще отвлекаться от своих задач не хочется. А теперь мы можем освоить новый спектр решений – новые области, в которые раньше не ходили.

Переиспользовать этот опыт нам позволяют общие принципы, по которым построена платформа 1С:Предприятие 8 и часть платформы 1С:Предприятие.Элемент:

• Разработка от привычных метаданных – у нас есть справочники, документы, регистры. Парадигма, которая заложена в платформу 1С:Предприятие 8, отражается и в 1С:Предприятие.Элемент. Это часть экосистемы – в ней общие абстракции, общие принципы работы, общие метаданные. Мы знаем, что такое справочник по опыту работы с «восьмеркой», и, работая с 1С:Предприятие.Элемент, для решения аналогичных задач тоже делаем справочник.

• Знакомые средства интеграции – HTTP-сервис, Web-сервис, который работает по протоколу SOAP, сериализация в XML и JSON, и так далее. Мы умеем это делать, мы то же самое можем сделать на 1С:Элементе.

• Один язык программирования для клиента и сервера. Безусловно, в 1С:Предприятие.Элемент язык не такой, как встроенный язык 1С:Предприятие 8, но общая концепция сохранена – в 1С:Элементе используется один язык, на котором мы пишем и клиентский, и серверный код, передаем управление с клиента на сервер. Все подходы наследуются.

• Декларативное описание интерфейса – то, к чему мы привыкли, разрабатывая управляемые формы.

• Киллер-фича платформы 1С:Предприятия – кастомизация прикладных решений. Мы можем взять готовое решение, например, 1С:Кабинет сотрудника, и добавить свои документы, свои процессы согласования, запилить там онбординг, предоставлять пользователю дополнительную информацию. Мы все это можем сделать силами своих 1С-разработчиков, используя те же принципы и приемы кастомизации, что и в 1С:Предприятии 8, сохраняя на будущее возможность безболезненного обновления.

Как начать разрабатывать на 1С:Элементе?

Определенные особенности технологии 1С:Элемент все равно придется изучить. Сюда входит:

• Статическая типизация и области видимости внутри языка.

• Компонентный подход к интерфейсу – с одной стороны, он сильно облегчает создание типовых форм, но требует определенного изучения и осознания.

• Подход к настройке прав доступа.

• Библиотечный подход к разработке решений в целом.

Давайте подробнее остановимся на каждом из этих пунктов.

Статическая типизация. Во встроенном языке 1С:Элемент, в отличие от 1С:Предприятия 8, используется статическая типизация. Это значит, что:

• При создании переменной сразу задается ее тип, и в дальнейшем он не может изменяться – если только изначально он не был объявлен как множественный.

• Аналогично, для метода мы указываем типы входных параметров и тип возвращаемого значения.

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

  • Например, если забыть в запросе обернуть поле в ЕСТЬNULL(), а потом передать его в арифметическую операцию, среда разработки сразу вычислит тип поля и скажет, что здесь может быть NULL. И мы сразу поймем, что забыли ЕСТЬNULL() и добавим его, либо поменяем соединение на внутреннее.

  • Или, если попытаться передать в метод программного интерфейса строку вместо числа, среда также подсветит ошибку – в отличие от «восьмерки», где преобразования происходят неявно и могут привести к неожиданным результатам (например, к появлению неразрывных пробелов). В 1С:Элементе неявное преобразование будет подсвечено, и мы сможем выбрать правильный способ для преобразования – оставить технический вариант без разделителей или выбрать представление для пользователя, которому с этими разделителями легче воспринимать числа.

• Статическая типизация минимизирует количество сложно диагностируемых ошибок, которые могут возникнуть на этапе сквозного тестирования, или когда мы работаем с несколькими библиотеками. Код становится более надежным: каждый метод получает строго те типы, структуры и объекты, которые ожидает. Мы можем быть уверены, что ошибки не вылезут в рантайме. Ну а понятно, что исправлять ошибку, которую мы поймали в рантайме, намного дольше и дороже, чем исправлять ошибку, которую мы поймали на этапе написания кода.

Компоненты интерфейса.

• Мы можем собрать определенный набор элементов в группу и сохранить ее как отдельный элемент проекта. А внутри этой группы реализовать свою бизнес-логику – свои обработчики, свой код на встроенном языке, запросы к базе данных, если необходимо.

• Эта группа будет работать изолированно, и ее целиком можно будет встраивать в другие формы, подсовывая ей определенные параметры, перехватывая в нужный момент от нее управление, обрабатывая те или иные события. Не нужно будет копировать группы элементов, не нужно в каждой форме программно прописывать создание элементов – мы просто сделали компонент, и технология автоматически тиражирует этот компонент по разным формам.

• Например, если мы делаем тот же кабинет сотрудника и хотим, чтобы в каждой заявке у нас добавилось кастомизируемое поле с контактами поддержки (звоните по такому-то телефону, пишите запросы в наш Telegram-бот) – мы один раз сделали компонент, пробросили во все формы, и все отлично работает.

Права доступа. Подход к правам доступа поменялся.

• Есть минимальный набор базовых прав для объекта – мы определяем, как с ним работать могут пользователи и администраторы. Например, администраторы могут изменять, а пользователи – только просматривать. Или просматривать и менять могут только администраторы, а пользователи – не могут. Или вообще с этим объектом имеют право работать неаутентифицированные пользователи – например, сохранять лид можно без регистрации.

• А дальше, если нам нужна более сложная логика, где мы говорим: эта часть пользователей может работать с объектом, а эта – не может. Это настраивается в программном коде – через их должности, подразделения, отдельно выданные права. В том числе для RLS (когда на часть записей в одной таблице пользователь имеет доступ, а на часть – не имеет) мы также настраиваем алгоритм во встроенном языке. В зависимости от подразделения, должности и галочек в регистрах пишем алгоритм, кому из пользователей выдать доступ, а кому – нет.

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

Область видимости. В 1С:Элементе для программного интерфейса можно ограничить видимость: библиотекой, проектом или подсистемой. Например, в 1С:Предприятии мы можем внутри одного общего модуля часть функций сделать экспортными, а часть – локальными, чтобы снаружи их вызвать было нельзя. А в 1С:Элементе для экспортных функций можно еще и детально настраивать область видимости:

• Например, указать, что эта экспортная функция доступна только в подсистеме – это служебный программный интерфейс, который используют объекты, общаясь между собой внутри подсистемы, но снаружи потребители его дергать не должны.

• Либо это в проекте. Например, мы пишем библиотеку – разные подсистемы одной библиотеки через этот программный интерфейс взаимодействовать друг с другом могут, но проект, в который мы встроили библиотеку, к этому программному интерфейсу обращаться не должен.

• И есть область видимости глобально. Значит, что в библиотеке есть программный интерфейс, который предназначен для вызова из проекта.

Таким образом, разработчик, реализуя модуль, объект, подсистему или библиотеку, определяет, что он готов сделать публичным интерфейсом своего решения, а что снаружи дергать не надо, поскольку мы не берем на себя обязательств это поддерживать.

Библиотечный подход.

• В 1С:Элементе одна подсистема или набор подсистем могут быть выделены как библиотека.

• В библиотеке определяется публичный интерфейс – методы и объекты с глобальной областью видимости. Далее эта библиотека может быть встроена в другие приложения – везде будут одни и те же функции, одни и те же интерфейсные формы.

• Библиотеками можно делиться с сообществом – уже сейчас есть готовые решения от сообщества. Нам не нужно вносить изменения внутрь библиотеки, чтобы интегрировать ее со своим решением. Это очень облегчает обновление. Если нам нужна новая версия библиотеки, мы просто меняем у себя в проекте импортируемую версию и пользуемся новой функциональностью. Если там сломалась где-то обратная совместимость, разработчики об этом расскажут, нам, понятно, все равно придется адаптировать. Но это контролируемо и без дополнительных транзакционных издержек.

С какой скоростью 1С-разработчик может освоить 1С:Предприятие.Элемент?

Решить первую элементарную задачу на 1С:Элементе – например, накидать личный кабинет, где можно оставлять заявки – можно в первый же день знакомства с ним. У нас есть те же документы, те же справочники, тот же автогенерируемый интерфейс, алгоритмы на языке 1С:Элемент, которые похожи на аналоги для 1С:Предприятие 8. И мы за день можем эту задачу решить. Без изысков, без сложных интеграций, без каких-то клевых интерфейсов, но задача будет решена. Если задача начать через два часа собирать заявки от клиентов, мы просто, как 1С-разработчик, развернули, накидали, поехали. Задача решена.

До уверенного владения инструментом по опыту разработчик доходит за один-два месяца. Но это уже будет уровень разработки промышленных решений, когда разработчик с опытом уверенной 1С-разработки способен осознанно разбираться, кастомизировать, решать более сложные задачи, строить сложные интерфейсы в 1С:Предприятие.Элемент. Когда через два месяца постоянной практики мы уже сможем писать и на «восьмерке», и на 1С:Элементе с одинаковой скоростью. Понятно, что на некоторые узкоспециализированные задачи все равно придется отвлекаться, искать, экспериментировать, но основную часть работы мы будем уже делать, переиспользуя навык.

Сделано на «Элементе»

Приведу примеры уже существующих на 1С:Предприятии.Элемент решений, которые подтверждают, что перечисленные кейсы действительно востребованы

Это приложения от самой фирмы «1С»:

• 1С:Кабинет сотрудника – для персонала,

• 1С:Персонал – для HR-подразделений,

• 1С:Управление ландшафтом – для управления инфраструктурой предприятия.

Headless-сервисы от фирмы 1С:

• Сервис 1C:Share, который встроен в типовые конфигурации и позволяет публиковать счета на оплату и давать на них ссылки своим покупателям.

• Сервисы «Региональные ставки» и «Формы статистики», которые создавались как промежуточное звено для взаимодействия с государственной информационной системой. Потому что если сразу миллион информационных баз в одно время начнут проверять формы статистики, они легко могут перегрузить систему. Поэтому локальные базы идут в Headless-сервис, написанный на 1С:Предприятие.Элемент, и берут подготовленную для них информацию, а сам сервис уже взаимодействует с государственной информационной системой напрямую. Таким образом мы сами контролируем нагрузку

• Сервис сборки мобильных приложений – им пользуются все, кто разрабатывает мобильные приложения на платформе 1С. Его можно открыть через «Все функции», ввести логин, пароль от портала developer.1c.ru, загрузить конфигурацию мобильного приложения и получить обратно APK-файл, готовый к установке. Очень удобно, экономит время и позволяет не разворачивать полностью инфраструктуру сборки мобильных приложений на своем локальном компьютере.

Реализовано множество приложений от партнеров, которые разрабатывают на технологии со времен бета-тестирования:

• B2B-порталы.

• Личные кабинеты перевозчиков.

• Корпоративные порталы для сотрудников.

• Публичные сервисы.

В середине страницы с информацией о технологии есть блок «Сделано на Элементе» с отзывами о внедренных решениях от конкретных компаний, где описаны задачи, которые они автоматизировали на базе 1С:Предприятие.Элемент.

И, безусловно, множество пет-проектов от сообщества – 1С:Элемент очень дружелюбен к разработке пет-проектов. Могу привести пару примеров из собственного опыта:

• Когда мы участвуем в мероприятиях для студентов, мы разрабатываем для стендов Telegram-ботов с прохождением квизов, квестов, филвордов, различными шахматными головоломками. Вся бизнес-логика таких проектов построена на 1С:Предприятие.Элемент с использованием библиотеки Telegram-бота, опубликованной в документации.

• Еще один пример – система проверки дипломных работ на конкурсе цифровых кафедр. Нужно было сделать удобный интерфейс для жюри, где они смогут выставлять оценки, а потом подвести общий итог. Это решения я собрал буквально за 3 часа: создал документ, настроил RLS по пользователям, чтобы каждый эксперт видел только то, что предназначено для проверки ему. Они все напроверяли, а мы потом через встроенную 1С:Элемент Аналитику посмотрели средние баллы и определили победителя. Раньше все оценки присылались на электронную почту, а потом все это сводилось вручную в Excel – при этом и мы на проверку, и жюри на выставление оценок тратили на порядок больше времени. Здесь экономия очевидна – цена разработки 2-3 часа.

Материалы для изучения

Начать разрабатывать на 1С:Элементе будет легче, если вы изучите:

• Видео на канале Учебного центра №1.

• Мастер-классы на портале для разработчиков developer.1c.ru.

• Курсы от Учебного центра №1 фирмы «1С».

• Множество материалов о разработке на 1С:Элемент от участников профессионального сообщества Инфостарт.

• Официальный чат по 1С:Элемент – там присутствуют разработчики технологии, и можно задавать им вопросы.

Новая технология вышла в релиз, пора начинать – заходите на https://1cmycloud.com/, регистрируйтесь и пробуйте.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.