WEBVTT

00:00:00.000 --> 00:00:02.560
Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets.

00:00:02.720 --> 00:00:04.260
Я ваш ведучий Міро Пітерс.

00:00:04.340 --> 00:00:05.440
Отже, ось сценарій.

00:00:05.560 --> 00:00:08.640
Ви працюєте в Business Central і вам потрібна одна невелика зміна.

00:00:08.820 --> 00:00:12.360
Можливо, додаткове поле в картці клієнта, інший етап погодження або правило,

00:00:12.540 --> 00:00:14.720
яке перевіряє замовлення перед його публікацією.

00:00:14.840 --> 00:00:18.460
Потім хтось згадує розширення AL, таблиці, сторінки та модулі коду,

00:00:18.600 --> 00:00:21.460
і раптом це невелике прохання звучить як ціла нова мова.

00:00:21.640 --> 00:00:24.540
Це мова, звісно, але вона не повинна здаватися загадковою.

00:00:24.540 --> 00:00:26.900
Уявіть Business Central як офісну будівлю.

00:00:27.060 --> 00:00:31.160
AL надає розробникам інструкції, як додати кімнату, форму або нове правило,

00:00:31.300 --> 00:00:33.020
не пробиваючи дірки в самій будівлі.

00:00:33.160 --> 00:00:35.020
Це і є сьогоднішня порція знань.

00:00:35.160 --> 00:00:38.160
До кінця цього випуску ви дізнаєтеся, що означає розробка на AL,

00:00:38.320 --> 00:00:41.760
чому існують розширення і як індивідуальні налаштування вписуються в Business Central.

00:00:41.940 --> 00:00:44.220
Чому бізнес налаштовує Business Central під себе?

00:00:44.400 --> 00:00:47.580
Business Central вже обробляє багато щоденних робочих процесів, фінанси, клієнтів,

00:00:47.580 --> 00:00:49.900
замовлення на продаж, рахунки, фактури і все це в одній системі

00:00:49.900 --> 00:00:51.860
замість купи електронних таблиць та окремих інструментів.

00:00:51.980 --> 00:00:55.140
Для багатьох компаній стандартних налаштувань достатньо для виконання більшості завдань.

00:00:55.260 --> 00:00:56.380
Але ось у чому справа.

00:00:56.500 --> 00:00:58.540
Не існує двох компаній, які працюють однаково.

00:00:58.660 --> 00:00:59.860
Візьмемо дистриб'ютора продуктів харчування,

00:00:59.960 --> 00:01:02.420
якому потрібні деталі про партії товарів, які ніколи не використовує інша компанія.

00:01:02.560 --> 00:01:05.940
Сервісну компанію, який потрібен спеціальний процес погодження перед виставленням рахунків.

00:01:05.940 --> 00:01:08.960
Роздрібного продавця, який хоче мати рівніви нагород для знижок.

00:01:09.140 --> 00:01:13.000
Або когось іншого, кому потрібна форма з власними полями та внутрішніми правилами.

00:01:13.180 --> 00:01:16.360
Бізнес не буде змінювати свої методи роботи через одне відсутнє поле.

00:01:16.480 --> 00:01:20.540
І ви також не хочете, щоб кожен дрібний запит перетворювався на ризиковану зміну всієї системи.

00:01:20.640 --> 00:01:22.260
Раніше це було більшою проблемою.

00:01:22.420 --> 00:01:26.200
У старих системах розробники відкривали оригінальний код і редагували його безпосередньо.

00:01:26.320 --> 00:01:28.960
І це працювало доти, доки не надходило наступне оновлення.

00:01:28.960 --> 00:01:36.820
Тоді компанія мала нову версію від Microsoft з одного боку, власні зміни з іншого, і хтось мав узгоджувати все це, перш ніж можна було встановити оновлення.

00:01:36.940 --> 00:01:41.340
Уявіть офіс, де кожен орендар прокладає нові кабелі через стіни без жодного плану.

00:01:41.480 --> 00:01:46.420
Це працює певний час, але коли будівлі потрібен ремонт, ніхто не знає, який кабель кому належить.

00:01:46.580 --> 00:01:48.700
Business Central обирає інший шлях.

00:01:48.820 --> 00:01:53.520
Замість переписування стандартного додатка, розробники створюють окреме доповнення, яке підключається до нього,

00:01:53.520 --> 00:01:59.140
зберігаючи стандартну частину недоторканою, тоді як власні зміни компанії працюють поруч через підтримувані точки системи.

00:01:59.240 --> 00:02:05.720
Це розділення має значення під час оновлень, оскільки Microsoft оновлює свою частину будівлі, а користувацькі налаштування залишаються у власному просторі.

00:02:05.840 --> 00:02:09.220
Звісно, все одно потрібні тестування та виправлення, адже це програмне забезпечення,

00:02:09.340 --> 00:02:13.920
але від розробника більше не вимагається копіювати та переробляти кожну зміну всередині оригінального коду Microsoft.

00:02:14.100 --> 00:02:16.140
Отже, що саме бізнес налаштовує під себе?

00:02:16.580 --> 00:02:17.840
Кастомізація додає дані.

00:02:23.520 --> 00:02:27.440
Також додаються екрани, що ведуть персонал через завдання у правильному порядку.

00:02:27.580 --> 00:02:31.520
Вони також забезпечують дотримання правил, наприклад, зупиняють замовлення, якщо відсутній необхідний документ.

00:02:31.660 --> 00:02:34.640
Індивідуальні розробки також допомагають людям уникати ручних операцій.

00:02:34.760 --> 00:02:41.280
Уявіть, що персонал щоп'ятниці копіює дані клієнтів із Business Central в інший інструмент, вручно перевіряє умови, а потім надсилає звіт менеджеру.

00:02:41.280 --> 00:02:48.340
Якісно виконана зміна зберігає цю інформацію в Business Central, послідовно застосовує правила та надає персоналу кнопку або сторінку, що відповідає їхній щоденній роботі.

00:02:48.460 --> 00:02:49.980
Давайте розвіємо один міф.

00:02:50.080 --> 00:02:51.860
Ви не повинні налаштовувати все підряд.

00:02:52.000 --> 00:02:54.660
Стандартний Business Central уже має багато вбудованих процесів.

00:02:54.820 --> 00:02:58.480
Зміна чогось лише тому, що це виглядає інакше, ніж у старій системі створює додаткову роботу в майбутньому.

00:02:58.480 --> 00:03:06.940
Тож якісна кастомізація починається з чіткої бізнес-причини, з якою проблемою стикаються люди, що має відбуватися натомість, і чи може стандартний продукт це вже робити.

00:03:07.120 --> 00:03:10.600
Коли стандартний продукт не задовольняє цю потребу, на сцену виходить All.

00:03:10.760 --> 00:03:18.900
AL фокусується на самому Business Central, считуючи, додаючи та змінюючи записи на рівні бази даних, одночасно контролюючи роботу сторінок, звітів та інших частин застосунку.

00:03:19.080 --> 00:03:24.320
Він також обчислює значення, переміщує дані та показує повідомлення, коли правила не виконуються в процесах.

00:03:24.320 --> 00:03:29.440
Це великий обсяг роботи для однієї мови, але AL – не універсальний інструмент для будь-якого програмного забезпечення,

00:03:29.520 --> 00:03:34.100
і ви не обрали б його для створення публічного сайту покупок, мобільної гри чи окремого настільного застосунку.

00:03:34.240 --> 00:03:41.220
AL існує для одного цілеспрямованого завдання – формування даних і поведінки всередині Business Central так, щоб система відповідала тому, як працює компанія.

00:03:41.360 --> 00:03:43.040
І саме це ми розглянемо далі.

00:03:43.180 --> 00:03:45.840
AL і розширення – безпечна модель доповнень.

00:03:46.040 --> 00:03:49.300
AL розшифровується як мова застосунків Application Language.

00:03:49.300 --> 00:03:57.780
Це мова програмування Microsoft для Business Central, яка надає розробникам структурований спосіб створення нових бізнес-функцій або зміни поведінки існуючих частин системи.

00:03:57.880 --> 00:04:00.580
Але слово «розширення» так само важливе, як і «all».

00:04:00.580 --> 00:04:03.660
Розширення – це окремий застосунок, який може встановити Business Central.

00:04:03.860 --> 00:04:08.520
Він містить індивідуальні налаштування компанії, тоді як стандартний застосунок Business Central залишається недоторканим.

00:04:08.660 --> 00:04:12.280
Думайте про це не як про переписування довідника, а як про додавання до нього затверджених сторінок.

00:04:12.280 --> 00:04:15.220
Так, сторінок, які відповідають початковим правилам, не стираючи їх.

00:04:15.360 --> 00:04:19.080
Це може звучати як технічна деталь, але це змінює те, як індивідуальні налаштування існують часом.

00:04:19.200 --> 00:04:22.260
Уявіть, що компанії потрібна нова офісна кімната для спеціальної команди.

00:04:22.400 --> 00:04:26.280
Старий підхід означав би пробивання стіни в головній будівлі та зміну самої конструкції.

00:04:26.460 --> 00:04:32.640
Це може розв'язати проблему сьогодні, але майбутній ремонт стане кошмаром, бо оригінальна будівля більше не відповідає кресленням.

00:04:32.640 --> 00:04:34.360
Розширення працює інакше.

00:04:34.520 --> 00:04:37.860
У будівлі вже є двері, розетки та правила для додавання простору.

00:04:38.000 --> 00:04:40.500
Ви будуєте нову кімнату через ці схвалені з'єднання.

00:04:40.640 --> 00:04:45.240
Кімната належить компанії, але головна будівля може обслуговуватися без руйнування кожної нестандартної стіни.

00:04:45.460 --> 00:04:47.600
Саме так працюють розширення Business Central.

00:04:47.840 --> 00:04:50.860
Базовий додаток містить стандартну роботу, яку надає Microsoft.

00:04:51.140 --> 00:04:56.120
Розширення може додавати власні поля, екрани, кнопки, правила, звіти і навіть посилання на інші системи.

00:04:56.120 --> 00:05:01.880
Воно може реагувати на певні бізнес-дії, але робить це через підтримувані способи підключення до стандартного додатка.

00:05:02.020 --> 00:05:03.400
Отже, межі вбудовані.

00:05:03.540 --> 00:05:04.280
Це добре.

00:05:04.420 --> 00:05:08.600
Безмеж невеликий індивідуальний запит може проникнути глибоко в зони, яких він не повинен торкатися.

00:05:08.760 --> 00:05:12.900
Завдяки розширенням розробник працює з чіткими типами об'єктів і визначеними точками підключення,

00:05:13.040 --> 00:05:16.600
що полегшує розуміння коду, коли комусь іншому потрібно буде його прочитати пізніше.

00:05:16.740 --> 00:05:20.040
Такий підхід також ідеально підходить для хмарної версії Business Central.

00:05:20.040 --> 00:05:22.420
Microsoft регулярно оновлює цей сервіс.

00:05:22.540 --> 00:05:27.820
Компанії все одно потрібно тестувати своє розширення після змін, особливо якщо воно залежить від частин продукту, які були оновлені.

00:05:27.940 --> 00:05:30.720
Програмне забезпечення ніколи не знімає необхідності турботи про нього.

00:05:30.880 --> 00:05:36.500
Але відокремлення власного коду зменшує ймовірність того, що кожне оновлення перетвориться на серйозну переробку старих модифікацій.

00:05:36.640 --> 00:05:40.840
Ви можете почути згадки про CAL, коли мова йде про старіші системи Dynamics NAV.

00:05:40.840 --> 00:05:46.660
CAL з'явився в ранній моделі розробки, де програмісти часто змінювали оригінальні об'єкти програми безпосередньо.

00:05:46.800 --> 00:05:52.580
Багато компаній роками успішно використовували системи в такий спосіб, але це тісно пов'язувало власні розробки зі стандартним кодом,

00:05:52.660 --> 00:05:55.280
а оновлення вимагали багато роботи з порівняння та виправлення.

00:05:55.420 --> 00:05:58.240
AL перевів Business Central на розробку на основі додатків.

00:05:58.360 --> 00:06:01.100
Це не означає, що кожне розширення є великим чи складним.

00:06:01.280 --> 00:06:05.620
Одне розширення може лише додати поле до запису клієнта та відобразити його на знаємому екрані.

00:06:05.620 --> 00:06:11.460
Інше може містити повне рішення для певного типу бізнесу з власними записами, процесами, сторінками та звітами.

00:06:11.620 --> 00:06:13.920
Обидва дотримуються однієї базової ідеї.

00:06:14.100 --> 00:06:17.780
Власний додаток існує поруч із Business Central, а не приховує його переписану версію.

00:06:17.940 --> 00:06:20.340
Ви також можете встановити більше, ніж одне розширення.

00:06:20.480 --> 00:06:23.940
Компанія може використовувати розширення від програмного партнера для розрахунку зарплати,

00:06:24.020 --> 00:06:28.020
інше – для доставки і невелике внутрішнє розширення для правил, важливих лише для цієї компанії.

00:06:28.020 --> 00:06:33.620
Business Central об'єднує їх у спільну робочу систему, доки вони дотримуються правил платформи та не конфліктують між собою.

00:06:33.780 --> 00:06:36.100
Отже, AL – це не просто спосіб написання коду.

00:06:36.280 --> 00:06:39.300
Це мова, яку розробники використовують для створення цих додаткових програм,

00:06:39.440 --> 00:06:42.380
а розширення – це контейнер, який переносить ці зміни в Business Central.

00:06:42.580 --> 00:06:47.480
Ця модель дозволяє компанії адаптувати систему, зберігаючи стандартний продукт впізнаваним і легшим в обслуговуванні.

00:06:47.580 --> 00:06:51.300
Тепер давайте відкриємо одне з цих розширень і розглянемо його складові елементи.

00:06:51.300 --> 00:06:54.300
Основні будівельні блоки AL – всередині розширення All.

00:06:54.460 --> 00:06:56.140
Розробники працюють з об'єктами.

00:06:56.300 --> 00:07:00.100
Об'єкт – це окрема іменована частина програми з чітким завданням, як-от зберігання інформації,

00:07:00.220 --> 00:07:02.760
відображення екрана, виконання правила чи створення документа.

00:07:02.880 --> 00:07:06.980
Коли ви бачите ці завдання окремо, AL починає здаватися набагато менш схожим на суцільну стіну коду.

00:07:07.140 --> 00:07:09.640
Почнемо з місця, де зберігається бізнес-інформація.

00:07:09.780 --> 00:07:11.760
Таблиці зберігають дані в Business Central.

00:07:11.760 --> 00:07:14.980
Уявіть таблицю як цифрову картотеку для одного типу записів.

00:07:15.100 --> 00:07:19.200
Одна шафа може містити клієнтів, інша – товари, а ще одна – замовлення на продаж.

00:07:19.320 --> 00:07:21.520
Кожен запис – це один файл у цій шафі.

00:07:21.640 --> 00:07:24.540
Таблиця клієнтів містить один запис для кожного клієнта.

00:07:24.680 --> 00:07:27.520
Таблиця товарів містить один запис для кожного продукту.

00:07:27.700 --> 00:07:31.680
Якщо вашій компанії потрібна інформація, яку стандартний бізнес-централ не зберігає,

00:07:31.800 --> 00:07:34.940
розширення може створити власну таблицю, можливо, для рівнів винагород,

00:07:35.060 --> 00:07:37.040
оглядів обладнання чи затвердження проєктів.

00:07:37.040 --> 00:07:39.880
Поля – це підписані місця всередині кожного запису.

00:07:40.020 --> 00:07:44.020
Запис клієнта може включати ім'я, адресу, умови оплати та номер телефону,

00:07:44.080 --> 00:07:46.740
оскільки таблиця клієнтів містить поля для цих деталей.

00:07:46.860 --> 00:07:51.720
Поля можуть містити текст, дати, суми, відповіді «Так» чи «Ні» або вибір із фіксованого списку.

00:07:51.860 --> 00:07:53.840
Поле також може вказувати на інший запис.

00:07:54.060 --> 00:07:56.800
Наприклад, клієнт може містити поле «Айді винагороди».

00:07:56.800 --> 00:08:00.860
Замість введення довільного тексту персонал обирає рівень винагороди з окремої таблиці винагород.

00:08:00.860 --> 00:08:04.620
Цей зв'язок підтримує дані в чистоті, оскільки всі обирають із одного і того самого відомого списку.

00:08:04.760 --> 00:08:06.180
Отже, таблиці зберігають факти.

00:08:06.360 --> 00:08:08.360
Але як люди бачать ці факти і як з ними працюють?

00:08:08.560 --> 00:08:09.000
Сторінки.

00:08:09.180 --> 00:08:11.400
Сторінка – це екран, який ви відкриваєте в «Бізнес-централ».

00:08:11.400 --> 00:08:12.820
Картка клієнта – це сторінка.

00:08:13.020 --> 00:08:14.680
Список замовлень на продаж – це сторінка.

00:08:14.840 --> 00:08:18.020
Сторінка контролює те, що користувачі можуть переглядати, вводити, шукати та з чим працювати.

00:08:18.200 --> 00:08:19.980
Різні сторінки підходять для різних завдань.

00:08:19.980 --> 00:08:23.980
Сторінка картки фокусується на одному записі за раз, наприклад, на одному клієнті або одному товарі.

00:08:24.100 --> 00:08:29.560
Сторінка списку показує багато записів у рядках, що зручно, коли потрібно швидко переглянути, відфільтрувати або знайти щось.

00:08:29.720 --> 00:08:34.480
Сторінка робочого аркуша підтримує роботу, де люди вводять або обробляють кілька рядків інформації разом.

00:08:34.600 --> 00:08:36.280
Таблиця зберігає інформацію.

00:08:36.480 --> 00:08:38.460
Сторінка показує її користувачеві.

00:08:38.580 --> 00:08:42.520
Такий розподіл корисний, оскільки ви можете змінити екран, не змінюючи місце зберігання даних,

00:08:42.520 --> 00:08:48.040
або використовувати ту саму таблицю на кількох сторінках, коли різним командам потрібні різні представлення одних і тих самих записів.

00:08:48.140 --> 00:08:51.100
А що, як дані вже належать до стандартного запису Business Central?

00:08:51.300 --> 00:08:54.980
Ви зазвичай не створюєте таблицю клієнтів на заміну лише тому, що вам потрібно одне додаткове поле.

00:08:55.120 --> 00:08:56.840
Ви використовуєте розширення таблиці.

00:08:57.000 --> 00:09:00.100
Розширення таблиці додає ваше поле до існуючої таблиці клієнтів.

00:09:00.100 --> 00:09:05.880
Стандартний запис клієнта залишається на своєму місці, а ваше розширення додає специфічні дані компанії поруч зі стандартними полями.

00:09:06.040 --> 00:09:11.280
Це може бути ідентифікатор винагороди, примітка про доставку, менеджер облікового запису або поле, що з'єднує з іншою частиною бізнесу.

00:09:11.380 --> 00:09:14.460
Але додавання поля до таблиці не відображає його автоматично на екрані.

00:09:14.600 --> 00:09:16.600
Для цього ви використовуєте розширення сторінки.

00:09:16.760 --> 00:09:19.940
Розширення сторінки додає поле, групу або дію до існуючої сторінки.

00:09:19.940 --> 00:09:27.760
Якщо бізнесу потрібно, щоб персонал обирав рівень винагороди під час перегляду клієнта, розширення сторінки може розмістити поле ID винагороди прямо в картці клієнта, де вже працюють співробітники.

00:09:27.920 --> 00:09:29.780
Це зберігає звичний досвід роботи.

00:09:29.960 --> 00:09:35.740
Замість того, щоб направляти користувачів на окремий спеціальний екран для простої деталі, розширення додає цю деталь на знайому їм сторінку.

00:09:35.940 --> 00:09:40.540
Розширення сторінки також може додавати дію, кнопку або команду меню, що запускає завдання.

00:09:40.540 --> 00:09:44.980
Наприклад, картка клієнта може містити дію винагороди, яка відкриває список винагород.

00:09:45.120 --> 00:09:47.460
За екраном вам потрібне місце для бізнес-правил.

00:09:47.580 --> 00:09:49.340
Таким місцем часто є коди у ніт.

00:09:49.500 --> 00:09:53.660
Коди у ніт містить процедури AL – це іменовані фрагменти коду, які виконують певну роботу.

00:09:53.860 --> 00:09:59.360
Думайте про це як про BackOffice, який виконує завдання, коли сторінка, звіт або інший процес просить про допомогу.

00:09:59.540 --> 00:10:02.800
Припустимо, рівень винагороди визначає знижку для клієнта.

00:10:02.800 --> 00:10:07.020
Розрахунок знижки має бути в коди у ніт, а не в самій сторінці картки клієнта.

00:10:07.200 --> 00:10:13.140
Тоді процес продажу, звіт або майбутня сторінка зможуть використовувати одне й те саме правило без дублювання в багатьох місцях.

00:10:13.320 --> 00:10:15.420
Одне правило – одне місце для його підтримки.

00:10:15.600 --> 00:10:18.580
Бізнес-централ також включає інші типи об'єктів для різних завдань.

00:10:18.580 --> 00:10:23.380
Звіти збирають дані та представляють їх у вигляді документа або макета, як от рахунок фактура або звіт про продажі.

00:10:23.380 --> 00:10:28.340
Запити «Квіріс» ставлять конкретні питання до даних, наприклад, які клієнти замовили певний товар за період.

00:10:28.480 --> 00:10:32.340
Наприклад, XML-порти допомагають імпортувати або експортувати дані у структурованому форматі,

00:10:32.420 --> 00:10:35.560
часто коли іншій системі потрібно обмінятися інформацією з «Бізнес-централ».

00:10:35.560 --> 00:10:39.240
Зберіть ці частини разом, і ви зможете уявити невелике розширення для винагород клієнтів.

00:10:39.240 --> 00:10:42.200
Таблиця «Винагород» зберігає кожен рівень та його відсоток знижки.

00:10:42.340 --> 00:10:44.960
Сторінки «Винагород» дозволяють персоналу керувати цими рівнями.

00:10:53.380 --> 00:10:56.820
Кожен об'єкт відповідає за окрему частину роботи.

00:10:56.960 --> 00:11:02.020
Це робить розширення зручнішим для читання, тестування та внесення змін, коли «Бізнес-правило» змінюється через півроку.

00:11:02.120 --> 00:11:06.400
Але «Бізнес-правило» часто має виконуватися в точно визначений момент, наприклад, під час обліку замовлення.

00:11:06.400 --> 00:11:08.340
Ось тут стають у пригоді тригери та події.

00:11:08.480 --> 00:11:10.300
Події, тригери та «Бізнес-правила».

00:11:10.300 --> 00:11:12.200
Отже, ви додали поле «Винагороди» клієнта.

00:11:12.360 --> 00:11:14.020
Добре, ось справжнє запитання.

00:11:14.180 --> 00:11:16.160
Коли «Бізнес-централ» має використовувати це поле?

00:11:16.160 --> 00:11:18.360
Уявіть, що ви збираєтеся облікувати замовлення на продаж.

00:11:18.480 --> 00:11:21.380
Перш ніж система створить фінальні записи, ви хочете провести додаткову перевірку.

00:11:21.560 --> 00:11:24.980
Можливо, клієнту потрібен підтверджений рівень винагороди, перш ніж почне діяти знижка.

00:11:25.120 --> 00:11:29.500
Або, можливо, має існувати необхідний документ на доставку, перш ніж замовлення зможе рухатися далі.

00:11:29.500 --> 00:11:35.480
Ви хочете цю перевірку в потрібний момент, але не бажаєте копіювати весь процес обліку продажів у своє розширення лише заради одного правила.

00:11:35.660 --> 00:11:38.180
Цей процес вже виконує багато роботи у фоновому режимі.

00:11:38.180 --> 00:11:41.860
Якщо ви його скопіюєте, ваше розширення буде змушене підтримувати всі майбутні зміни.

00:11:42.000 --> 00:11:42.980
Не найкращий варіант.

00:11:43.160 --> 00:11:45.480
Тому IAL надає розробникам кілька способів запуску коду.

00:11:45.640 --> 00:11:48.080
Те, що ви оберете, залежить від того, що має статися.

00:11:48.220 --> 00:11:49.220
По-перше, тригери.

00:11:49.220 --> 00:11:52.840
Тригер – це іменована точка всередині об'єкта IAL, де може виконуватися код.

00:11:52.960 --> 00:11:55.920
Коли хтось змінює значення в полі таблиці, тригер запускає код.

00:11:56.040 --> 00:11:58.900
Коли сторінка відкривається або закривається, тригер запускає код.

00:11:58.900 --> 00:12:03.760
Звіти, запити, XML-порти, таблиці, розширення, IAL – всі вони мають такі точки, куди розробник може додати правила.

00:12:03.920 --> 00:12:05.920
Візьмемо поле ID винагороди для клієнта.

00:12:06.060 --> 00:12:09.000
Коли користувач вибирає рівень винагороди, може спрацювати тригер перевірки.

00:12:09.000 --> 00:12:14.440
Код перевіряє, чи заблокований клієнт, чи існує такий рівень винагороди, чи потрібно оновити інше поле.

00:12:14.560 --> 00:12:18.260
Перевірка відбувається саме в момент зміни значення, а не пізніше, коли хтось виявить помилку.

00:12:18.260 --> 00:12:21.360
Тригери добре працюють, коли правило безпосередньо стосується цього об'єкта.

00:12:21.480 --> 00:12:23.540
Але Business Central також використовує події.

00:12:23.680 --> 00:12:25.160
Подія – це як повідомлення.

00:12:25.300 --> 00:12:28.160
Одна частина програми надсилає його, коли щось стається.

00:12:28.160 --> 00:12:33.800
Вона може сповістити, що запис ось-ось буде вставлено, що документ скоро буде обліковано, або що процес завершено.

00:12:33.960 --> 00:12:36.280
Ваше розширення може прослуховувати це повідомлення.

00:12:36.420 --> 00:12:39.000
Код, який здійснює прослуховування, називається підписником події.

00:12:39.180 --> 00:12:40.880
Він очікує напевну іменовану подію.

00:12:40.880 --> 00:12:44.360
Коли Business Central ініціює цю подію, підписник виконує власну процедуру.

00:12:44.540 --> 00:12:46.380
Стандартний процес залишається головним.

00:12:46.540 --> 00:12:50.700
Наприклад, коли Business Central починає облік замовлення на продаж, він ініціює подію перед продовженням.

00:12:50.700 --> 00:12:53.040
Ваше розширення для винагород отримує це повідомлення.

00:12:53.160 --> 00:12:55.660
Воно перевіряє ID винагороди, клієнта та правило знижки.

00:12:55.800 --> 00:12:59.420
Потім воно або дозволяє процесу продовжитися, або зупиняє його з чітким повідомленням.

00:12:59.540 --> 00:13:02.660
Стандартний процес публікації, як і раніше, належить Business Central.

00:13:02.660 --> 00:13:06.640
Ваше розширення просто додає своє правило, специфічне для компанії у цій точці підключення.

00:13:06.800 --> 00:13:09.720
Ви часто чутімєте назви подій, як от OnBafo або Onafta.

00:13:09.900 --> 00:13:12.680
OnBafo означає, що ваш код запускається перед завершенням дії.

00:13:12.680 --> 00:13:15.520
Це ідеально підходить для перевірки, яка може запобігти наступному кроку.

00:13:15.640 --> 00:13:18.460
Наприклад, зупинка замовлення на продаж, якщо умова не виконується.

00:13:18.620 --> 00:13:20.580
Afta означає, що дія вже відбулася.

00:13:20.740 --> 00:13:25.040
Ви можете відреагувати, створити пов'язаний запис, оновити примітку або розпочати іншу роботу.

00:13:25.240 --> 00:13:27.220
Назви вказують на час, а час має значення.

00:13:27.360 --> 00:13:29.960
Правило, яке запускається після публікації, не може їй запобігти.

00:13:30.100 --> 00:13:32.940
Правило, яке запускається занадто рано, може не мати потрібних даних.

00:13:33.020 --> 00:13:36.280
Тому розробники обирають подію залежно від того, що і коли має робити бізнес-правило.

00:13:36.280 --> 00:13:38.160
Код також може запускатися від дії.

00:13:38.340 --> 00:13:42.620
Користувач натискає кнопку, наприклад, перевірити статус винагороди, і ця дія викликає процедуру.

00:13:42.740 --> 00:13:45.980
Код також може виконуватися, коли один об'єкт викликає інший через змінну.

00:13:46.120 --> 00:13:47.880
Це звучить технічно, але все просто.

00:13:48.080 --> 00:13:50.620
Одна частина розширення просить іншу виконати роботу.

00:13:50.620 --> 00:13:52.200
Змінні допомагають у цьому.

00:13:52.380 --> 00:13:55.700
Змінна – це іменоване місце, яке зберігає значення під час виконання коду.

00:13:55.880 --> 00:13:59.920
Це може бути число, текст, дата або навіть запис бізнес-централ, наприклад, поточний клієнт.

00:13:59.920 --> 00:14:02.380
В АЛ ви оголошуєте їх за допомогою ВАП.

00:14:02.440 --> 00:14:07.340
Наприклад, процедура винагород може використовувати змінну «Кастама» для зберігання запису поточного клієнта.

00:14:07.500 --> 00:14:10.500
Інша змінна – «Дискаунт пасент» зберігає розмір знижки.

00:14:10.680 --> 00:14:11.920
Це не постійні записи.

00:14:12.060 --> 00:14:14.140
Це лише робочі значення для цієї частини коду.

00:14:14.140 --> 00:14:16.140
Ось як це працює з місцем зберігання коду.

00:14:16.280 --> 00:14:19.520
Якщо правило може використовуватися у кількох місцях, помістіть його в кодеуніт.

00:14:19.640 --> 00:14:26.180
Таким чином, картка клієнта, процес продажу та звіт можуть викликати одну і ту саму процедуру знижки замість того, щоб мати власні версії.

00:14:26.360 --> 00:14:28.540
Це дозволяє уникнути знайомої проблеми.

00:14:28.660 --> 00:14:33.900
Один екран застосовує знижку 10%, інший – 5% і ніхто не знає, якому правилу довіряти.

00:14:34.100 --> 00:14:38.640
Зберігання спільних бізнес-правил в одному кодеуніт дає розширенню єдине джерело для такого рішення.

00:14:38.640 --> 00:14:44.840
Отже, тригери обробляють правила, пов'язані з об'єктом. Події дозволяють розширенню реагувати на власні процеси Business Central.

00:14:45.040 --> 00:14:47.200
Кодеуніт зберігають спільну логіку разом.

00:14:47.360 --> 00:14:52.700
Коли ці елементи з'єднані, виникає питання, де розробники пишуть, тестують та перевіряють весь цей EL-код.

00:14:52.840 --> 00:14:57.540
Розробка на EL зазвичай відбувається у Visual Studio Code, яку часто називають VS Code.

00:14:57.720 --> 00:14:59.880
Це ваш робочий простір для написання файлів All.

00:15:00.040 --> 00:15:01.980
Він допомагає впорядкувати ваше розширення.

00:15:01.980 --> 00:15:06.320
Він допомагає знаходити проблеми та надсилає готовий додаток у середовище Business Central для тестування.

00:15:06.460 --> 00:15:09.080
Але VS Code сам по собі – це лише загальний редактор коду.

00:15:09.300 --> 00:15:11.580
Для нього потрібне розширення мови EL від Microsoft.

00:15:11.840 --> 00:15:14.520
Це розширення пояснює VS Code, як працює Business Central.

00:15:14.760 --> 00:15:16.840
Воно може пропонувати назви об'єктів під час введення.

00:15:17.040 --> 00:15:18.840
Воно вказує на помилки перед публікацією.

00:15:19.020 --> 00:15:20.880
Воно допомагає переглядати поля та процедури.

00:15:21.000 --> 00:15:23.320
І воно підключає ваш проект до середовища Business Central.

00:15:23.500 --> 00:15:25.260
Це позбавляє від необхідності вгадувати.

00:15:25.260 --> 00:15:29.400
Коли ви розпочинаєте новий EL проект, можна запустити команду Elgo у VS Code.

00:15:29.580 --> 00:15:33.240
Вона створює базову папку проекту та файли налаштувань, назву розширення,

00:15:33.400 --> 00:15:35.780
видавця, версію та середовище Business Central.

00:15:35.980 --> 00:15:38.500
Сприймайте цю папку проекту як верстак для розширень.

00:15:38.620 --> 00:15:40.260
Кожен файл EL належить до неї.

00:15:40.420 --> 00:15:42.900
Один файл може містити таблицю, інший – розширення сторінки,

00:15:43.000 --> 00:15:44.460
а CodeUnit може мати власний файл.

00:15:44.540 --> 00:15:46.200
Таким чином, коли хтось відкриває проект,

00:15:46.320 --> 00:15:49.240
він може знайти потрібну частину без гортання величезного документа.

00:15:49.240 --> 00:15:52.980
Коли код готовий до тестування, VS Code компілює його у пакет додатка.

00:15:53.160 --> 00:15:55.080
Це встановлювана версія розширення.

00:15:55.280 --> 00:15:58.680
Business Central зчитує цей пакет і додає розширення до середовища.

00:15:58.800 --> 00:16:00.960
Якщо є відсутнє поле, одрук або інша проблема,

00:16:01.120 --> 00:16:03.980
що заважає збірці додатка, VS Code повідомить про це до того,

00:16:04.120 --> 00:16:05.660
як пакет потрапить у Business Central.

00:16:05.840 --> 00:16:08.160
Тестування має відбуватися спочатку в Пісочниці.

00:16:08.320 --> 00:16:10.400
Пісочниця – це окреме середовище Business Central,

00:16:10.540 --> 00:16:12.920
де можна випробувати зміни без ризику для поточної роботи.

00:16:12.920 --> 00:16:15.660
Ви публікуєте розширення, відкриваєте сторінки, які воно змінює,

00:16:15.760 --> 00:16:18.640
вводите тестові записи і перевіряєте, чи правила працюють, як очікувалося.

00:16:18.780 --> 00:16:20.280
Таке розділення має значення.

00:16:20.440 --> 00:16:23.180
Ви ж не хочете дізнатися, що нове правило перевірки блокує замовлення на продаж,

00:16:23.260 --> 00:16:24.980
поки персонал намагається виконувати свою роботу.

00:16:25.160 --> 00:16:27.900
У Пісочниці можна припускатися помилок, видаляти тестові дані,

00:16:28.000 --> 00:16:30.800
змінювати код і публікувати знову, не впливаючи на робочі записи.

00:16:30.940 --> 00:16:33.520
Іноді код запускається, але результат виглядає неправильно.

00:16:33.520 --> 00:16:35.620
Ось тоді на допомогу приходить налагодження.

00:16:35.780 --> 00:16:38.160
Ви ставите точку зупину в коді, запускаєте процес,

00:16:38.260 --> 00:16:40.260
і розширення призупиняється під час виконання.

00:16:40.400 --> 00:16:42.580
Під час цієї паузи можна перевірити значення,

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

00:16:47.440 --> 00:16:49.500
Замість того, щоб вгадувати, чому правило не спрацювало,

00:16:49.620 --> 00:16:51.340
ви можете побачити саме те, що отримав код.

00:16:51.460 --> 00:16:54.920
Команди розробників також використовують DIT, щоб зберігати історію своєї роботи.

00:16:54.920 --> 00:16:57.340
DIT записує зміни у файлах проєкту з часом.

00:16:57.480 --> 00:16:59.300
Якщо хтось змінює правило і створює проблему,

00:16:59.420 --> 00:17:03.440
команда може порівняти версії, побачити зміни та, за потреби, повернутися до попередньої версії.

00:17:03.580 --> 00:17:07.100
Це також допомагає, коли над одним розширенням працює кілька розробників.

00:17:07.260 --> 00:17:09.840
Для початківця найкращий шлях – починати з малого.

00:17:10.020 --> 00:17:14.200
Спочатку вивчіть можливості Business Central, а потім створіть одну таблицю та одну сторінку.

00:17:14.360 --> 00:17:17.340
Після цього розширті стандартну сторінку, додайте просте бізнес-правило

00:17:17.340 --> 00:17:20.380
та дізнайтеся, як події та інсталяційні дані вписуються в проєкт.

00:17:20.520 --> 00:17:25.600
Далі давайте поєднаємо ці елементи в один невеликий додаток, який бізнес дійсно зможе використовувати.

00:17:26.320 --> 00:17:29.620
Простий приклад – створення додатку для винагород клієнтів.

00:17:29.760 --> 00:17:32.260
Як насправді виглядає справжнє розширення на L?

00:17:32.420 --> 00:17:34.440
Давайте зануримося у простий приклад.

00:17:34.600 --> 00:17:38.640
Уявіть, що вашій компанії потрібні рівні винагород для клієнтів, кожен зі своєю знижкою.

00:17:38.820 --> 00:17:40.860
Ви починаєте зі створення таблиці винагород.

00:17:40.860 --> 00:17:45.600
Сприймайте її як цифрову картотеку, де кожен файл містить ідентифікатор, опис та відсоток знижки.

00:17:45.780 --> 00:17:48.220
Наприклад, статус «Золотий» дає знижку 10%.

00:17:48.220 --> 00:17:51.340
Вашому персоналу потрібно керувати цими рівнями, не торкаючись технічних інструментів.

00:17:51.460 --> 00:17:54.280
Тому ви додаєте дві сторінки – сторінку списку винагород для перегляду всіх рівнів

00:17:54.280 --> 00:17:56.580
і сторінку картки винагороди для редагування чи створення нової.

00:17:56.720 --> 00:18:01.860
Вони можуть додати новий рівень, змінити відсоток або переглянути існуючі дані, не відкриваючи середовище розробки.

00:18:01.860 --> 00:18:05.480
Далі ви розширюєте таблицю клієнтів новим полем під назвою ID винагороди.

00:18:05.600 --> 00:18:08.180
Це поле пов'язує кожного клієнта з одним записом винагороди,

00:18:08.240 --> 00:18:11.980
і ви розміщуєте його прямо на сторінці картки клієнта, де персонал уже веде облік даних.

00:18:12.100 --> 00:18:16.400
Потім ви додаєте дію для винагород, щоб вони могли відкривати список винагород безпосередньо з тієї ж картки.

00:18:16.580 --> 00:18:19.480
Саме правило знижки знаходиться всередині кодової одиниці – кодеунів.

00:18:19.620 --> 00:18:22.820
Коли іншому процесу потрібна знижка клієнта, він звертається до цієї кодової одиниці,

00:18:22.820 --> 00:18:25.360
замість того, щоб обчислювати її знову і знову на кожній сторінці.

00:18:25.520 --> 00:18:26.360
Це ефективно.

00:18:26.540 --> 00:18:30.580
Інсталяційна кодова одиниця додає початкові рівні винагород під час першого встановлення вашого розширення.

00:18:30.720 --> 00:18:33.860
А підписник подій перевіряє обраний рівень винагороди під час процесу продажу,

00:18:33.980 --> 00:18:36.480
застосовуючи правило вашої компанії саме в потрібний момент.

00:18:36.660 --> 00:18:39.760
Це одне невелике розширення, але зверніть увагу на те, що воно містить.

00:18:39.760 --> 00:18:44.760
Таблиці даних, екрани користувачів, навігаційні дії, логіка налаштування та бізнес-правила – усе це працює разом.

00:18:44.880 --> 00:18:46.220
Це справжня сила ОЛ.

00:18:46.360 --> 00:18:49.260
Отже, висновок – ваша відправна точка в розробці на ОЛ.

00:18:49.360 --> 00:18:50.700
Отже, основний висновок.

00:18:50.860 --> 00:18:56.840
Розробка на IEL дозволяє додавати до бізнес-централ-специфічні функції, необхідні вашій компанії, не змінюючи основну програму.

00:18:56.960 --> 00:18:58.760
І вам не потрібно будувати все відразу.

00:18:58.940 --> 00:19:02.340
Почніть з одного поля, одного розширення сторінки та одного чіткого правила.

00:19:02.500 --> 00:19:04.020
Це ваш перший будівельний блок.

00:19:04.020 --> 00:19:10.540
Якщо цей фрагмент знань був для вас корисним, підпишіться на улюбленій подкаст-платформі та поділіться ним з тими, хто лише починає розробку в бізнес-централ.

00:19:10.680 --> 00:19:13.760
Приєднуйтесь до нас наступного разу, коли ми додамо ще одну частину пазла.

00:19:13.960 --> 00:19:19.360
Я Марко Пітерс, і це був черговий епізод Microsoft Knowledge Nuggets на М365FM.