Добро пожаловать в очередной выпуск Microsoft Knowledge на Getas. Я ваш ведущий, Мира Питерс. Итак, вот сценарий. Вы работаете в Business Central, и вам нужно внести одно небольшое изменение. Например, добавить поле в карточку клиента, изменить этап согласования или правила проверки заказа перед публикацией. Затем кто-то упоминает расширение AL, таблицы, страницы и модули кода, и внезапно ваш простой запрос звучит как совершенно новый язык. Конечно, это своего рода язык, но он вовсе не обязан казаться чем-то загадочным. Представьте Business Central в виде офисного здания. AL дает разработчикам инструкции по добавлению комнаты, формы или нового правила, не проламывая стены самого здания. Это и есть наша крупица знаний на сегодня. К концу этого выпуска вы поймете, что такое разработка на AL, зачем нужны расширения и как пользовательские доработки вписываются в Business Central. Почему компании адаптируют Business Central под себя? Бизнес Central уже обрабатывает множество ежедневных задач, финансы, клиентов, заказы на продажу, счета на товары, все в одной связанной системе вместо кучи электронных таблиц и разрозненных инструментов. Многим компаниям стандартной настройки хватает для выполнения большинства задач. Но вот в чем дело. Нет двух компаний, работающих абсолютно одинаково. Возьмем дистрибьютора продуктов питания, которому нужны данные о партиях, неиспользуемые другой компанией. Сервисной компании требуется особый процесс согласования перед выставлением счета. Ретейлер хочет внедрить уровни вознаграждения для скидок. А кому-то еще нужна форма с собственными формулировками полей и внутренними правилами.

Компания не будет менять свои бизнес-процессы ради одного недостающего поля. И вы вряд ли захотите, чтобы каждый мелкий запрос превращался в рискованное изменение всей системы целиком. Раньше это было большой проблемой. В старых системах разработчики открывали исходный код и правили его напрямую. И это работало до тех пор, пока не приходило следующее обновление. Затем компании приходилось совмещать новую версию от Microsoft с собственными изменениями, и кто-то должен был примирить все это, прежде чем обновление можно было установить. Представьте офис, где каждый арендатор прокладывает новые кабели сквозь стены без какого-либо плана. Некоторое время это работает, но когда зданию нужен ремонт, никто не знает, какой кабель кому принадлежит. Бизнес-централ идет другим путем. Вместо переписывания стандартного приложения разработчики создают отдельное дополнение, которое подключается к системе, сохраняя стандартную часть на месте, в то время как собственные изменения компании работают параллельно через поддерживаемые точки интеграции. Это разделение критически важно при выходе обновлений, поскольку Microsoft обновляет свою часть здания, а пользовательские доработки остаются в своем пространстве. Конечно, по-прежнему нужны тесты и исправления, это все-таки программное обеспечение, но от разработчика больше не требуется копировать и переделывать каждое изменение внутри исходного кода Microsoft. Итак, что именно бизнес адаптирует под себя?

Адаптации добавляют данные. Стандартная система не хранит, например, инструкции по доставке, внутренний рейтинг риска, уровень членства или ссылки на сторонние системы. Они также добавляют экраны, которые направляют сотрудников в процессе выполнения задачи в правильном порядке. Они обеспечивают соблюдение правил, например, блокируя заказ, если отсутствует обязательный документ. Индивидуальная настройка также помогает избежать ручных операций. Представьте, что сотрудники каждую пятницу копируют данные клиентов из бизнес-централ в другой инструмент, вручную проверяют условия и отправляют отчет руководителю. Грамотно выполненная доработка оставляет информацию в бизнес-централ, последовательно применяет правила и предоставляет сотрудникам кнопку или страницу, подходящую для их ежедневной работы. Давайте развеем один миф. Не стоит настраивать под себя абсолютно все. В стандартную версию бизнес-централ уже встроено множество процессов. Изменение чего-либо только потому, что это выглядит иначе, чем в старой системе, создает лишнюю работу в будущем. Таким образом, качественная доработка начинается с четкого бизнес-обоснования. С какой проблемой сталкиваются люди? Что должно происходить вместо этого?

И может ли стандартный продукт это сделать? Когда стандартный продукт не удовлетворяет эту потребность, в дело вступает EEL. EEL фокусируется непосредственно на бизнес-централ, считывая, добавляя и изменяя записи на уровне базы данных, одновременно контролируя происходящее на страницах, в отчетах и других частях приложения. Он вычисляет значения, перемещает данные и выводит сообщения об ошибках, если правила нарушаются в ходе процессов. Это большая нагрузка для одного языка, но EEL не универсальный инструмент для любого программного обеспечения, и вы не выберете его для создания публичного интернет-магазина, мобильной игры или отдельного настольного приложения. EEL существует для одной узкой задачи – настройки данных и поведения внутри бизнес-централ так, чтобы система соответствовала операционной деятельности компании. И именно это мы рассмотрим далее. EEL и расширение – безопасная модель дополнений. EEL расшифровывается как Application Language – язык приложений. Это язык программирования Microsoft для бизнес-централ, который дает разработчикам структурированный способ создания новых бизнес-функций или изменения поведения существующих частей системы. Но слово «расширение» не менее важно, чем EEL.

Расширение – это отдельное приложение, которое можно установить в бизнес-централ. В нем хранятся доработки компании, в то время как стандартное приложение бизнес-централ остается нетронутым. Думайте об этом не как о переписывании руководства, а скорее как о добавлении в него одобренных страниц. Да, страниц, которые следуют первоначальным правилам, не стирая их. Это может показаться технической деталью, но это меняет-то, как доработки живут с течением времени. Представьте, что компании нужен новый кабинет для специальной команды. Старый подход означал бы пробивание стены в главном здании и изменение самой структуры. Возможно, это решит проблему сегодня, но в будущем ремонт станет кошмаром, потому что исходное здание перестанет соответствовать своим чертежам. Расширение работает иначе. В здании уже есть двери, розетки и правила для добавления пространства. Вы строите новую комнату через эти утвержденные подключения. Комната принадлежит компании, но основное здание по-прежнему можно обслуживать, не разбирая все пользовательские стены. Именно так работают расширения Business Central. Базовое приложение содержит стандартные функции, предоставляемые Microsoft. Расширение может добавлять свои поля, экраны, кнопки, правила, отчеты и даже ссылки на другие системы. Оно может реагировать на определенные бизнес-действия, но делает это через поддерживаемые способы подключения к стандартному приложению. Поэтому границы встроены по умолчанию. И это хорошо. Без границ небольшой пользовательский запрос может проникнуть глубоко в области, которые не следует затрагивать. С расширениями разработчик работает с четкими типами объектов и определенными точками подключения, что облегчает понимание кода, если кому-то другому придется его читать позже. Этот подход также идеально подходит для облачной версии Business Central.

Microsoft регулярно обновляет сервис. Компании все равно нужно тестировать свое расширение после изменений, особенно если оно зависит от частей продукта, которые были изменены. Программное обеспечение никогда не отменяет необходимость ухода за ним. Но хранение пользовательского кода отдельно снижает вероятность того, что каждое обновление превратится в масштабную переделку старых модификаций. Вы можете услышать упоминание C-AL, когда люди говорят о старых системах Dynamics NAV. C-AL возникла из более ранней модели разработки, где разработчики часто меняли исходные объекты приложения напрямую. Многие компании годами успешно использовали системы таким образом, но это гораздо теснее связывало пользовательскую работу со стандартным кодом. Обновления требовали большого объема работы по сравнению и исправлению. A-L перевела Business Central на разработку на основе приложений. Это не означает, что каждое расширение является большим или сложным. Одно расширение может просто добавить поле в запись клиента и отобразить его на знакомом экране. Другое может содержать полноценное решение для конкретного вида бизнеса со своими записями, процессами, страницами и отчетами. Оба следуют одной и той же базовой идее. Пользовательское приложение существует рядом с Business Central, а не скрывает его переписанную версию. Вы также можете установить более одного расширения. Компания может использовать расширение от программного партнера для расчета заработной платы, другое для доставки и небольшое внутреннее расширение для правил, важных только для этой компании. Business Central объединяет их в одной рабочей системе, если они следуют правилам платформы и не конфликтуют друг с другом. Итак, A-L — это не просто способ написания кода. Это язык, который разработчики используют для создания таких дополнительных приложений, а расширение — это контейнер, который переносит эти изменения в Business Central. Эта модель позволяет компании адаптировать систему, сохраняя при этом стандартный продукт, узнаваемым и простым в обслуживании.

Теперь давайте откроем одно из этих расширений и рассмотрим его внутренние компоненты. Основные структурные элементы A-L внутри расширения A-L. Разработчики работают с объектами. Объект — это именованная часть приложения с четкой задачей, например, хранение информации, отображение экрана, выполнение правила или создание документа. Когда вы видите эти задачи по отдельности, A-L перестает казаться просто стеной кода. Начнем с места, где хранится бизнес-информация. В Business Central данные хранятся в таблицах. Представьте таблицу как цифровой картотечный шкаф для одного типа записей. В одном шкафу могут быть клиенты, в другом — товары, в третьем — заказы на продажу. Каждая запись — это один файл внутри такого шкафа. Таблица клиентов содержит по одной записи для каждого клиента. Таблица товаров содержит по одной записи для каждого продукта. Если вашей компании нужна информация, которую стандартный Business Central не хранит, расширение может создать собственную таблицу, например, для уровней вознаграждений, проверок оборудования или утверждения проектов. Поля — это именованные ячейки внутри каждой записи. Запись клиента может включать имя, адрес, условия оплаты и номер телефона, потому что таблица клиентов содержит поля для этих данных.

Поля могут содержать текст, даты, суммы, ответы «да» или «нет» или выбор из фиксированного списка. Поле также может указывать на другую запись. Например, в записи клиента может быть поле с идентификатором вознаграждения. Вместо того, чтобы вводить произвольный текст, сотрудники выбирают уровень вознаграждения из отдельной таблицы вознаграждений. Такая связь поддерживает частоту данных, поскольку все выбирают из одного и того же известного списка. Итак, таблицы хранят факты. Но как люди видят эти факты и работают с ними? Страницы. Страница — это экран, который вы открываете в Business Central. Карточка клиента — это страница. Список заказов на продажу — это страница. Страница контролирует, что пользователи могут просматривать, вводить, искать и с чем могут работать. Разные страницы подходят для разных задач. Страница карточки фокусируется на одной записи за раз. Например, на одном клиенте или товаре.

Страница списка показывает много записей в строках, что удобно для быстрого просмотра, фильтрации или поиска. Страница рабочего листа поддерживает работу, при которой люди вводят или обрабатывают несколько строк информации одновременно. Таблица хранит информацию. Страница предоставляет ее пользователю. Такое разделение полезно, поскольку вы можете изменить экран, не меняя расположение данных, или использовать одну и ту же таблицу на нескольких страницах, когда разным командам нужны разные представления одних и тех же записей. А что, если данные уже относятся к стандартной записи Business Central? Обычно вы не создаете новую таблицу клиентов только ради одного дополнительного поля. Вы используете расширение таблицы. Расширение таблицы добавляет ваше поле в существующую таблицу клиентов. Стандартная запись клиента остается на своем месте, а расширение добавляет специфические для компании детали рядом со стандартными полями. Это может быть ID вознаграждения, примечание к доставке, менеджер или поле, связанное с другим бизнес-процессом.

Но добавление поля в таблицу не выводит его автоматически на экран. Для этого используется расширение страницы. Расширение страницы добавляет поле, группу или действие на существующую страницу. Если сотруднику нужно выбрать уровень вознаграждения при просмотре клиента, расширение страницы разместит поле ID вознаграждения прямо на карточке клиента, где он уже работает. Это сохраняет привычный интерфейс. Вместо того, чтобы отправлять пользователей на отдельный экран для простой детали, расширение добавляет ее на уже знакомую страницу. Расширение страницы также может добавлять действие, кнопки или команды меню для запуска задач. Например, карточка клиента может содержать действие, вознаграждение, открывающее список наград. За кулисами интерфейса вам нужно место для бизнес-правил. Этим местом часто является код Юнит. Код Юнит содержит процедуры AL, именованные фрагменты кода, выполняющие конкретную задачу. Представьте это как бэк-офис, который выполняет работу по запросу страницы, отчета или другого процесса. Допустим, уровень вознаграждения определяет скидку для клиента. Расчет скидки должен находиться в код Юнит, а не на самой странице карточки клиента. Тогда процесс продаж, отчет или будущая страница смогут использовать это правило, не копируя его в разные места. Одно правило, одно место для его поддержки. Бизнес-централ также включает другие типы объектов для различных задач. Отчеты собирают данные и представляют их в виде документа или макета. Например, счета или отчета о продажах. Запросы, кверис, позволяют задавать точечные вопросы к данным. Например, какие клиенты заказывали определенный товар за перед. Например, XML-порты помогают импортировать или экспортировать данные в структурированном формате, когда системе нужно обменяться информацией с бизнес-централ. Собрав эти элементы вместе, можно представить небольшое расширение для программы лояльности. Таблица вознаграждений хранит каждый уровень и его процент скидки. Страницы вознаграждений позволяют персоналу управлять этими уровнями. Расширение таблицы клиентов добавляет ID вознаграждения каждому клиенту, а расширение карточки клиента отображает его. Действие на странице открывает список вознаграждений, а код Юнит вычисляет правила скидки. Каждый объект отвечает за свою часть работы. Это облегчает чтение, тестирование и изменение расширения, когда через полгода меняется бизнес-правило. Но бизнес-правило часто должно срабатывать в строго определенный момент, например, при проводке заказа. Именно здесь на помощь приходят трикгеры и события.

События, трикгеры и бизнес-правила. Итак, вы добавили поле вознаграждения клиента. Хорошо. А вот и главный вопрос. Когда именно бизнес-централ должен использовать это поле? Представьте, что вы собираетесь провести заказ на продажу. Перед тем, как система создаст итоговые записи, вы хотите выполнить дополнительную проверку. Может быть, клиенту нужен одобренный уровень вознаграждения, прежде чем скидка начнет действовать. Или, возможно, для продолжения работы с заказом должен существовать обязательный документ доставки. Вам нужна эта проверка в нужный момент, но вы не хотите копировать весь процесс проводки продаж в свое расширение только ради одного правила. Этот процесс уже выполняет множество операций в фоновом режиме. Если вы скопируете его, вашему расширению придется поддерживать все будущие изменения. Не самый лучший вариант. Поэтому EEL предлагает разработчикам несколько способов запуска кода. Выбор зависит от того, что именно должно произойти. Начнем с триггеров. Триггер – это именованное место внутри объекта EEL, где может выполняться код. Когда пользователь изменяет значение в поле таблицы, триггер запускает код. Когда страница открывается или закрывается, триггер запускает код. Отчеты, запросы, XML-порты, таблицы, расширения, EEO – во всех них есть такие места, куда разработчик может добавить правила. Возьмем поле ID вознаграждения в карточке клиента. Когда пользователь выбирает уровень вознаграждения, может сработать триггер проверки. Код проверяет, заблокирован ли клиент, существует ли такой уровень вознаграждения, нужно ли обновить другое поле. Проверка происходит сразу при изменении значения, а не позже, когда обнаружится ошибка. Триггеры хорошо работают, когда правило тесно связано с конкретным объектом. Но в бизнес-централ также используется событие. Событие похоже на уведомление. Одна часть приложения отправляет его, когда что-то происходит. Оно может сообщать о том, что запись вот-вот будет добавлена, документ будет проведен или процесс завершен. Ваше расширение может слушать это уведомление.

Код, который прослушивает событие, называется подписчиком событий. Он ожидает конкретное именованное событие. Когда бизнес-централ инициирует это событие, подписчик выполняет свою процедуру. Стандартный процесс сохраняет контроль. Например, когда бизнес-централ начинает проводку заказа на продажу, он инициирует событие, прежде чем продолжить работу. Ваше расширение для вознаграждений получает это уведомление. Оно проверяет идентификатор вознаграждения клиента и правила скидки. Затем оно либо позволяет процессу продолжиться, либо останавливает его с понятным сообщением. Стандартный процесс отражения операции по-прежнему принадлежит бизнес-централ. Ваше расширение просто добавляет свое специфическое правило компании в этой точке подключения. Вы часто будете слышать имена событий, такие как «да, on before» или «после on after». Да, означает, что ваш код выполняется до завершения действия. Это идеально подходит для проверки, которая может предотвратить следующий шаг. О, например, остановка заказа на продажу, если условие не выполняется. После означает, что действие уже произошло. Вы можете отреагировать, создать связанную запись, обновить примечание или начать другую работу. Имена указывают на время, а время имеет значение. Правило, которое выполняется после отражения, не может его предотвратить. Правило, которое выполняется слишком рано, может не иметь нужных данных. Поэтому разработчики выбирают события в зависимости от того, что и когда должно делать бизнес-правила. Код также может запускаться по действию. Пользователь нажимает кнопку, например, «проверить статус вознаграждения», и это действие вызывает процедуру. Код также может выполняться, когда один объект вызывает другой через переменную. Это звучит технически сложно, но все просто.

Одна часть расширения просит другую выполнить задачу. Переменные помогают в этом. Переменная — это именованное место, которое хранит значение во время выполнения кода. Это может быть число, текст, дата или даже запись бизнес-централ. Например, текущий клиент. В AEL вы объявляете их с помощью VAR. Например, процедура вознаграждений может использовать переменную с именем кастомер для хранения текущей записи клиента. Другая переменная — discount percent — содержит процент скидки. Это не постоянные записи, это просто рабочие значения для этого фрагмента кода. Вот что важно знать о том, где находится код. Если правило может использоваться в нескольких местах, поместите его в код unit. Таким образом, карточка клиента, процесс продаж и отчет могут вызывать одну и ту же процедуру скидки, а не иметь каждой свою версию. Это позволяет избежать типичной проблемы. На одном экране применяется скидка 10%, на другом — 5%. И никто не знает, какому правилу верить. Хранение общих бизнес-правил в одном код unit дает расширению единый источник истины. Итак, триггеры обрабатывают правила, близкие к объекту. События позволяют расширению реагировать на собственные процессы бизнес-централ. Коди unit объединяют общую логику. Когда эти части соединены, возникает вопрос, где разработчики пишут, тестируют и проверяют весь этот AEL код. Разработка на AEL обычно происходит в Visual Studio Code, часто называемом VS Code. Это ваше рабочее пространство для написания файлов AEL. Оно помогает поддерживать порядок в расширении. Оно помогает находить проблемы и отправляет готовые приложения в среду бизнес-централ для тестирования. Но сам по себе VS Code — это лишь обычный редактор кода. Для него требуется расширение языка AEL от Microsoft. Это расширение объясняет VS Code, как работает бизнес-централ. Оно может предлагать имена объектов во время ввода. Оно указывает на ошибки до публикации. Оно помогает просматривать поля и процедуры. И оно подключает ваш проект к среде бизнес-централ. Это избавляет от многих догадок. Когда вы начинаете новый проект AEL, вы можете выполнить команду AEL Go в VS Code. Она создает базовую папку проекта и файлы настроек, имя расширения AEL, издателя, версию и среду бизнес-централ для использования. Представьте эту папку проекта как верстак для расширения. Каждый файл AEL должен находиться там. Один файл может содержать таблицу, другой — расширение страницы, а CodeUnit может иметь собственный файл. Таким образом, когда кто-то открывает проект, он может найти нужную часть, не прокручивая один огромный документ.

Когда код готов к тестированию, VS Code компилирует его в пакет приложения. Это устанавливаемая версия расширения. Бизнес-централ считывает этот пакет и добавляет расширение в среду. Если отсутствует поле, допущена опечатка или возникла любая другая проблема, препятствующая сборке, VS Code сообщит вам об этом до того, как пакет попадет в бизнес-централ. Тестирование должно сначала проводиться в песочнице. Песочница — это отдельная среда бизнес-централ, где можно опробовать изменения, не рискуя реальной рабочей деятельностью. Вы публикуете расширение, открываете страницы, вносите изменения, вводите тестовые записи и проверяете, работают ли правила должным образом. Такое разделение важно. Вы же не хотите обнаружить, что новые правила проверки блокируют заказы на продажу, пока сотрудники пытаются выполнять свою работу. В песочнице можно совершать ошибки, удалять тестовые данные, изменять код и публиковать его снова, не затрагивая реальные записи. Иногда код выполняется, но результат все равно выглядит неверным. Вот тогда на помощь приходит отладка. Вы ставите точку останова в коде, запускаете процесс, и расширение приостанавливается во время работы. В этой паузе можно проверить значение, например, текущего клиента, выбранный уровень вознаграждения или процент скидки, рассчитанный процедурой. Вместо того, чтобы гадать, почему правило не сработало, вы можете точно увидеть, что получил код. Команды разработчиков также используют гид для ведения истории своей работы.

Гид записывает изменения в файлах проекта с течением времени. Если кто-то изменит правила и возникнет проблема, команда сможет сравнить версии, увидеть изменения и при необходимости откатить их. Это также помогает, когда над одним расширением работает несколько разработчиков. Для новичка лучший путь – начинать с малого. Сначала изучите бизнес-централ, затем создайте одну таблицу и одну страницу. После этого расширьте стандартную страницу, добавьте простое бизнес-правило и узнайте, как события и установочные данные вписываются в проект. Далее давайте свяжем эти элементы в небольшое дополнение, которое бизнес мог бы реально использовать. Простой пример – создание дополнения для поощрения клиентов. Как на самом деле выглядит настоящее расширение на EEL? Давайте погрузимся в простой пример. Представьте, что вашей компании нужны уровни поощрения клиентов, каждый со своей скидкой. Вы начинаете с создания таблицы поощрений. Представьте ее как цифровой картотечный шкаф, где в каждой карточке есть ID, описание и процент скидки. Например, золотой уровень дает скидку 10%. Вашим сотрудникам нужно управлять этими уровнями, не прибегая к техническим инструментам. Поэтому вы добавляете две страницы – список поощрений для просмотра всех уровней и карточку поощрения для редактирования или создания. Они могут добавить новый уровень, изменить процент или просмотреть текущие данные без открытия среды разработки. Затем вы расширяете таблицу клиентов новым полем под названием ID поощрения. Это поле связывает каждого клиента с одной записью поощрения, и вы размещаете его прямо на странице карточки клиента, где сотрудники уже управляют данными клиентов. Далее вы добавляете действия поощрения, чтобы они могли открыть список поощрений прямо из той же карточки. Само правило расчета скидки находится внутри модуля кода – CodeUnit. Когда другому процессу требуется скидка клиента, он обращается к этому модулю вместо того, чтобы вычислять ее снова и снова на каждой странице. Это эффективно. Установочный модуль кода добавляет начальные уровни поощрения при первой установке вашего расширения. А подписчик событий проверяет выбранный уровень поощрения во время процесса продаж, применяя правила вашей компании в нужный момент. Это небольшое расширение, но заметьте, что оно содержит. Таблицы данных, экраны пользователей, действия навигации, логику настройки и бизнес-правила. Все это работает вместе. В этом и заключается настоящая сила EEL. Хорошо, заключение – ваша отправная точка в разработке на EEL. Итак, вот основные выводы.

Разработка на EEL позволяет добавлять в бизнес-централ специфические функции, необходимые вашей компании, не затрагивая основное приложение. И вам не нужно создавать все сразу. Начните с одного поля, одного расширения страницы и одного четкого правила. Это ваш первый строительный блок. Если этот полезный совет оказался для вас ценным, подпишитесь на удобной вам платформе для подкастов и поделитесь им с теми, кто только начинает свой путь в разработке бизнес-централ. Присоединяйтесь к нам в следующий раз, когда мы добавим еще один фрагмент в общую картину. С вами был Мерка Питерс и еще один эпизод Microsoft Knowledge на Гетас на М365FM.