WEBVTT

00:00:00.000 --> 00:00:04.220
Добро пожаловать в очередной выпуск Microsoft Knowledge на Getas. Я ваш ведущий, Мира Питерс.

00:00:04.320 --> 00:00:08.800
Итак, вот сценарий. Вы работаете в Business Central, и вам нужно внести одно небольшое изменение.

00:00:08.980 --> 00:00:13.380
Например, добавить поле в карточку клиента, изменить этап согласования или правила проверки

00:00:13.380 --> 00:00:18.440
заказа перед публикацией. Затем кто-то упоминает расширение AL, таблицы, страницы и модули кода,

00:00:18.680 --> 00:00:22.860
и внезапно ваш простой запрос звучит как совершенно новый язык. Конечно, это своего рода язык,

00:00:22.960 --> 00:00:26.700
но он вовсе не обязан казаться чем-то загадочным. Представьте Business Central в виде офисного

00:00:26.700 --> 00:00:31.180
здания. AL дает разработчикам инструкции по добавлению комнаты, формы или нового правила,

00:00:31.360 --> 00:00:35.200
не проламывая стены самого здания. Это и есть наша крупица знаний на сегодня.

00:00:35.400 --> 00:00:39.600
К концу этого выпуска вы поймете, что такое разработка на AL, зачем нужны расширения и как

00:00:39.600 --> 00:00:43.280
пользовательские доработки вписываются в Business Central. Почему компании адаптируют

00:00:43.280 --> 00:00:46.540
Business Central под себя? Бизнес Central уже обрабатывает множество ежедневных задач,

00:00:46.700 --> 00:00:50.140
финансы, клиентов, заказы на продажу, счета на товары, все в одной связанной системе вместо

00:00:50.140 --> 00:00:53.680
кучи электронных таблиц и разрозненных инструментов. Многим компаниям стандартной настройки

00:00:53.680 --> 00:00:57.160
хватает для выполнения большинства задач. Но вот в чем дело. Нет двух компаний,

00:00:57.340 --> 00:01:00.060
работающих абсолютно одинаково. Возьмем дистрибьютора продуктов питания,

00:01:00.180 --> 00:01:03.780
которому нужны данные о партиях, неиспользуемые другой компанией. Сервисной компании требуется

00:01:03.780 --> 00:01:08.320
особый процесс согласования перед выставлением счета. Ретейлер хочет внедрить уровни вознаграждения

00:01:08.320 --> 00:01:13.000
для скидок. А кому-то еще нужна форма с собственными формулировками полей и внутренними правилами.

00:01:13.180 --> 00:01:17.320
Компания не будет менять свои бизнес-процессы ради одного недостающего поля. И вы вряд ли захотите,

00:01:17.520 --> 00:01:20.720
чтобы каждый мелкий запрос превращался в рискованное изменение всей системы целиком.

00:01:20.720 --> 00:01:25.120
Раньше это было большой проблемой. В старых системах разработчики открывали исходный код и

00:01:25.120 --> 00:01:28.940
правили его напрямую. И это работало до тех пор, пока не приходило следующее обновление.

00:01:29.180 --> 00:01:33.200
Затем компании приходилось совмещать новую версию от Microsoft с собственными изменениями,

00:01:33.300 --> 00:01:36.760
и кто-то должен был примирить все это, прежде чем обновление можно было установить.

00:01:36.880 --> 00:01:41.140
Представьте офис, где каждый арендатор прокладывает новые кабели сквозь стены без какого-либо

00:01:41.140 --> 00:01:45.280
плана. Некоторое время это работает, но когда зданию нужен ремонт, никто не знает,

00:01:45.520 --> 00:01:49.480
какой кабель кому принадлежит. Бизнес-централ идет другим путем. Вместо переписывания

00:01:49.480 --> 00:01:53.180
стандартного приложения разработчики создают отдельное дополнение, которое подключается к

00:01:53.180 --> 00:01:56.800
системе, сохраняя стандартную часть на месте, в то время как собственные изменения компании

00:01:56.800 --> 00:02:00.540
работают параллельно через поддерживаемые точки интеграции. Это разделение критически важно

00:02:00.540 --> 00:02:04.600
при выходе обновлений, поскольку Microsoft обновляет свою часть здания, а пользовательские доработки

00:02:04.600 --> 00:02:08.540
остаются в своем пространстве. Конечно, по-прежнему нужны тесты и исправления, это все-таки

00:02:08.540 --> 00:02:12.240
программное обеспечение, но от разработчика больше не требуется копировать и переделывать каждое

00:02:12.240 --> 00:02:16.260
изменение внутри исходного кода Microsoft. Итак, что именно бизнес адаптирует под себя?

00:02:16.260 --> 00:02:20.700
Адаптации добавляют данные. Стандартная система не хранит, например, инструкции по доставке,

00:02:20.860 --> 00:02:24.720
внутренний рейтинг риска, уровень членства или ссылки на сторонние системы. Они также добавляют

00:02:24.720 --> 00:02:27.660
экраны, которые направляют сотрудников в процессе выполнения задачи в правильном порядке.

00:02:27.820 --> 00:02:31.320
Они обеспечивают соблюдение правил, например, блокируя заказ, если отсутствует обязательный

00:02:31.320 --> 00:02:35.100
документ. Индивидуальная настройка также помогает избежать ручных операций. Представьте,

00:02:35.100 --> 00:02:38.880
что сотрудники каждую пятницу копируют данные клиентов из бизнес-централ в другой инструмент,

00:02:39.080 --> 00:02:42.640
вручную проверяют условия и отправляют отчет руководителю. Грамотно выполненная доработка

00:02:42.640 --> 00:02:46.260
оставляет информацию в бизнес-централ, последовательно применяет правила и предоставляет сотрудникам

00:02:46.260 --> 00:02:50.360
кнопку или страницу, подходящую для их ежедневной работы. Давайте развеем один миф. Не стоит

00:02:50.360 --> 00:02:54.300
настраивать под себя абсолютно все. В стандартную версию бизнес-централ уже встроено множество

00:02:54.300 --> 00:02:57.380
процессов. Изменение чего-либо только потому, что это выглядит иначе, чем в старой системе,

00:02:57.460 --> 00:03:00.600
создает лишнюю работу в будущем. Таким образом, качественная доработка начинается с четкого

00:03:00.600 --> 00:03:04.760
бизнес-обоснования. С какой проблемой сталкиваются люди? Что должно происходить вместо этого?

00:03:04.920 --> 00:03:09.000
И может ли стандартный продукт это сделать? Когда стандартный продукт не удовлетворяет эту

00:03:09.000 --> 00:03:12.780
потребность, в дело вступает EEL. EEL фокусируется непосредственно на бизнес-централ,

00:03:12.940 --> 00:03:16.800
считывая, добавляя и изменяя записи на уровне базы данных, одновременно контролируя происходящее

00:03:16.800 --> 00:03:21.220
на страницах, в отчетах и других частях приложения. Он вычисляет значения, перемещает данные и

00:03:21.220 --> 00:03:25.820
выводит сообщения об ошибках, если правила нарушаются в ходе процессов. Это большая нагрузка для одного

00:03:25.820 --> 00:03:30.240
языка, но EEL не универсальный инструмент для любого программного обеспечения, и вы не выберете его для

00:03:30.240 --> 00:03:34.100
создания публичного интернет-магазина, мобильной игры или отдельного настольного приложения.

00:03:34.100 --> 00:03:38.460
EEL существует для одной узкой задачи – настройки данных и поведения внутри бизнес-централ так,

00:03:38.640 --> 00:03:42.660
чтобы система соответствовала операционной деятельности компании. И именно это мы рассмотрим

00:03:42.660 --> 00:03:47.380
далее. EEL и расширение – безопасная модель дополнений. EEL расшифровывается как

00:03:47.380 --> 00:03:52.000
Application Language – язык приложений. Это язык программирования Microsoft для бизнес-централ,

00:03:52.040 --> 00:03:56.040
который дает разработчикам структурированный способ создания новых бизнес-функций или изменения

00:03:56.040 --> 00:04:00.500
поведения существующих частей системы. Но слово «расширение» не менее важно, чем EEL.

00:04:00.680 --> 00:04:03.860
Расширение – это отдельное приложение, которое можно установить в бизнес-централ.

00:04:03.860 --> 00:04:06.940
В нем хранятся доработки компании, в то время как стандартное приложение

00:04:06.940 --> 00:04:10.360
бизнес-централ остается нетронутым. Думайте об этом не как о переписывании руководства,

00:04:10.480 --> 00:04:14.360
а скорее как о добавлении в него одобренных страниц. Да, страниц, которые следуют первоначальным

00:04:14.360 --> 00:04:17.620
правилам, не стирая их. Это может показаться технической деталью, но это меняет-то,

00:04:17.700 --> 00:04:21.320
как доработки живут с течением времени. Представьте, что компании нужен новый кабинет

00:04:21.320 --> 00:04:25.540
для специальной команды. Старый подход означал бы пробивание стены в главном здании и изменение

00:04:25.540 --> 00:04:29.800
самой структуры. Возможно, это решит проблему сегодня, но в будущем ремонт станет кошмаром,

00:04:29.800 --> 00:04:33.820
потому что исходное здание перестанет соответствовать своим чертежам. Расширение работает

00:04:33.820 --> 00:04:38.800
иначе. В здании уже есть двери, розетки и правила для добавления пространства. Вы строите новую

00:04:38.800 --> 00:04:42.720
комнату через эти утвержденные подключения. Комната принадлежит компании, но основное здание

00:04:42.720 --> 00:04:46.380
по-прежнему можно обслуживать, не разбирая все пользовательские стены. Именно так работают

00:04:46.380 --> 00:04:50.600
расширения Business Central. Базовое приложение содержит стандартные функции, предоставляемые

00:04:50.600 --> 00:04:55.620
Microsoft. Расширение может добавлять свои поля, экраны, кнопки, правила, отчеты и даже ссылки на другие

00:04:55.620 --> 00:04:59.700
системы. Оно может реагировать на определенные бизнес-действия, но делает это через поддерживаемые

00:04:59.700 --> 00:05:04.020
способы подключения к стандартному приложению. Поэтому границы встроены по умолчанию. И это

00:05:04.020 --> 00:05:07.540
хорошо. Без границ небольшой пользовательский запрос может проникнуть глубоко в области,

00:05:07.700 --> 00:05:11.140
которые не следует затрагивать. С расширениями разработчик работает с четкими типами

00:05:11.140 --> 00:05:15.640
объектов и определенными точками подключения, что облегчает понимание кода, если кому-то другому

00:05:15.640 --> 00:05:20.140
придется его читать позже. Этот подход также идеально подходит для облачной версии Business Central.

00:05:20.320 --> 00:05:23.960
Microsoft регулярно обновляет сервис. Компании все равно нужно тестировать свое

00:05:23.960 --> 00:05:27.540
расширение после изменений, особенно если оно зависит от частей продукта, которые были

00:05:27.540 --> 00:05:31.280
изменены. Программное обеспечение никогда не отменяет необходимость ухода за ним. Но хранение

00:05:31.280 --> 00:05:34.940
пользовательского кода отдельно снижает вероятность того, что каждое обновление превратится в

00:05:34.940 --> 00:05:39.400
масштабную переделку старых модификаций. Вы можете услышать упоминание C-AL, когда люди говорят о

00:05:39.400 --> 00:05:44.740
старых системах Dynamics NAV. C-AL возникла из более ранней модели разработки, где разработчики часто

00:05:44.740 --> 00:05:49.160
меняли исходные объекты приложения напрямую. Многие компании годами успешно использовали системы таким

00:05:49.160 --> 00:05:53.380
образом, но это гораздо теснее связывало пользовательскую работу со стандартным кодом. Обновления требовали

00:05:53.380 --> 00:05:57.440
большого объема работы по сравнению и исправлению. A-L перевела Business Central на разработку на

00:05:57.440 --> 00:06:01.660
основе приложений. Это не означает, что каждое расширение является большим или сложным. Одно

00:06:01.660 --> 00:06:06.040
расширение может просто добавить поле в запись клиента и отобразить его на знакомом экране. Другое

00:06:06.040 --> 00:06:10.520
может содержать полноценное решение для конкретного вида бизнеса со своими записями, процессами,

00:06:10.680 --> 00:06:14.960
страницами и отчетами. Оба следуют одной и той же базовой идее. Пользовательское приложение

00:06:14.960 --> 00:06:19.240
существует рядом с Business Central, а не скрывает его переписанную версию. Вы также можете установить

00:06:19.240 --> 00:06:23.320
более одного расширения. Компания может использовать расширение от программного партнера для расчета

00:06:23.320 --> 00:06:27.360
заработной платы, другое для доставки и небольшое внутреннее расширение для правил, важных только

00:06:27.360 --> 00:06:31.880
для этой компании. Business Central объединяет их в одной рабочей системе, если они следуют правилам

00:06:31.880 --> 00:06:36.760
платформы и не конфликтуют друг с другом. Итак, A-L — это не просто способ написания кода. Это язык,

00:06:36.860 --> 00:06:40.340
который разработчики используют для создания таких дополнительных приложений, а расширение — это

00:06:40.340 --> 00:06:44.260
контейнер, который переносит эти изменения в Business Central. Эта модель позволяет компании адаптировать

00:06:44.260 --> 00:06:47.480
систему, сохраняя при этом стандартный продукт, узнаваемым и простым в обслуживании.

00:06:47.480 --> 00:06:51.280
Теперь давайте откроем одно из этих расширений и рассмотрим его внутренние компоненты.

00:06:51.280 --> 00:06:56.220
Основные структурные элементы A-L внутри расширения A-L. Разработчики работают с объектами.

00:06:56.380 --> 00:07:00.100
Объект — это именованная часть приложения с четкой задачей, например, хранение информации,

00:07:00.320 --> 00:07:04.300
отображение экрана, выполнение правила или создание документа. Когда вы видите эти задачи по

00:07:04.300 --> 00:07:09.540
отдельности, A-L перестает казаться просто стеной кода. Начнем с места, где хранится бизнес-информация.

00:07:09.720 --> 00:07:14.040
В Business Central данные хранятся в таблицах. Представьте таблицу как цифровой картотечный шкаф

00:07:14.040 --> 00:07:19.060
для одного типа записей. В одном шкафу могут быть клиенты, в другом — товары, в третьем — заказы на продажу.

00:07:19.060 --> 00:07:23.900
Каждая запись — это один файл внутри такого шкафа. Таблица клиентов содержит по одной записи для

00:07:23.900 --> 00:07:28.300
каждого клиента. Таблица товаров содержит по одной записи для каждого продукта. Если вашей

00:07:28.300 --> 00:07:32.500
компании нужна информация, которую стандартный Business Central не хранит, расширение может создать

00:07:32.500 --> 00:07:36.200
собственную таблицу, например, для уровней вознаграждений, проверок оборудования или

00:07:36.200 --> 00:07:41.400
утверждения проектов. Поля — это именованные ячейки внутри каждой записи. Запись клиента может включать

00:07:41.400 --> 00:07:46.740
имя, адрес, условия оплаты и номер телефона, потому что таблица клиентов содержит поля для этих данных.

00:07:46.740 --> 00:07:51.780
Поля могут содержать текст, даты, суммы, ответы «да» или «нет» или выбор из фиксированного списка.

00:07:51.920 --> 00:07:55.680
Поле также может указывать на другую запись. Например, в записи клиента может быть поле с

00:07:55.680 --> 00:07:59.160
идентификатором вознаграждения. Вместо того, чтобы вводить произвольный текст, сотрудники выбирают

00:07:59.160 --> 00:08:02.360
уровень вознаграждения из отдельной таблицы вознаграждений. Такая связь поддерживает частоту

00:08:02.360 --> 00:08:06.340
данных, поскольку все выбирают из одного и того же известного списка. Итак, таблицы хранят факты.

00:08:06.440 --> 00:08:08.320
Но как люди видят эти факты и работают с ними?

00:08:08.580 --> 00:08:12.880
Страницы. Страница — это экран, который вы открываете в Business Central. Карточка клиента — это страница.

00:08:12.880 --> 00:08:16.300
Список заказов на продажу — это страница. Страница контролирует, что пользователи могут

00:08:16.300 --> 00:08:20.000
просматривать, вводить, искать и с чем могут работать. Разные страницы подходят для разных задач.

00:08:20.220 --> 00:08:24.120
Страница карточки фокусируется на одной записи за раз. Например, на одном клиенте или товаре.

00:08:24.240 --> 00:08:28.200
Страница списка показывает много записей в строках, что удобно для быстрого просмотра,

00:08:28.340 --> 00:08:32.500
фильтрации или поиска. Страница рабочего листа поддерживает работу, при которой люди вводят

00:08:32.500 --> 00:08:36.240
или обрабатывают несколько строк информации одновременно. Таблица хранит информацию.

00:08:36.480 --> 00:08:40.480
Страница предоставляет ее пользователю. Такое разделение полезно, поскольку вы можете

00:08:40.480 --> 00:08:44.500
изменить экран, не меняя расположение данных, или использовать одну и ту же таблицу на нескольких

00:08:44.500 --> 00:08:48.040
страницах, когда разным командам нужны разные представления одних и тех же записей.

00:08:48.140 --> 00:08:51.280
А что, если данные уже относятся к стандартной записи Business Central?

00:08:51.460 --> 00:08:55.040
Обычно вы не создаете новую таблицу клиентов только ради одного дополнительного поля.

00:08:55.160 --> 00:08:59.360
Вы используете расширение таблицы. Расширение таблицы добавляет ваше поле в существующую

00:08:59.360 --> 00:09:03.500
таблицу клиентов. Стандартная запись клиента остается на своем месте, а расширение добавляет

00:09:03.500 --> 00:09:07.640
специфические для компании детали рядом со стандартными полями. Это может быть ID вознаграждения,

00:09:07.640 --> 00:09:11.340
примечание к доставке, менеджер или поле, связанное с другим бизнес-процессом.

00:09:11.440 --> 00:09:15.540
Но добавление поля в таблицу не выводит его автоматически на экран. Для этого используется

00:09:15.540 --> 00:09:19.740
расширение страницы. Расширение страницы добавляет поле, группу или действие на существующую

00:09:19.740 --> 00:09:23.360
страницу. Если сотруднику нужно выбрать уровень вознаграждения при просмотре клиента,

00:09:23.540 --> 00:09:27.020
расширение страницы разместит поле ID вознаграждения прямо на карточке клиента,

00:09:27.200 --> 00:09:31.760
где он уже работает. Это сохраняет привычный интерфейс. Вместо того, чтобы отправлять пользователей на

00:09:31.760 --> 00:09:35.740
отдельный экран для простой детали, расширение добавляет ее на уже знакомую страницу.

00:09:35.740 --> 00:09:40.140
Расширение страницы также может добавлять действие, кнопки или команды меню для запуска

00:09:40.140 --> 00:09:44.640
задач. Например, карточка клиента может содержать действие, вознаграждение, открывающее список

00:09:44.640 --> 00:09:48.940
наград. За кулисами интерфейса вам нужно место для бизнес-правил. Этим местом часто является

00:09:48.940 --> 00:09:53.500
код Юнит. Код Юнит содержит процедуры AL, именованные фрагменты кода, выполняющие конкретную

00:09:53.500 --> 00:09:58.360
задачу. Представьте это как бэк-офис, который выполняет работу по запросу страницы, отчета или

00:09:58.360 --> 00:10:04.000
другого процесса. Допустим, уровень вознаграждения определяет скидку для клиента. Расчет скидки должен

00:10:04.000 --> 00:10:09.280
находиться в код Юнит, а не на самой странице карточки клиента. Тогда процесс продаж, отчет или

00:10:09.280 --> 00:10:13.940
будущая страница смогут использовать это правило, не копируя его в разные места. Одно правило,

00:10:14.120 --> 00:10:18.300
одно место для его поддержки. Бизнес-централ также включает другие типы объектов для различных

00:10:18.300 --> 00:10:22.000
задач. Отчеты собирают данные и представляют их в виде документа или макета. Например,

00:10:22.200 --> 00:10:26.380
счета или отчета о продажах. Запросы, кверис, позволяют задавать точечные вопросы к данным. Например,

00:10:26.560 --> 00:10:30.860
какие клиенты заказывали определенный товар за перед. Например, XML-порты помогают импортировать

00:10:30.860 --> 00:10:34.820
или экспортировать данные в структурированном формате, когда системе нужно обменяться информацией

00:10:34.820 --> 00:10:38.780
с бизнес-централ. Собрав эти элементы вместе, можно представить небольшое расширение для программы

00:10:38.780 --> 00:10:42.720
лояльности. Таблица вознаграждений хранит каждый уровень и его процент скидки. Страницы

00:10:42.720 --> 00:10:46.680
вознаграждений позволяют персоналу управлять этими уровнями. Расширение таблицы клиентов добавляет

00:10:46.680 --> 00:10:51.180
ID вознаграждения каждому клиенту, а расширение карточки клиента отображает его. Действие на странице

00:10:51.180 --> 00:10:56.360
открывает список вознаграждений, а код Юнит вычисляет правила скидки. Каждый объект отвечает за свою часть

00:10:56.360 --> 00:11:01.280
работы. Это облегчает чтение, тестирование и изменение расширения, когда через полгода меняется

00:11:01.280 --> 00:11:04.820
бизнес-правило. Но бизнес-правило часто должно срабатывать в строго определенный момент,

00:11:05.020 --> 00:11:08.480
например, при проводке заказа. Именно здесь на помощь приходят трикгеры и события.

00:11:08.600 --> 00:11:12.360
События, трикгеры и бизнес-правила. Итак, вы добавили поле вознаграждения клиента.

00:11:12.500 --> 00:11:16.200
Хорошо. А вот и главный вопрос. Когда именно бизнес-централ должен использовать это поле?

00:11:16.300 --> 00:11:19.980
Представьте, что вы собираетесь провести заказ на продажу. Перед тем, как система создаст итоговые записи,

00:11:20.120 --> 00:11:23.100
вы хотите выполнить дополнительную проверку. Может быть, клиенту нужен одобренный уровень

00:11:23.100 --> 00:11:27.440
вознаграждения, прежде чем скидка начнет действовать. Или, возможно, для продолжения работы с заказом

00:11:27.440 --> 00:11:31.240
должен существовать обязательный документ доставки. Вам нужна эта проверка в нужный момент,

00:11:31.440 --> 00:11:35.100
но вы не хотите копировать весь процесс проводки продаж в свое расширение только ради одного

00:11:35.100 --> 00:11:39.320
правила. Этот процесс уже выполняет множество операций в фоновом режиме. Если вы скопируете его,

00:11:39.500 --> 00:11:42.980
вашему расширению придется поддерживать все будущие изменения. Не самый лучший вариант.

00:11:43.140 --> 00:11:46.780
Поэтому EEL предлагает разработчикам несколько способов запуска кода. Выбор зависит от того,

00:11:46.960 --> 00:11:51.600
что именно должно произойти. Начнем с триггеров. Триггер – это именованное место внутри объекта EEL,

00:11:51.600 --> 00:11:55.920
где может выполняться код. Когда пользователь изменяет значение в поле таблицы, триггер запускает

00:11:55.920 --> 00:11:59.780
код. Когда страница открывается или закрывается, триггер запускает код. Отчеты, запросы,

00:11:59.860 --> 00:12:03.540
XML-порты, таблицы, расширения, EEO – во всех них есть такие места, куда разработчик может добавить

00:12:03.540 --> 00:12:07.260
правила. Возьмем поле ID вознаграждения в карточке клиента. Когда пользователь выбирает уровень

00:12:07.260 --> 00:12:10.980
вознаграждения, может сработать триггер проверки. Код проверяет, заблокирован ли клиент,

00:12:11.160 --> 00:12:15.540
существует ли такой уровень вознаграждения, нужно ли обновить другое поле. Проверка происходит сразу

00:12:15.540 --> 00:12:19.460
при изменении значения, а не позже, когда обнаружится ошибка. Триггеры хорошо работают,

00:12:19.580 --> 00:12:23.140
когда правило тесно связано с конкретным объектом. Но в бизнес-централ также используется

00:12:23.140 --> 00:12:27.120
событие. Событие похоже на уведомление. Одна часть приложения отправляет его,

00:12:27.340 --> 00:12:31.380
когда что-то происходит. Оно может сообщать о том, что запись вот-вот будет добавлена,

00:12:31.640 --> 00:12:36.220
документ будет проведен или процесс завершен. Ваше расширение может слушать это уведомление.

00:12:36.420 --> 00:12:40.100
Код, который прослушивает событие, называется подписчиком событий. Он ожидает конкретное

00:12:40.100 --> 00:12:43.900
именованное событие. Когда бизнес-централ инициирует это событие, подписчик выполняет

00:12:43.900 --> 00:12:47.840
свою процедуру. Стандартный процесс сохраняет контроль. Например, когда бизнес-централ начинает

00:12:47.840 --> 00:12:50.700
проводку заказа на продажу, он инициирует событие, прежде чем продолжить работу.

00:12:50.900 --> 00:12:54.180
Ваше расширение для вознаграждений получает это уведомление. Оно проверяет идентификатор

00:12:54.180 --> 00:12:57.640
вознаграждения клиента и правила скидки. Затем оно либо позволяет процессу продолжиться,

00:12:57.840 --> 00:13:01.180
либо останавливает его с понятным сообщением. Стандартный процесс отражения операции

00:13:01.180 --> 00:13:04.900
по-прежнему принадлежит бизнес-централ. Ваше расширение просто добавляет свое специфическое

00:13:04.900 --> 00:13:08.660
правило компании в этой точке подключения. Вы часто будете слышать имена событий, такие как «да,

00:13:08.660 --> 00:13:13.020
on before» или «после on after». Да, означает, что ваш код выполняется до завершения действия. Это

00:13:13.020 --> 00:13:16.140
идеально подходит для проверки, которая может предотвратить следующий шаг. О, например,

00:13:16.340 --> 00:13:20.260
остановка заказа на продажу, если условие не выполняется. После означает, что действие уже

00:13:20.260 --> 00:13:24.460
произошло. Вы можете отреагировать, создать связанную запись, обновить примечание или начать

00:13:24.460 --> 00:13:28.600
другую работу. Имена указывают на время, а время имеет значение. Правило, которое выполняется после

00:13:28.600 --> 00:13:32.360
отражения, не может его предотвратить. Правило, которое выполняется слишком рано, может не иметь

00:13:32.360 --> 00:13:35.940
нужных данных. Поэтому разработчики выбирают события в зависимости от того, что и когда должно делать

00:13:35.940 --> 00:13:39.860
бизнес-правила. Код также может запускаться по действию. Пользователь нажимает кнопку, например,

00:13:40.000 --> 00:13:43.880
«проверить статус вознаграждения», и это действие вызывает процедуру. Код также может выполняться,

00:13:44.040 --> 00:13:48.100
когда один объект вызывает другой через переменную. Это звучит технически сложно, но все просто.

00:13:48.280 --> 00:13:52.920
Одна часть расширения просит другую выполнить задачу. Переменные помогают в этом. Переменная — это

00:13:52.920 --> 00:13:57.200
именованное место, которое хранит значение во время выполнения кода. Это может быть число, текст,

00:13:57.440 --> 00:14:02.140
дата или даже запись бизнес-централ. Например, текущий клиент. В AEL вы объявляете их с помощью VAR.

00:14:02.140 --> 00:14:05.260
Например, процедура вознаграждений может использовать переменную с именем

00:14:05.260 --> 00:14:09.880
кастомер для хранения текущей записи клиента. Другая переменная — discount percent — содержит

00:14:09.880 --> 00:14:14.240
процент скидки. Это не постоянные записи, это просто рабочие значения для этого фрагмента кода.

00:14:14.420 --> 00:14:18.080
Вот что важно знать о том, где находится код. Если правило может использоваться в нескольких

00:14:18.080 --> 00:14:22.860
местах, поместите его в код unit. Таким образом, карточка клиента, процесс продаж и отчет могут

00:14:22.860 --> 00:14:27.560
вызывать одну и ту же процедуру скидки, а не иметь каждой свою версию. Это позволяет избежать

00:14:27.560 --> 00:14:33.060
типичной проблемы. На одном экране применяется скидка 10%, на другом — 5%. И никто не знает,

00:14:33.060 --> 00:14:37.380
какому правилу верить. Хранение общих бизнес-правил в одном код unit дает расширению

00:14:37.380 --> 00:14:42.100
единый источник истины. Итак, триггеры обрабатывают правила, близкие к объекту. События

00:14:42.100 --> 00:14:46.280
позволяют расширению реагировать на собственные процессы бизнес-централ. Коди unit объединяют

00:14:46.280 --> 00:14:50.840
общую логику. Когда эти части соединены, возникает вопрос, где разработчики пишут,

00:14:51.040 --> 00:14:55.920
тестируют и проверяют весь этот AEL код. Разработка на AEL обычно происходит в Visual Studio Code,

00:14:56.140 --> 00:15:01.180
часто называемом VS Code. Это ваше рабочее пространство для написания файлов AEL. Оно помогает поддерживать

00:15:01.180 --> 00:15:05.100
порядок в расширении. Оно помогает находить проблемы и отправляет готовые приложения в среду

00:15:05.100 --> 00:15:09.580
бизнес-централ для тестирования. Но сам по себе VS Code — это лишь обычный редактор кода. Для него

00:15:09.580 --> 00:15:14.080
требуется расширение языка AEL от Microsoft. Это расширение объясняет VS Code, как работает

00:15:14.080 --> 00:15:18.300
бизнес-централ. Оно может предлагать имена объектов во время ввода. Оно указывает на ошибки до

00:15:18.300 --> 00:15:22.760
публикации. Оно помогает просматривать поля и процедуры. И оно подключает ваш проект к среде

00:15:22.760 --> 00:15:27.500
бизнес-централ. Это избавляет от многих догадок. Когда вы начинаете новый проект AEL, вы можете

00:15:27.500 --> 00:15:32.720
выполнить команду AEL Go в VS Code. Она создает базовую папку проекта и файлы настроек, имя расширения

00:15:32.720 --> 00:15:37.400
AEL, издателя, версию и среду бизнес-централ для использования. Представьте эту папку проекта

00:15:37.400 --> 00:15:41.360
как верстак для расширения. Каждый файл AEL должен находиться там. Один файл может содержать

00:15:41.360 --> 00:15:45.120
таблицу, другой — расширение страницы, а CodeUnit может иметь собственный файл. Таким образом,

00:15:45.280 --> 00:15:49.320
когда кто-то открывает проект, он может найти нужную часть, не прокручивая один огромный документ.

00:15:49.460 --> 00:15:54.260
Когда код готов к тестированию, VS Code компилирует его в пакет приложения. Это устанавливаемая

00:15:54.260 --> 00:15:58.580
версия расширения. Бизнес-централ считывает этот пакет и добавляет расширение в среду.

00:15:58.720 --> 00:16:01.900
Если отсутствует поле, допущена опечатка или возникла любая другая проблема,

00:16:02.080 --> 00:16:05.760
препятствующая сборке, VS Code сообщит вам об этом до того, как пакет попадет в бизнес-централ.

00:16:05.880 --> 00:16:09.660
Тестирование должно сначала проводиться в песочнице. Песочница — это отдельная среда

00:16:09.660 --> 00:16:13.040
бизнес-централ, где можно опробовать изменения, не рискуя реальной рабочей деятельностью.

00:16:13.200 --> 00:16:17.520
Вы публикуете расширение, открываете страницы, вносите изменения, вводите тестовые записи и проверяете,

00:16:17.680 --> 00:16:21.200
работают ли правила должным образом. Такое разделение важно. Вы же не хотите обнаружить,

00:16:21.200 --> 00:16:24.760
что новые правила проверки блокируют заказы на продажу, пока сотрудники пытаются выполнять свою

00:16:24.760 --> 00:16:29.020
работу. В песочнице можно совершать ошибки, удалять тестовые данные, изменять код и публиковать

00:16:29.020 --> 00:16:33.000
его снова, не затрагивая реальные записи. Иногда код выполняется, но результат все равно

00:16:33.000 --> 00:16:37.120
выглядит неверным. Вот тогда на помощь приходит отладка. Вы ставите точку останова в коде,

00:16:37.380 --> 00:16:41.740
запускаете процесс, и расширение приостанавливается во время работы. В этой паузе можно проверить

00:16:41.740 --> 00:16:46.220
значение, например, текущего клиента, выбранный уровень вознаграждения или процент скидки,

00:16:46.380 --> 00:16:50.740
рассчитанный процедурой. Вместо того, чтобы гадать, почему правило не сработало, вы можете точно увидеть,

00:16:50.740 --> 00:16:54.700
что получил код. Команды разработчиков также используют гид для ведения истории своей работы.

00:16:54.920 --> 00:16:58.840
Гид записывает изменения в файлах проекта с течением времени. Если кто-то изменит правила

00:16:58.840 --> 00:17:02.980
и возникнет проблема, команда сможет сравнить версии, увидеть изменения и при необходимости

00:17:02.980 --> 00:17:07.400
откатить их. Это также помогает, когда над одним расширением работает несколько разработчиков.

00:17:07.520 --> 00:17:11.500
Для новичка лучший путь – начинать с малого. Сначала изучите бизнес-централ,

00:17:11.760 --> 00:17:16.060
затем создайте одну таблицу и одну страницу. После этого расширьте стандартную страницу,

00:17:16.280 --> 00:17:20.460
добавьте простое бизнес-правило и узнайте, как события и установочные данные вписываются в проект.

00:17:20.460 --> 00:17:25.020
Далее давайте свяжем эти элементы в небольшое дополнение, которое бизнес мог бы реально

00:17:25.020 --> 00:17:30.520
использовать. Простой пример – создание дополнения для поощрения клиентов. Как на самом деле

00:17:30.520 --> 00:17:35.020
выглядит настоящее расширение на EEL? Давайте погрузимся в простой пример. Представьте,

00:17:35.140 --> 00:17:39.400
что вашей компании нужны уровни поощрения клиентов, каждый со своей скидкой. Вы начинаете

00:17:39.400 --> 00:17:43.820
с создания таблицы поощрений. Представьте ее как цифровой картотечный шкаф, где в каждой карточке

00:17:43.820 --> 00:17:49.160
есть ID, описание и процент скидки. Например, золотой уровень дает скидку 10%. Вашим сотрудникам нужно

00:17:49.160 --> 00:17:53.060
управлять этими уровнями, не прибегая к техническим инструментам. Поэтому вы добавляете две страницы –

00:17:53.060 --> 00:17:56.260
список поощрений для просмотра всех уровней и карточку поощрения для редактирования или

00:17:56.260 --> 00:18:00.500
создания. Они могут добавить новый уровень, изменить процент или просмотреть текущие данные

00:18:00.500 --> 00:18:04.680
без открытия среды разработки. Затем вы расширяете таблицу клиентов новым полем под названием

00:18:04.680 --> 00:18:09.140
ID поощрения. Это поле связывает каждого клиента с одной записью поощрения, и вы размещаете его прямо

00:18:09.140 --> 00:18:13.340
на странице карточки клиента, где сотрудники уже управляют данными клиентов. Далее вы добавляете действия

00:18:13.340 --> 00:18:17.080
поощрения, чтобы они могли открыть список поощрений прямо из той же карточки. Само правило

00:18:17.080 --> 00:18:21.280
расчета скидки находится внутри модуля кода – CodeUnit. Когда другому процессу требуется скидка

00:18:21.280 --> 00:18:25.100
клиента, он обращается к этому модулю вместо того, чтобы вычислять ее снова и снова на каждой

00:18:25.100 --> 00:18:29.240
странице. Это эффективно. Установочный модуль кода добавляет начальные уровни поощрения при

00:18:29.240 --> 00:18:33.400
первой установке вашего расширения. А подписчик событий проверяет выбранный уровень поощрения во

00:18:33.400 --> 00:18:37.900
время процесса продаж, применяя правила вашей компании в нужный момент. Это небольшое расширение,

00:18:38.140 --> 00:18:41.940
но заметьте, что оно содержит. Таблицы данных, экраны пользователей, действия навигации,

00:18:41.940 --> 00:18:46.240
логику настройки и бизнес-правила. Все это работает вместе. В этом и заключается настоящая сила

00:18:46.240 --> 00:18:50.960
EEL. Хорошо, заключение – ваша отправная точка в разработке на EEL. Итак, вот основные выводы.

00:18:51.100 --> 00:18:54.300
Разработка на EEL позволяет добавлять в бизнес-централ специфические функции,

00:18:54.480 --> 00:18:58.700
необходимые вашей компании, не затрагивая основное приложение. И вам не нужно создавать все сразу.

00:18:58.920 --> 00:19:03.220
Начните с одного поля, одного расширения страницы и одного четкого правила. Это ваш первый

00:19:03.220 --> 00:19:06.840
строительный блок. Если этот полезный совет оказался для вас ценным, подпишитесь на удобной вам

00:19:06.840 --> 00:19:10.060
платформе для подкастов и поделитесь им с теми, кто только начинает свой путь в разработке

00:19:10.060 --> 00:19:13.620
бизнес-централ. Присоединяйтесь к нам в следующий раз, когда мы добавим еще один фрагмент в общую

00:19:13.620 --> 00:19:19.360
картину. С вами был Мерка Питерс и еще один эпизод Microsoft Knowledge на Гетас на М365FM.